Christoph Anton Mitterer wrote: > On Sat, 2014-11-29 at 13:00 -0800, John Williams wrote: >> On Sat, Nov 29, 2014 at 12:38 PM, Alex Elsayed <eternal...@gmail.com> >> wrote: >> > Why not just use the kernel crypto API? Then the user can just specify >> > any hash the kernel supports. >> >> One reason is that crytographic hashes are an order of magnitude >> slower than the fastest non-cryptographic hashes. And for filesystem >> checksums, I do not see a need for crypotgraphic hashes. > > I'm not that crypto expert, but wouldn't the combination of a > cryptographic hash, in combination with e.g. dm-crypt below the > filesystem give us what dm-crypt alone cannot really give us > (authenticated integrity)? > > Would that combination of hash+encrypt basically work like a MAC?
Sadly, no. Partially because in order for an encrypted hash to be a secure MAC, the encryption must be nonmalleable, which would require CMC or EME - encryption modes which Linux does not presently support as I understand it. There are other issues as well, including that MAC-then-encrypt is fragile against a number of attacks, mainly in the padding-oracle category (See: TLS BEAST attack). AEAD modes are also nonmalleable, but as they are length-expanding they cannot be used for LUKS. However, as eCryptFS and possibly the recent ext4 encryption work shows, using them at a higher-level (encrypting extents or files) does work. Of course, if you're using an AEAD mode in the filesystem anyway, just use it directly and have done with it. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
