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.gpgfile. 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):
- create the backup
2020-01-01.backup.tar.bzip2(date is just an example)
- generate a random passphrase, and save it as
2020-01-01.passphrase.txtwith my "master" passphrase (which I keep on my local box) to get
2020-01-01.passphrase.txt.gpgto 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?