Truncating SHA2 hashes vs shortening a MAC for ZFS Crypto

[Zooko Wilcox-O'Hearn]

following-up to my own post to clarify something important and add  
some further ideas

On Tuesday,2009-11-03, at 9:32 , Zooko Wilcox-O'Hearn wrote:

> 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.

Important note: GCM does *not* have the security properties that you  
expect from a truncated MAC tag: [1, 2].  If you're relying on the  
MAC tag for integrity (i.e., if the SHA256 tag is truncated to be  
short or if the user is allowed to run with an insecure checksum),  
then you must use a sufficiently large MAC tag.

It seems like the IV field could be mostly or completely optimized  
out by generating the IV at runtime from other data which is  
guaranteed to be unique for this version of this block.  Note that  
you really should use a unique IV on *every write* of the block --  
i.e. for every unique block's worth of plaintext -- and not re-use  
the same IV for successive contents of the same block.  Do you  
already do that?

Looking at [3] I don't see anything that obviously fits the bill.   
The Birth Transaction ID uniquely identifies this block as far as I  
understand, but nothing uniquely identifies this particular version  
of this block.  So maybe you could make the IV be the (64-bit) Birth  
Transaction ID plus a  64-bit counter which gets incremented on every  
write and is stored in the place where you are currently storing an  
IV.  That counter could roll-over, in the hopes that someone who  
steals your ciphertext and wants to learn something about your  
plaintext doesn't have a copy of your ciphertext from 2^64 versions  
ago.  Of course, a larger counter would be better, if you can fit it in.

Regards,

Zooko

[1] http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/CWC- 
GCM/Ferguson2.pdf
[2] http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/CWC- 
GCM/gcm-update.pdf
[3] http://opensolaris.org/os/community/zfs/docs/ondiskformat0822.pdf
---
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