Re: Questions about encryption and (possibly weak) checksum

[Eric Biggers <ebiggers@kernel.org>]

On Fri, Nov 21, 2025 at 08:28:38AM +1030, Qu Wenruo wrote:
> Hi,
> 
> Recently Daniel is reviving the fscrypt support for btrfs, and one thing
> caught my attention, related the sequence of encryption and checksum.
> 
> What is the preferred order between encryption and (possibly weak) checksum?
> 
> The original patchset implies checksum-then-encrypt, which follows what ext4
> is doing when both verity and fscrypt are involved.
> 
> 
> But on the other hand, btrfs' default checksum (CRC32C) is definitely not a
> cryptography level HMAC, it's mostly for btrfs to detect incorrect content
> from the storage and switch to another mirror.
> 
> Furthermore, for compression, btrfs follows the idea of
> compress-then-checksum, thus to me the idea of encrypt-then-checksum looks
> more straightforward, and easier to implement.
> 
> Finally, the btrfs checksum itself is not encrypted (at least for now),
> meaning the checksum is exposed for any one to modify as long as they
> understand how to re-calculate the checksum of the metadata.
> 
> 
> So my question here is:
> 
> - Is there any preferred sequence between encryption and checksum?
> 
> - Will a weak checksum (CRC32C) introduce any extra attack vector?

If you won't be encrypting the checksums, then it needs to be
encrypt+checksum so that the checksums don't leak information about the
plaintext.  It doesn't matter how "strong" the checksum is.

- Eric