0

I need to encrypt daily backups, then upload them to untrusted cloud storage (s3, dropbox, etc.)

I received help on security.se and crypto.se to formulate this approach:

  • tar and xz the backup file
  • create random 32 byte (symmetric) "session" key (head -c 32 /dev/urandom)
  • encrypt backups using session key
  • encrypt session key using my "master" (asymmetric) keypair's public key
  • upload encrypted backup file and encrypted session key

Result:

  1. Every backup has unique symmetric session key
  2. Only my master keypair's private key can decrypt session keys
  3. My private key is stored locally only
  4. Encryption process is completely automated; no passphrases required

However then I tried to implement this with gpg and stumbled over some items.

Once I generate a session key, how do I use it? I thought it was supposed to be the passphrase in gpg --symmetric --passphrase $SESSION_KEY ..., but apparently that's not how it's done.

I did more digging and discovered that gpg does almost everything symmetrically, and that a session key is already generated and included in each encrypted file automatically (in the header). So most of the above is done automatically for me.

So, how do I use the session key (if at all)? I understand the theory, but not how to implement it with gpg.

lonix
  • 363
  • 3
  • 11

1 Answers1

1

You don't need to do anything with the session key. Like you said, GPG is already using hybrid encryption; generating a symmetric session key and using it to encrypt the data, then encrypting the session key with the recipient's public key.

You could devise a more intricate method like you describe, but I believe GPG alone should be sufficient unless you truly can't handle the GPG key as a single point of failure.

multithr3at3d
  • 12,355
  • 3
  • 29
  • 42
  • Thanks. So with gpg my "approach" above is reduced to: "create backup file", "encrypt backup file with master public key", "upload" ? – lonix Apr 06 '20 at 04:16
  • Yes. I suppose you could also generate subkeys that have a shorter expiration to limit the damage of one key becoming compromised, but that's optional. – multithr3at3d Apr 06 '20 at 23:31