Truncating SHA2 hashes vs shortening a MAC for ZFS Crypto

[Zooko Wilcox-O'Hearn]

[Folks, I don't seem to be getting messages from zfs-crypto-discuss  
so I am reading the web archives of zfs-crypto-discuss and replying.]

in http://mail.opensolaris.org/pipermail/zfs-crypto-discuss/2009- 
November/002951.html Darren Moffat wrote:

 > 	SHA256 truncated to 192 bits.

You know, I've thought about this sort of thing quite a lot for Tahoe- 
LAFS and there's a very good reason not to truncate SHA-256 at all.   
That reason is: now you've got to do your own cryptanalysis work.   
Suppose open cryptographers publish better and better attacks on  
SHA-256 in the future.  As the attacks get better and better, we'll  
have to decide how urgent it is to upgrade from SHA-256 to (hopefully  
by that time) SHA-3.  If you're using a truncation of SHA-256 then  
you might need to jump sooner than other people, and you won't know  
whether or not this is the case unless you study the attacks yourself!

It is possible that a cryptographer will publish an attack on SHA-256  
which is evaluated as "not a realistic threat", but which *is* a  
realistic threat on SHA-256-trunc-192.  None of the open  
cryptographers will be checking or publicly mentioning whether  
SHA-256-trunc-192 is vulnerable because SHA-256-trunc-192 isn't on  
their radar.

 > I have to store the IV because of other features coming in the  
future. Originally I was calculating the IV based on: object set,  
object, blockid and transaction group (unsigned 64bit ints).  I still  
do calculate the IV based on those but it needs to be stored.

 > "Version" of the block doesn't really make sense in ZFS in that  
way because ZFS is copy on write. Or maybe you can think of the birth  
transaction id as the version because the other things like the  
object set, object, level and block id identify the logical  
filesystem location.

I don't understand the last sentence there.  Does this mean that  
you'll never be asked to encrypt more than one plaintext under a  
different birth transaction id?  If, so then perfect! -- use the  
birth transaction id as the IV!  What other features coming in the  
future would need to know the IV and would not already know the birth  
transaction id?

Something that I still don't understand is: why do you have a MAC tag  
at all if you already have a SHA-256 hash of the ciphertext?  David- 
Sarah Hopwood suggested a good reason that you might want one [1],  
but is that your reason?  Because how big the MAC tag needs to be is  
probably determined by why you need it.

Regards,

Zooko Wilcox-O'Hearn

[1] http://www.mail-archive.com/cryptography@metzdowd.com/msg11034.html
---
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