Not to mention, the state of Linux filesystems in general. I don't really follow that field, the last thing I remember reading is Ars Technica articles about how btrfs was going to change everything. I've been kind of wondering what happened to that!
> The current design uses the same key for both ChaCha20 and Poly1305, but my recent rereading of the Poly1305-AES paper seems to imply that the Poly1305 key shouldn't be used for anything else. Guidance from actual cryptographers would be appreciated here; the ChaCha20/Poly1305 AEAD RFC appears to be silent on the matter.
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.
> Please try not to roll your own encryption. It's frightening how easy it is to get this sort of thing completely wrong.
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.
Birthday attack doesn't apply here; the HMAC an attacker would be trying to collide with is fixed and stored elsewhere, encrypted.
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.
Nobody got hellbanned, and the response was less than reasonable as you can well see. Even more so given that the post was asking for feedback. The only content was that the birthday attack doesn't apply.
If the comment was so canned and pointless then don't reply.
> 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.
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.
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 like quite a cool project... Would it be possible to have for example 2xSSD and 2xHDD raid mirror setup with this? I mean trying to achieve good performance, capacity and data safety at the same time,
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.
How does this compare to ZFS? There seems to be some significant overlap in functionality, but ZFS is more mature, so I'm wondering if bcachefs has charm points I'm unaware of.
(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.
While what you wrote was interesting, none of it directly answers any of the questions in the post you followed up to. It would be appreciated to have some answers to what was asked.
I think there are plans for send/receive of encrypted ZFS datasets, which would be really useful for offsite-backup to untrusted (or less trusted) storage. I know it will be a while till you get around to implementing send/receive in bcachefs, but just wanted to mention that in case you want to change the encryption design to enable that in the future.
