4 ms·
> 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
by 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.