Authenticated Btrfs

Posted May 1, 2020 6:46 UTC (Fri) by cyphar (subscriber, #110703)
In reply to: Authenticated Btrfs by flussence
Parent article: Authenticated Btrfs

ZFS has the same restriction (the checksum field in ZFS block pointers is 32 bytes long). The trick is that you take the first 16 bytes of SHA-256 and the first 16 bytes of HMAC-256, and the concatenation of both is your new 32 byte checksum. If you don't have the key, you can only verify half of the checksum but that is sufficient to detect data corruption. Obviously this is a workaround for fixed-size block pointers -- ideally you would just store both checksums.

to post comments

Authenticated Btrfs

Posted May 1, 2020 20:00 UTC (Fri) by dcg (subscriber, #9198) [Link] (1 responses)

In Btrfs it would be theoretically possible to add yet another tree to the forest, so you could have both a csum tree and a hmac tree (it may even be possible to shoehorn the hmac items into the csum tree in some way). But I'm not sure how valuable are these features for developers, btrfs has already been pretty disappointing when it comes to encryption.

Authenticated Btrfs

Posted May 1, 2020 20:15 UTC (Fri) by jeffm (subscriber, #29341) [Link]

It would be possible to modify the csum tree (or create a new tree) to do this for data, but metadata checksums are in the header for every tree node. Changing the size would be an incompatible disk format change. It's not impossible but it's a big barrier.