3 ms·
My issue with their encryption scheme is that although you can encrypt your private key before sending it to them, during restore, you still need to hand them t
by red0point 5y ago
My issue with their encryption scheme is that although you can encrypt your private key before sending it to them, during restore, you still need to hand them the unencrypted private key.
This feature is thus pure security theatre.
You gain nothing - the provider may still access your data at some point (yes, they only "fly-by fast on a super-secure-server"), but still lose the ability to restore without the password.
The thing is, it wouldn't be hard to do the decryption during restore on the client. Why haven't they done this in all these years?
- detaro 5y agoyeah, even if you accept the premise of "we need to backup the key for users" (which I'd still prefer to be optional), that is just WTF.
- csnover 5y ago> you can encrypt your private key before sending it to them You can’t even do that! Setting a PEK passphrase sends it to Backblaze. It has to[0]: your private key exists only on their servers. As you say, the entire feature is basically a lie. [0] I mean “has” in the sense that they deliberately designed it this way. Obviously there are plenty of ways to design this that don’t involve sending your password.
- detaro 5y agoIt doesn't have to (and according to the linked page doesn't until a restore), since the private key isn't needed to backup files. If it instead let you fetch the encrypted private key for a restore, it'd be a lot better already.
- csnover 5y agoI’m just telling you what their client actually does based on a previous analysis I conducted, not the claims of their documentation. The private key is auto-generated by the Backblaze Client installer and gets sent to their server at install time. This is done before the user has any choice to set a passphrase. Setting a passphrase later does not generate a new keypair, it just sends that passphrase to their server so the server can re-encrypt the private key using the new passphrase. Because the key is uploaded at install time and doesn’t ever change, they already have the private key in unencrypted form. When a user tries to protect it, now they also have the user’s passphrase. There is no technological way by which “PEK” shields your data from Backblaze, even at rest, as implemented.