Truncating SHA2 hashes vs shortening a MAC for ZFS Crypto
zooko at zooko.com
Tue Nov 3 12:12:06 EST 2009
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  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.
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
More information about the cryptography