Hello
BackBlaze storage has server side encryption.
(i) Does that mean that I can use duplicati without encryption - reducing resources on my machine?
(ii) Though not sure how managing own encryption keys (SSE-C) on blackblaze which is supposed to be done at file upload - how does that work with duplicati?
Server-side Encryption: Keys to More Protection announced it four days ago. Some answers are TBD.
I’ve definitely not tried it, but anybody who has, or is interested in trying it, is invited to share experience.
Volunteers with coding expertise are also invited to add support that the more secure usages will need.
At the high level, the question is whether you are satisfied with that security, and as you can see, there are variations. The setup where only the client knows the key is most secure but a disaster if you lose the key.
That’s true of Duplicati encryption too – don’t lose the passphrase (or connection info, or other essentials). Exporting a backup job configuration can help with that.
A next question is whether Duplicati (or Duplicati plus some help from other mechanisms) can get this up.
The document you link to talks mostly about extensions to original B2 APIs which are what Duplicati uses.
I’m not a B2 code expert but I think anything you see there needing new headers or JSON won’t work now.
This would be a good question for Backblaze support – you have a program that hasn’t yet added anything to support the new features. What can you get? Ask that for both B2 and S3 APIs. Duplicati’s S3 uses the Amazon SDK or the MinIO SDK. Before asking, please also study Server-Side Encryption FAQ that writes:
If a bucket has default encryption turned on, are the encryption headers in an API call required to upload a file and have it stored encrypted?
No.
So if you’re willing to accept the lower level of security, the answer to your first question seems to be “yes”.
My initial thought is that it doesn’t. B2 was mentioned earlier (also see here) as Duplicati code not having support for new Backblaze feature yet. S3 uses standard libraries such as Amazon’s, but info isn’t given.
PutObjectRequest has an enormous list of things that it can accept if the program wishes. Duplicati uses:
CISSP, CISM, etc. recommendation here: Encryption with keys someone else manages serves you not one bit.
If you want to protect the confidentiality of your data, encrypt it yourself. There’s really no shortcut.
Second your view here.
Never send the keys to any third party is my view. Keep one set for use and then encrypt a disk with a known but crazy complex passcode and store a second set of your keys on it. Then tuck this disk by itself into a safe deposit box somewhere.
Doesn’t that depend on the provider’s security design, and key management practices and controls?
Backblaze doesn’t detail their design, but an attacker would need to get not only the data, but the key.
Encryption at rest in Google Cloud explains what Google Cloud does, for example, and it’s quite a lot.
I’m picking at the “not one bit” part, but think that good confidentiality takes a lot and it still isn’t perfect.
In a word, nope.
Longer answer: what the hucksters of server-side encryption leave out is the threat model. In order to protect your data you have to have a clear concept of just what you’re protecting it against. So: server-side encryption. The threat it’s protecting you against is… what? That someone will break into their physical data center and steal the actual disks your data is on? OK, I guess that probability is not zero. But it’s not the one that’s gonna be keeping me up nights.
In order to be doing anything – anything at all! – with your data it has to be in a decrypted state. That means the keys to decrypt it (or at least a service that provides decryption of it) are available to people accessing the data store from a network-based process. This applies to legitimate users and remote attackers alike.