
Bcachefs: Encryption - koverstreet
https://bcache.evilpiepirate.org/Encryption/
======
webaholic
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
That patreon page has a MUCH better description of the project and its goals.

~~~
redwards510
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!

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

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

~~~
orf
That is a terrible comment to make and comes across as overly hostile to
someone who is only trying to help.

Cool project though.

~~~
EdHominem
How HN. Someone offers canned advice and the project maintainer's reasonable
response gets hellbanned.

The real joke is that the advice to not roll your own came with the poster's
own half-baked suggestion...

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

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

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

------
jerguismi
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,

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

------
wscott
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
The Patreon has a better description I think:
[https://www.patreon.com/bcachefs](https://www.patreon.com/bcachefs)

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

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

