I'm not sure why you'd want PFS for backups. The idea of backups is that you have a history (not just a simple mirror) and so having PFS intentionally renders older backups unusable (unless you're storing all the keys -- in which case you have somewhat defeated the point of PFS).
Now, PFS would allow you to handle key compromise by making future backups unreadable. But there are other solutions for this (such as upgradeable encryption).
I'm currently writing my own backup tool because of one feature I want that nothing else seems to have. In my opinion, it's not enough to distrust the server where the backups are stored. The client should also not need to keep around a key that can be used to decrypt the backups for the purpose of encrypting new backups.
This is quite easy to accomplish with public key cryptography - just use a new, random AES key for each backup job, then encrypt that with a public key you keep around. The private key can be stored offline in cold storage.
Backups are much more practical to encrypt and put in the cloud than the software you're actively using. Though hopefully the software we're actively using can be encrypted too.
Every client would need to make its own backups, automatically. In such a situation it would be probably best to have two backups, those plus a backup of the encrypted data for the clients that fail to do the backups on their own. But you raise a good point: That's difficult to do.
Something about the idea of being able to back things up on multiple remote target storage services sounds extra compelling. Simple encryption with robust backup for e.g. text notes.
Backups of keys are a lot smaller and fit on USB flash drives and CDs. So in practice keeping encrypted backups with multiple keys is easier to deal with
What's even more important, you will be able to encrypt your backups without having to disclose the encryption key in case you ever need to restore (client-side encryption and decryption). This is not the case with Backblaze, which is why I switched to CrashPlan — but I'm still looking for other solutions.
Asymmetric crypto for backups feels overrated to me.
The "write-only mode" argument makes sense, if the backup target holds data from other nodes, but that doesn't require asymmetric crypto.
The "shouldn't be able to read own backups by default because what if it's hacked" argument doesn't seem to hold much water to me, because the most valuable secrets will generally be those in active use on the machine.
A seccond PW manager? Not necessary, an offline backup? Great idea. Most PW managers allow you to export in some way shape or form. Doing so and encrypting said file is a great idea, but also something that's hard to do enough for most people that I don't have a good solution.
Now, PFS would allow you to handle key compromise by making future backups unreadable. But there are other solutions for this (such as upgradeable encryption).
reply