1
$\begingroup$

Every day, I must backup my server's files, encrypt the backup, and upload it to untrusted cloud storage (dropbox, s3, etc.)

I've spent time on security.stackexchange where I discovered the typical approach is:

  • encrypt the backup with random one-time symmetric key ("session" key), for speed
  • encrypt the session key with an asymmetric key ("master" key: the public key in a public/private keypair)
  • upload the encrypted backup and encrypted session key to cloud storage

But I don't understand: why not use another symmetric key as the master key? Put another way: there is no key exchange here, as I am both "sender" and "receiver" - so how do I benefit from using an asymmetric key as master?

(For example, I'm using gpg, so my server could store a symmetric key with a 100-char passphrase, and use it to encrypt the daily session keys.)

Improve this question
$\endgroup$

1 Answer 1

Reset to default
2
$\begingroup$

Symmetric cryptography could well work here, to be honest.

The main advantage of public cryptography in this setting is that you can encrypt by just using a public key. So you'd get the following operations:

Setup:

  • create public / private key pair;
  • encrypt private key with password.

Encryption:

  • create random session key;
  • encrypt session key using public key;
  • encrypt data with session key and random nonce.

For decryption:

  • decrypt password-encrypted private key;
  • decrypt session key using private key;
  • decrypt data with session key using random nonce.

In other words, during encryption you don't need access to the private key and therefore you don't need a password either. You just need to make sure that you don't leak your temporary session key.

This seems to be particularly useful for backups where backing up is frequent and commonly automated, while the restoration is commonly manual and infrequent.

Notes:

  • the private key may also be otherwise protected, e.g. stored on a USB-stick or generated within a smart card (exporting the public key after key pair generation);
  • instead of deriving a key per session you might also want to generate a symmetric key per file - beware that some modes such as GCM have clear restrictions about the amount of data that can be processed by one key;
  • restoration is often too infrequent, don't forget to test your restoration initially and frequently thereafter.
Improve this answer
$\endgroup$
9
  • $\begingroup$ Is a 100 byte session key good enough? head -c 100 /dev/urandom $\endgroup$
    – lonix
    Apr 1, 2020 at 17:15
  • $\begingroup$ No, it's too much. A session key is a symmetric key and therefore only has to be between 128 to 256 bits or 16 to 32 bytes. You indeed spotted a mistake there - I moved from describing decryption to describing the public key encryption without updating the word in my mind :) $\endgroup$
    – Maarten Bodewes ♦
    Apr 1, 2020 at 17:17
  • $\begingroup$ Ok I'll use 32 bytes. Also this is the first time I've seen a recommendation to include a nonce - how large do you recommend to make it? I may be mistaken, but since each backup will be different, is the nonce really justified? (From what I remember, a nonce is used to make each plaintext dfferent, but every backup will always be different) $\endgroup$
    – lonix
    Apr 1, 2020 at 17:37
  • $\begingroup$ You need to use a nonce for every time you use the same key for a different encryption. If you create an archive and encrypt that with a different key each time then you don't need a nonce. Otherwise you do, basically. Either create / derive a new key each time or use a key + nonce; as long as the combination is unique. You can use a random nonce (again, within bounds, say 4 billion encrypts) and include it with the encrypted archive if necessary. $\endgroup$
    – Maarten Bodewes ♦
    Apr 1, 2020 at 17:44
  • $\begingroup$ Sorry to bother you again... I understand the theory now, but stumbled over the implementation... I hope you're familiar with gpg? I use it instead of openssl. When encrypting the files (gpg --symmetric ...) using a session key (head -c 32 /dev/urandom ), that session key is what I use for gpg's --passphrase, correct? Because the man pages mention to also use the --encrypt switch, but I assumed that was only for the asymmetric process. $\endgroup$
    – lonix
    Apr 4, 2020 at 17:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.