Truncating SHA2 hashes vs shortening a MAC for ZFS Crypto

[Zooko Wilcox-O'Hearn]

[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

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com