On Tue, Apr 07, 2020 at 12:02:30PM -0600, Chris Murphy wrote: > Hi, > > What's the status of this work? > https://lore.kernel.org/linux-btrfs/20191015121405.19066-1-jthumshirn@xxxxxxx/ > > Also I'm curious if it could use blake2b as an option? It's a bit > faster I guess. I don't have any objections against the feature but I don't find the specification complete enough, and there was no response when it was first sent. The feature itself is not something trivial or small-size so feedback is always welcome. It's happening now, which is great, and once we have the missing bits I'll go and merge it. My checklist so far: - blake2b needs to be supported as well - the HMAC must match the kernel implementation - naming of the new checksums (hmac-sha256 or hmac-blake2 should be ok) - key specification via mount option - all progs must work with filesystems with the keyed hash, so how to specify the auth key in a consistent way Usecase questions: - what to do if the key is not available, allow read-only mount, or provide rescue= option to ignore checksum failures? - support seeding device? And also document the the expected usecase and guarantees in case we ask somebody to do the crypto/security audit. As long as we use sandard primitives or components (eg. keyctl interface) it's the high-level usage that needs to be checked. The paper https://github.com/morbidrsa/btrfs-integrity-paper covers that, so that helps.
