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
