----- Ursprüngliche Mail ----- >> The hash algorithm needs to be passed as a mount option. Otherwise the attacker >> gets to choose it for you among all the supported keyed hash algorithms, as soon >> as support for a second one is added. Maybe use 'auth_hash_name' like UBIFS >> does? > > Can you elaborate a bit more on that? As far as I know, UBIFS doesn't > save the 'auth_hash_name' on disk, whereas 'BTRFS_CSUM_TYPE_HMAC_SHA256' > is part of the on-disk format. As soon as we add a 2nd keyed hash, say > BTRFS_CSUM_TYPE_BLAKE2B_KEYED, this will be in the superblock as well, > as struct btrfs_super_block::csum_type. Well, UBIFS stores auth_hash_name on disk but does not trust it. It is always required to provide auth_hash_name as mount parameter. At mount time it is compared to the stored name (among with other parameters) to detect misconfigurations. Thanks, //richard
