Using unique per-session gpg keys to store backups on cloud storage

Question

I'd like to encrypt my server's daily backups and send them to dropbox / google drive / etc., as a backup.

I've read of various approaches. Assuming symmetric encryption (passphrase rather than public/private keypair), people seem to: tar, compress, encrypt with a passphrase (using gpg), and upload the result to cloud storage.

Then I found this comment (edited for brevity):

I wouldn't use the same passphrase over and over to encrypt your files. Instead, I'd generate a file containing a number of random bytes and use that as a key for my .tar.bz2.gpg file. I'd then encrypt this random file with my 100 character passphrase and upload it together with the backup file. (Basically, I'd create a session key with which to encrypt my data and use the 100 character string as a master key to decrypt the session keys). You can automate this, and it gives you forward secrecy in case one of your backup session keys is compromised and the ability to decrypt any specific backup without losing control over your master key.

So if I understand correctly, for every backup I must (via a bash script):

1. create the backup 2020-01-01.backup.tar.bzip2 (date is just an example)
2. generate a random passphrase, and save it as 2020-01-01.passphrase.txt
3. use 2020-01-01.passphrase.txt to encrypt 2020-01-01.backup.tar.bzip2 to get 2020-01-01.backup.tar.bzip2.gpg
4. encrypt 2020-01-01.passphrase.txt with my "master" passphrase (which I keep on my local box) to get 2020-01-01.passphrase.txt.gpg
5. upload 2020-01-01.backup.tar.bzip2.gpg and 2020-01-01.passphrase.txt.gpg to cloud storage

The above comment says this is more secure because if one backup/passphrase is compromised, the others are still safe as they use different passphrases.

But I'm a little confused. If the master passphrase is compromised ("hacked" / guessed / whatever) - all the backups are compromised. It seems like just another level of indirection.

The only way this makes sense is if the master passphrase is MUCH longer (more entropy) than each session passphrase - e.g. 100 characters vs 20 characters, respectively. But then why not just make every session passphrase 100 characters?

Is my understanding of this strategy correct, and can you detect any gotchas I should take into account?

Answer 1

But I'm a little confused. If the master passphrase is compromised ("hacked" / guessed / whatever) - all the backups are compromised. It seems like just another level of indirection.

It's not another indirection, it's another lock the attacker have to pick before entering the safe. It's like having lots of small safes, and another safe well hidden somewhere else, with each little safe's combination. The attacker don't know about every combination is unique unless he successfully opens one and tries the same combination on the others, and don't know where the master combination is stored.

The reason to have a symmetrical key for each backup and one strong asymmetric master key is that you will rarely use the private master key, so it can be very long, be stored offline and be well defended. Security is always a trade-off against usability, and in this case, you can dial all the way to security, like splitting the key in lots of segments and use Shamir's Secret Sharing to store it on various places.

The public key will be used every day, but it is not of much concern. You would not paste it on the home page of your site, but you don't have to be paranoid about it either.

Usually, password leaks are due to human error, not failures on the tech side. Having only one key protecting all your backups means you are one mistake away from compromising every single backup. Having multiple keys you can compartmentalize the data, and the errors can be more contained.

Is my understanding of this strategy correct, and can you detect any gotchas I should take into account?

I believe your strategy is correct. The most important thing you must take into account is to keep the private key well protected, and never lose it. Leaking the private key means all backups can be compromised, losing it makes all backups irrecoverable.