2

I want to encrypt my server's backups and upload them to cloud storage (e.g. dropbox, google drive).

I understand the basics with symmetric (single passphrase-secured key) and asymmetric (public/private keypair) encryption. But I don't know which would be more appropriate in my specific use case.

I've read many related questions and there seems to be a 50/50 split between people who recommend the one way or the other (for this specific use case) - but I can't find a reason why.

I know that asymmetric is used when one can perform key exchange between parties, and that it is much slower. So symmetric is typically used to encrypt large payloads.

In my case, my daily backups are a few hundred megabytes each, and there is no key exchange because I am both "sender" and "receiver". And these are secondary backups - I will only decrypt them if my primary backups fail.

So I was planning to store on the server a very long (e.g. 100 char) passphrase, and use it for automated backups using gpg symmetric encryption, which is simple to manage. Is this good enough, or should I rather use asymmetric encryption?

lonix
  • 403
  • 6
  • 14
  • One factor in choosing symmetric over asymmetric encryption in your case is the "speed" of encryption as you are encrypting several hundreds of megabytes. – bhorkarg Apr 01 '20 at 06:49
  • 1
    Does this answer your question? [When should I use symmetric encryption instead of RSA?](https://security.stackexchange.com/questions/54360/when-should-i-use-symmetric-encryption-instead-of-rsa) – bhorkarg Apr 01 '20 at 06:50
  • @bhorkarg Thanks. Those answers though deal with the underlying technology, whereas I'm interested in how to choose for this specific use case (secure backup on untrusted remote storage). Those answers even state as much, i.e. that the use case it relevant. – lonix Apr 01 '20 at 07:34
  • @lonix yes, but read some of the other answers. One of them mentions that some applications (like GPG) actually do both. The data is encrypted with symmetric encryption. The symmetric key is encrypted with the recipient's public key and sent to them. – multithr3at3d Apr 02 '20 at 14:19

1 Answers1

2

Generate a reasonable long (around 200 bytes) symmetric key, use it to encrypt your backups, and encrypt the symmetric key with a long, secure and protected asymmetric key.

Symmetric key is faster to encrypt, that's why SSL use symmetric keys for encrypting the traffic. It uses asymmetric keys to exchange the symmetric session key. You should to the same.

Using the same key for every backup creates a situation that leaking the key once means every backup can be compromised. Having a different asymmetrical key for each backup means keeping track of every key, for as long as the backup is kept.

And you use the public asymmetric key to encrypt the symmetric one, so the private key is kept protected.

My answer to another question have some more insights.

ThoriumBR
  • 51,983
  • 13
  • 131
  • 149
  • Like you said it makes sense to use a symmetric session key A for payload encryption, and use a master key B to encrypt key A. But that raises an interesting question - why must B be asymmetric? Why not use another symmetric key? (I suspect that is an interesting and complicated issue, so I can move it to a new question if necessary?) – lonix Apr 01 '20 at 07:37
  • 1
    It's a simple reason: using the same symmetric key every day increases the chances of someone leaking it, by accident or otherwise. Giving anyone a public key does no harm, giving the symmetric key destroys its secrecy, and all protection it provided. – ThoriumBR Apr 01 '20 at 10:51
  • Okay that is sensible. But keep in mind that if someone hacks into my server, and steals that key that I use to encrypt the backups, then... I have bigger problems, because he is *already in my server*, so I won't care about the key anymore :-) Regardless, thank you for helping me again! – lonix Apr 01 '20 at 11:08
  • On the other hand... In my case where it's just me (and my automation scripts), then it doesn't apply. BUT, your comment is a strong one in the case where a server has multiple users - an unhappy employee might find the key and leak it! So you are right, it's better to use pub/priv encryption that way only the boss will have access to the private key, and the employees can't do any damage with the public key. – lonix Apr 01 '20 at 11:13
  • If a hacker enters your server, you lost your servers AND all your data. Any sensitive information you had is now on his hands. If a hacker gets your server and all data is encrypted, you just format the server and copy all data again. – ThoriumBR Apr 01 '20 at 11:59
  • also add that, when you encrypt a file with an asymmetric key using standard software, the file is indeed encrypted symmetrically and the key is encrypted asymmetrically. In other words, the process noted by @ThoriumBR is default anyways (with a difference that the encrypted key is attached in too). – eli Apr 01 '20 at 19:43
  • I note asymmetric crypto is weaker. Either you don't exchange your encrypted asymmetric key, in which case there is no point in using asymmetric encryption, or you do exchange it, in which case, if encrypted key is intercepted, your 100 characters long key is worth only around 20 characters. Still very secure, but not as much as you thought. – eli Apr 01 '20 at 19:50
  • You don't need to exchange the key, you will have the public key together with the backup script. If 100 chars are not enough, 4k chars will be. – ThoriumBR Apr 01 '20 at 20:05
  • For a case where a key exchange is not involved, I would encrypt the (original long) symmetric key with another (shorter memorable) symmetric key. That's done by my password manager with AES 256. The asymmeyric encryption is not designed for static situations. As for the 4k chars, I ignore it: I try all RSA 3072 keys which takes only 134-ish bits or 16-20 chars. – eli Apr 01 '20 at 20:15
  • Hey @ThoriumBR, one last thing... the symmetric "session" key used to encrypt backup files - I generated it with `head -c 32 /dev/urandom`. Then I use it as the passphrase in `gpg --symmetric --passphrase SESSIONKEY ...`, correct? – lonix Apr 04 '20 at 17:56
  • Almost. pipe it to `base64` or `uuencode` first, or you will end up with non-printable and control chars on your passphrase. – ThoriumBR Apr 05 '20 at 12:45