Truncating SHA2 hashes vs shortening a MAC for ZFS Crypto

[Zooko Wilcox-O'Hearn]

On Wednesday,2009-11-04, at 7:04 , Darren J Moffat wrote:

> The SHA-256 is unkeyed so there would be nothing to stop an  
> attacker that can write to the disks but doesn't know the key from  
> modifying the on disk ciphertext and all the SHA-256 hashes up to  
> the top of the Merkle tree to the uberblock.  That would create a  
> valid ZFS pool but the data would have been tampered with.   I  
> don't see that as an acceptable risk.

I see.  It is interesting that you and I have different intuitions  
about this.  My intuition is that it is easier to make sure that the  
Merkle Tree root hash wasn't unauthorizedly changed than to make sure  
that an unauthorized person hasn't learned a secret.  Is your  
intuition the opposite?  I suppose in different situations either one  
could be true.

Now I better appreciate why you want to use both a secure hash and a  
MAC.  Now I understand the appeal of Nico Williams's proposal to MAC  
just the root of the tree and not every node of the tree.  That would  
save space in all the non-root nodes but would retain the property  
that you have to both know the secret *and* be able to write to the  
root hash in order to change the filesystem.

> So if I don't truncate the SHA-256 how big does my MAC need to be  
> given every ZFS block has its own IV ?

I don't know the answer to this question.  I have a hard time  
understanding if the minimum safe size of the MAC is zero (i.e. you  
don't need it anyway) or a 128 bits (i.e. you rely on the MAC and you  
want 128-bit crypto strength) or something in between.

Regards,

Zooko

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