On Tue, May 05, 2020 at 03:31:20PM -0700, Eric Biggers wrote: > > Using that example, the authenticated checksum cannot be subverted on > > the superblock. So even if there are untrusted superblock data used, it > > won't even pass the verification of the superblock itself. > > You're missing the point. For unkeyed hashes, there's no need to provide the > hash algorithm name at mount time, as there's no authentication anyway. But for > keyed hashes (as added by this patch) it is needed. If the attacker gets to > choose the algorithms for you, you don't have a valid cryptosystem. I think we need to be more specific as I don't see how this contradicts what I've said, perhaps you'll show me the exact point where I missed it. An example superblock contains: u8 checksum[32]; int hash_type; u8 the_rest[256]; The checksum is calculated from offsetof(hash_type) to the end of the structure. Then it is stored to the checksum array, and whole block is stored on disk. Valid superblock created by user contains may look like: .checksum = 0x123456 .hash_type = 0x1 /* hmac(sha256) */ .the_rest = ...; Without a valid key, none of the hash_type or the_rest can be changed without producing a valid checksum. When you say 'if attacker gets to chose the algorithms' I understand it as change to hash_type, eg. setting it to 0x2 which would be hmac(blake2b). So maybe it violates some principle of not letting the attacker choice happen at all, but how would the attack continue to produce a valid checksum?
