Thanks for entertaining my comments. On Thu, Nov 6, 2008 at 9:40 AM, Chris Mason <chris.mason@xxxxxxxxxx> wrote: > For encryption we have a few choices. We can checksum the encrypted > blocks and disallow compression, or we can use a stronger checksum. [snip] The first sounds viable, although mutually exclusive features aren't very user-friendly. The latter would need to be a probably need to be a secret-keyed HMAC to prevent watermarking attacks and information leakage, I don't think simply salting with the sector number or other public information would be sufficient: I could still take your encrypted disk and answer the question "Does Chris have block X?" by checking the checksums. But if the checksum is a keyed transform we can't sweep the file-system for bit-rot without having all the keys available. I expect the common use case for encrypted btrfs is similar to eCryptfs where each user may have their own keys which are only available when they are logged in (single key whole disk encryption can still be easily done with a dmcrypt). So having all the keys at once may not be especially realistic. But being able to scan for failing blocks is important in catching errors before there is too much damage. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
