[145021] in cryptography@c2.net mail archive
Re: Truncating SHA2 hashes vs shortening a MAC for ZFS Crypto
daemon@ATHENA.MIT.EDU (Zooko Wilcox-O'Hearn)
Fri Nov 6 10:42:53 2009
In-Reply-To: <44BCE2C4-4B90-4CA1-9B7C-158DB2AA0C5E@zooko.com>
From: Zooko Wilcox-O'Hearn <zooko@zooko.com>
Date: Tue, 3 Nov 2009 10:12:06 -0700
To: David-Sarah Hopwood <david-sarah@jacaranda.org>,
Cryptography List <cryptography@metzdowd.com>,
zfs-crypto-discuss@opensolaris.org
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@metzdowd.com
