Hacker News Reader

Comment by ansible | Hacker News Reader

Well, that is interesting.

I'm curious that they're talking about implementing encryption at the filesystem layer. This has typically been done elsewhere. And anyway, key management is an issue. Seems like it would be beyond the scope for a filesystem. But I had similar thoughts right before I started learning about the write anywhere layout used by NetApp all those years ago, where mixing layers had enormous benefits (ZFS too).

The idea of incorporating a flash translation layer (FTL) is interesting, but there is the hardware support issue. Meaning that yes, you can still buy raw NAND flash memory, but what are you going to connect it to? NAND flash controllers which can present a useful interface to the host processor (like USB) already incorporate a FTL.

Similarly, eMMC memory has a FTL layer baked in, and presents itself as a block-addressable device.

Raw NAND flash controllers are increasingly rare on modern microcontrollers.

View on HN

A really good reason to use encryption at the filesystem level is that you can use stream ciphers instead of block ciphers (because you have a place to store nonces). The current disk encryption is based on XTS, which has a section in wikipedia on it's weaknesses [1].

[1] https://en.wikipedia.org/wiki/Disk_encryption_theory#XTS

ZFS encryption works in a similar fashion, and ext4 also has encryption (which is used by default in Android).

Personally I'm not a huge fan of this because unlike the clear benefits of giving filesystems control over raw devices, full disk encryption has requirements that can't really be provided partially. You want to ensure no metadata about the filesystem structure or files will be known without knowing the encryption key but this is clearly not possible without having block device layer encryption. ZFS encryption allows for all sorts of useful operations on encrypted filesystems without having the key. This is cool, but also obviously provides a lot of information about the filesystem structure. Also dedup tables aren't encrypted in this setup. ext4 only encrypts filenames and contents, which is worse in some respects.

The only metadata stored in the clear in bcachefs is the superblock and the very first part of the btree node and journal entry headers - just the checksum, magic number (identifying it as a btree node/journal header), and a flags field which mainly contains the checksum/encryption type.

So an attacker can tell roughly how much metadata you have, but literally nothing about the contents.

> Also dedup tables aren't encrypted in this setup.

This sounds like low-hanging fruit for a security researcher to try their hand at: comprehend the dedupe table format, and see what you can derive from it (basically the real-world version of https://xkcd.com/704/).

> the write anywhere layout used by NetApp all those years ago

I've never heard of "write anywhere" before but it sounds interesting. What is/was this?

> ... incorporating a flash translation layer (FTL) is interesting, but ... what are you going to connect it to? NAND flash controllers ... already incorporate a FTL. ... Raw NAND flash controllers are increasingly rare on modern microcontrollers.

My read of the FTL bit is that of hopeful optimization that supports the ideal-case - say, the filesystem equivalent of all the revving-up everyone is doing to support RISC-V. It's clearly leaning pretty heavily on the bit about existing precedent. My practical hope is that the code stays in good, well-tended condition up to the point it can be usefully taken advantage of - and that someone notices it to good effect sooner rather than later.

> I've never heard of "write anywhere" before but it sounds interesting. What is/was this?

https://en.wikipedia.org/wiki/Write_Anywhere_File_Layout

Reply on news.ycombinator.com