5 ms·

Bcachefs: Encryption

66 points by koverstreet 10y ago

ZoomZoomZoom 10y ago
Kent, I was really exited when I first heard of Bcachefs, so I'm a bit surprised of the lack of public discussion of your work. 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.
- koverstreet 10y ago
  Hey, thanks. 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.
wscott 10y ago
This is the first I have heard of bcachefs, and I have used bcache on one of my servers for years. https://bcache.evilpiepirate.org/Bcachefs/ https://bcache.evilpiepirate.org/Bcachefs/ 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.
- Veratyr 10y ago
  The Patreon has a better description I think: https://www.patreon.com/bcachefs https://www.patreon.com/bcachefs
jerguismi 10y ago
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,
- koverstreet 10y ago
  Once I finish replication, yes. It's fairly high on the list.
- king_phil 10y ago
  We use 2x SSD and 2x HDD in Adaptec HW RAIDs and then use bcache to speed up the HDD RAID with the SSD RAID.
webaholic 10y ago
This is a really good project in need of funding for the author. If you are in a position to help, please donate: https://www.patreon.com/bcachefs https://www.patreon.com/bcachefs.
- wscott 10y ago
  That patreon page has a MUCH better description of the project and its goals.
  - redwards510 10y ago
    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!
Filligree 10y ago
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.)
- aseipp 10y ago
  The Patreon page has a very good overview: https://www.patreon.com/bcachefs https://www.patreon.com/bcachefs 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.
  - rleigh 10y ago
    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.
zeveb 10y ago
> 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.
- CiPHPerCoder 10y ago
  > 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. See also: HKDF
- koverstreet 10y ago
  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.
  - 10y ago
tobias3 10y ago
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.
koverstreet 10y ago
Excellent article just posted in the thread about OpenBSD disk encryption that explains why existing disk encryption schemes suck: http://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/ 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.

66 points by koverstreet 10y ago

Kent, I was really exited when I first heard of Bcachefs, so I'm a bit surprised of the lack of public discussion of your work. 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.

koverstreet 10y ago
Hey, thanks. 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.

wscott 10y ago

This is the first I have heard of bcachefs, and I have used bcache on one of my servers for years. https://bcache.evilpiepirate.org/Bcachefs/ https://bcache.evilpiepirate.org/Bcachefs/ 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.

Veratyr 10y ago
The Patreon has a better description I think: https://www.patreon.com/bcachefs https://www.patreon.com/bcachefs

jerguismi 10y ago

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,

koverstreet 10y ago
Once I finish replication, yes. It's fairly high on the list.
king_phil 10y ago
We use 2x SSD and 2x HDD in Adaptec HW RAIDs and then use bcache to speed up the HDD RAID with the SSD RAID.

webaholic 10y ago

This is a really good project in need of funding for the author. If you are in a position to help, please donate: https://www.patreon.com/bcachefs https://www.patreon.com/bcachefs.

wscott 10y ago
That patreon page has a MUCH better description of the project and its goals.
- redwards510 10y ago
  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!

Filligree 10y ago

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.)

aseipp 10y ago
The Patreon page has a very good overview: https://www.patreon.com/bcachefs https://www.patreon.com/bcachefs 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.
- rleigh 10y ago
  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.

zeveb 10y ago

> 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.

CiPHPerCoder 10y ago
> 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. See also: HKDF
koverstreet 10y ago
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.
- 10y ago

tobias3 10y ago

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.

koverstreet 10y ago

Excellent article just posted in the thread about OpenBSD disk encryption that explains why existing disk encryption schemes suck: http://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/ 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.