Truncating SHA2 hashes vs shortening a MAC for ZFS Crypto

[Darren J Moffat]

Zooko Wilcox-O'Hearn wrote:
> [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!

That is exactly my concern and why I came here for advice.

I think I'm now convinced that truncating the SHA256 hash would not be a 
good idea even though we do have an additional MAC.

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

In a given birth transaction (txg) there may be many blocks being 
encrypted under the same key, so the txg alone isn't enough.  The 
combination of txg, objset and block id are unique - but that is 192 bits.

One of the possible future features that would need access to the IV is 
if we do a version of 'zfs send' (which takes a ZFS filesystem and makes 
a stream out of it for replication purposes) that transfers the blocks 
as they are on disk (ie compressed and encrypted).  Currently the 'zfs 
send' works at the DMU layer of ZFS and doesn't deal in transactions or 
even disk blocks - it deals in DMU objects and the send stream is all 
decrypted and decompressed.   To be able to send ciphertext blocks we 
will need to send the IV to the remote side too.  Which is why we need 
to store the IV rather than calculate it - the remote side won't be 
putting that ciphertext on disk in the same txg number.   I don't want 
to do anything now that would make that difficult to do later.

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

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 can't make the SHA-256 keyed because there are ZFS operations that we 
must be able to perform with the decryption key is not available: 
resilvering a mirror/raidz, disk removal (raid relayout), hotspare, 
scrub (proactive resilver).

By using a MAC we reduce that risk because now the attacker needs to 
forge the MAC and modify the SHA-256 Merkle tree all the way to the 
uberblock as well.  Depending on the type of modification the attacker 
may actually need to forge multiple MAC tags.

A given MAC tag applies to a single ZFS block that is between 512 bytes 
and 128k.

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 ?

--
Darren J Moffat

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