is cryptographically secure integrity checking possible with btrfs?

[Christoph Anton Mitterer <calestyo@scientia.net>]

[-- Attachment #1: Type: text/plain, Size: 2587 bytes --]

Hey.

For encryption we have dm-crypt and in principle I'm happy with having
that at the block device level below the filesystem - perhaps except for
any possible performance issues, especially when used with software RAID
(regardless of whether MD or btrfs')[0].

But obviously integrity protection is still missing... and I guess for
many people this would actually be much more interesting than
encryption.


Now as far as I understand btrfs, everything, data and metadata is
checksummed (right now only with CRC32, but enough space would be left
for something "better"). And further, these checksums are verified on
each read.

Are these checksums chained? I.e. when a datablock is written/changed,
not only its checksum is affected, but also those of all meta-data
blocks up to the super blocks?

If so, one could perhaps use this like git for integrity protection.

For example when unmounting a btrfs filesystem, it could print the final
checksum of the superblock.
The user could store this on some safe device (for the paranoid one e.g.
on a USB stick that always travels along and that by coincidence also
contains boot loader, kernel+initrd and the dm-crypt keys necessary to
decrypt the fully encrypted system).


On mount one could then specify the expected checksum for the
superblock. If it differs already, then the mount should obviously fails
right away (or try backup superblocks and that like, but again only use
them if they match the sum).

Obviously one would also need an operation mode in which btrfs dies with
bells and red signs as soon as something (data or metadata) is read
afterwards, which doesn't match the expected checksums.
again, RAID copies, etc. could of course be tried - but if no valid copy
is found, then it should assume compromise and the read operation should
error out and not deliver any data at all (it may be compromised and
nothing should use it).

Of course people might still want to read such "compromised" blocks
(e.g. when they are sure that they've only suffered from accidental data
corruption and try to rescue as much as possible), but that should then
require a special mount option.


Well I'm not that crypto expert,... and btrfs would probably at least
need more than CRC32.
Unfortunately the 512bit version of Keccak wouldn't fit in, would it? ;)


Cheers,
Chris.


[0] Does anyone know the current status of this? When I have say a btrfs
RAID6 with n disks, each actually being a dm-crypt device... will this
run all in one IO thread killing the performance?

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5313 bytes --]