[adding cc: zfs-crypto-discuss at opensolaris.org] David-Sarah:
Yes, a secure hash of the plaintext might give better assurance than a secure hash of the ciphertext, because the implementation of the cipher could be buggy or because the decryption key could be wrong. The latter problem could perhaps be addressed by appending the encryption key to the plaintext before encryption. But my point was about something else: that hashes are actually sometimes more robust than MACs from a security engineering standpoint even though MACs are much stronger than secure hashes from a crypto standpoint. I think your reply best summarized what I was trying to say: On Monday,2009-11-02, at 23:31 , David-Sarah Hopwood wrote: > Right. If hashes are used instead of MACs, then the integrity of > the system does not depend on keeping secrets. It only depends on > preventing the attacker from modifying the root of the Merkle tree. > One consequence of this is that if there are side-channel attacks > against the implementations of crypto algorithms, there is no > information that they can leak to an attacker that would allow > compromising integrity. Yes, and in addition to side-channel attacks and theft of the key, there is also the simple fact that with a secure hash you can give a person or process the ability to verify the integrity of data without thereby giving them the ability to forge data. With a MAC, you can't. The way this might be relevant to ZFS is that they have these constraints on how much space they have to store crypto material, and they have these issues about integrity and about dedupe, and they *already have* a SHA-256 hash of the ciphertext! So it would seem to me that they should leverage that powerful feature that they already have: don't allocate a lot of bits to the MAC tag which is mostly redundant. Maybe just allocate 32 bits to it, and think of it as a double-check that you have the right key and that your AES implementation is working right. Also, of course, require that the checksum is SHA-256 and not one of the faster, insecure checksums. Also encourage users (as Jeff Bonwick has already done on his blog [1]) to set dedupe to act solely on hash tags and not do a full comparison of block data. > (Of course, the integrity of the OS also needs to be protected. One > way of doing that would be to have a TPM, or the same hardware that > is used for crypto, store the root hash of the Merkle tree and also > the hash of a boot loader that supports ZFS. Then the boot loader > would load an OS from the ZFS filesystem, and only that OS would be > permitted to update the ZFS root hash.) Wow -- that is a good idea! Regards, Zooko [1] http://blogs.sun.com/bonwick/en_US/entry/zfs_dedup --- Your cloud storage provider does not need access to your data. Tahoe-LAFS -- http://allmydata.org
