On Thu, Nov 6, 2008 at 11:31 AM, Florian Weimer <fweimer@xxxxxx> wrote: > * Gregory Maxwell: > >> I noticed in the compression support that the checksum is over the >> uncompressed data. >> >> While this has the advantages that the checksum does not have to be >> changed as transformations are changed and the system might catch >> errors in the compression layer, this design decision will be >> problematic if/when encryption is supported: Plaintext checksums >> would leak substantial amounts of information about the content of >> files. > > Would this be an issue if metadata (including file names) were > encrypted as well? If the checksum is encrypted, no, at least not obviously. But as I've mentioned if the checksum is encrypted then you can't scrub the FS for checksum errors without the keys. A lack of metadata encryption would be another possible information leak, but at least it's one which can probably be understood by users. It would be nice if subvolume level encryption provided metadata encryption. If metadata is encrypted but block checksums are unencrypted and on plaintext then information will leak about the files, even if the checksum is replaced with an unkeyed or non-secret-keyed cryptographic hash, a secret-keyed hash is equivalent to an encrypted checksum. -- 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
