Bcachefs: Encryption
bcache.evilpiepirate.org
bcache.evilpiepirate.org
As a general rule, a key for one thing shouldn't be used for the other. However, one take some key material and calculate HMAC("ChaCha20", key material) and HMAC("Poly1305", key material) and use those keys for the two algorithms.
> Currently, the Poly1305 MAC is truncated to 64 bits - due to a desire not to inflate our metadata any more than necessary. Guidance from cryptographers is requested as to whether this is a reasonable option; do note that the MAC is not stored with the data, but is itself stored encrypted elsewhere in the btree.
I really think that's a poor idea. A 64-bit MAC provides 32-bit security (due to the birthday attack), which is … poor. You want at least 128 bits in a modern system, and perhaps even more.
You may wish to take a look at NSA's Suite B for good key & hash lengths.
I am not a cryptographer, nor have I read the rest of your proposal in-depth; those two comments just leapt out at me.
There are disk-encryption algorithms which may serve to provide low-level encryption, upon which you could build authenticated, encrypted storage by using MACs at a higher level (e.g. a MAC per file maybe?).
Please try not to roll your own encryption. It's frightening how easy it is to get this sort of thing completely wrong.
See also: HKDF
Don't give me the "don't roll your own encryption", I've been doing my homework and I've been very explicit about what I'm not confident enough to analyze myself.
If you're even suggesting a MAC per file, honestly you're not qualified here.
Cool project though.
The real joke is that the advice to not roll your own came with the poster's own half-baked suggestion...
If the comment was so canned and pointless then don't reply.
He's not rolling his own encryption. That advice dates from the mid-'90s when people were inventing their own block ciphers.
The state of the art in disk encryption technology is absymal, e.g, no MACs at all, just some voodoo block ciphers that maybe offer tamper-resistance. If you want to do this sort of thing properly, you must roll your own cryptosystem.
There's the significant danger that the "don't roll your own crypto" mantra has separated the crypto-implementing community into two groups: one that's too self-confident to listen to any advice, and one that's too afraid to do anything but use existing crypto code that's probably been written by group 1. That's basically the story of SSL today, for instance. Let's not let that be the case any more.
I have a few questions for you:
1. Do you have any other active contributors for the project?
2. Are you seeking any help besides donations?
3. What's your estimate for how long (and how active) can you maintain the development at the current level of support?
4. Do you have any roadmap with approximate dates?
Thank you for your work.
1: Not currently.
2: I'd love for people to jump in and help out - and I've asked. Besides working on the kernel code, help with things like documentation, userspace tools and the website would really make a big difference. But I'm ok with doing development by myself for now, it's not a dealbreaker.
3. Probably indefinitely, but I'm getting tired of eating ramen, you know? I'm working on bcachefs full time, and have been for quite some time.
4. For going upstream? That's a long ways off, for a variety of reasons - a big one is that I don't want to freeze the on disk format until the main features are at least mostly done, and finishing snapshots is quite a ways off.
But it's plenty stable enough to use now (what I'm hearing from users is that it already appears to be more solid than btrfs). Also, I think I'm going to prioritize multiple devices and replication (and possibly start on erasure coding) after I finish off compression, so that'll come sooner rather than later.
http://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/
This really explains the motivations for bcachefs's encryption - in the filesystem, if we're taking encryption into account in the design, we can incorporate MACs and nonces.
Looks cool, but it would be nice if there was a vision-like top-level description. I assume it will be a superset of bcache, so you could have an array of big slow spinning disks and a SSH writeback cache device.
(Besides the SSD cache persisting across reboots. ZFS has a patch in progress to fix that lack, so it won't last.)
TL;DR: it's based on a stable, pre-existing design (bcache) to avoid design bloat and ensure stability, it's much faster than the competition with similar feature sets (e.g. far lower latency than btrfs), it's very small and lean, and is extensible enough to support most of the common needs (COW, multi-device, replication, compression, encryption, etc etc). Also, bcachefs will hopefully land upstream in Linux and stay there, and unfortunately it seems ZFS will forever have to stay out of tree at this rate (of course, many distros make ZFS very easy to use these days, so if you're comfortable with it, just use that!)
I donated to the project and have been tracking it. I'm not sure how long it will take until Kent sends a request to pull in the code to the upstream kernel, but it's been progressing nicely lately.