Truncating SHA2 hashes vs shortening a MAC for ZFS Crypto

Matt Ball matt.ball at ieee.org
Mon Nov 2 10:23:44 EST 2009


Hi Darren,


On Fri, Oct 30, 2009 at 11:30 AM, Darren J Moffat <Darren.Moffat at sun.com>wrote:

> For the encryption functionality in the ZFS filesystem we use AES in CCM or
> GCM mode at the block level to provide confidentiality and authentication.
>  There is also a SHA256 checksum per block (of the ciphertext) that forms a
> Merkle tree of all the blocks in the pool. Note that I have to store the
> full IV in the block.   A block here is a ZFS block which is any power of
> two from 512 bytes to 128k (the default).
>
> The SHA256 checksums are used even for blocks in the pool that aren't
> encrypted and are used for detecting and repairing (resilvering) block
> corruption.  Each filesystem in the pool has its own wrapping key and data
> encryption keys.
>
> Due to some unchangeable constraints I have only 384 bits of space to fit
> in all of: IV, MAC (CCM or GCM Auth Tag), and the SHA256 checksum, which
> best case would need about 480 bits.
>
> Currently I have Option 1 below but I the truncation of SHA256 down to 128
> bits makes me question if this is safe.  Remember the SHA256 is of the
> ciphertext and is used for resilvering.
>
> Option 1
> --------
> IV              96 bits  (the max CCM allows given the other params)
> MAC             128 bits
> Checksum        SHA256 truncated to 128 bits
>
>
I personally like the default option 1.  All the others have various
uglinesses.

SHA-224 has patent issues (see US patent
6829355<http://v3.espacenet.com/textdoc?DB=EPODOC&IDX=US6829355>).
It's really identical to SHA-256 except that it uses a different initial
value and truncates to 224 bits.  I would love to see SHA-224 completely
disappear.

Cryptographers will all have different opinions about how big a MAC (i.e.,
cryptographic integrity check) should be, but my take on it is to ask how
big of a CRC would you need in a non-adversarial environment to meet the
undetectable error rate specified within the system, and then use that for
the minimum size of the MAC.  For tape drives I've worked on, this was
typically somewhere around 1 undetected error in 10^27 bits.  If you protect
1 data bit, then you'd roughly need an 90 bit CRC, which you could round up
to 96-bits.  Anything more than 96 bits in my opinion is somewhat overkill.
I'd pick a CCM mac of either 96 bits or 128.

For hashing, it's a little different since you have to worry about the
birthday paradox.  The size of the hashing output depends on the
undetectable error rate of the system, along with the maximum number of
candidate plaintexts that an adversary could create in finding a hash
collision.  Most cryptographers (not knowing more about the system) would be
conservative and say something like "Use the full 256-bits of SHA-256 to get
a minimum of 128-bits of security", but realistically for this system, that
would be way overkill.  There's already a 128-bit CCM MAC to fall back to,
so here again (given the other safety nets in the system), I think that a
128-bit truncated SHA-256 has would be plenty of assurance for the system.

-- 
Thanks!

Matt Ball, Chair, IEEE P1619 Security in Storage Working Group
Staff Engineer, Sun Microsystems, Inc.
500 Eldorado Blvd, Bldg #5 BRM05-212, Broomfield, CO 80021
Work: 303-272-7580, Cell: 303-717-2717
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20091102/8ccf90d2/attachment.html>


More information about the cryptography mailing list