Re: [PATCH] btrfs-progs: docs: add warning for btrfs checksum features

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

On Fri, 2025-11-21 at 17:14 +1030, Qu Wenruo wrote:
> 
> Adding linux-crypto list for more feedback.

It would be good if any of them could confirm or reject:

- Whether a filesystem that uses full checksumming (data + meta-data)
and that is encrypted with dm-crypt,... is effectively integrity
protected like it would be with an AEAD.

In particular also:

- Whether this requires a strong cryptographic hash (or as Qu presumed,
any hash would do) and whether the hashing is needed to be done as a
Merkle-tree or whether that's not needed

- Whether, if one uses such a fs, AEAD or dm-verity is even
recommended, or just a waste of resources as the checksumming done by
the fs would already be enough.


> > The question IMO is, whether a (dm-crypt) encrypted btrfs that uses
> > a strong hash function for btrfs (i.e. like hash-then-encrypt)
> > would be effectively integrity protected.
> 
> In that case, I can not give a concrete answer, but I tend to believe
> it's protected, and no matter what the algorithm is (including
> CRC32C).

I'd rather not think CRC would be enough... I mean why would all crypto
use strong hash algos for signatures, if it could also be done with
fast CRC.


> - For metadata
>    The bytenr will mismatch, thus be rejected.
> 
>    This prevents csum tree from bing modified.

But meta data *is* still checksum protected right (i.e. it doesn'thave
only the bytenr).

Maybe, if someone from the crypto guys has a look, you could outline
them how the exact hashing structure looks for btrfs.... like is it a
full Merkle-tree starting from the super block, what about super block
copies, etc. pp. 


Thanks,
Chris.