Zooko Wilcox-O'Hearn wrote:
> 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].
I never said anything about truncating the GCM MAC and I wouldn't do
that. With GCM you can choose in the params the size of the MAC. I
that is what you mean by truncate though in choosing a short tag though.
The main thing I get from those two references and the GCM spec is: ever
go below 96 bits of MAC but ideally use 128 bits of MAC.
So that leads me to think that for ZFS given my space restriction this
is probably the best set of sizes for IV, MAC, cryptographic hash of
ciphertext:
96 bit IV (stored in block pointer)
96 bit MAC (stored in block pointer)
SHA256 truncated to 192 bits.
> 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.
They user can't choose a checksum other than SHA256 if encryption is
enabled. In the future when SHA-3 is choosen we will allow that too.
Right, thats the question, how big of a GCM MAC is big enough ?
> 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?
Yes the IV is unique for every write already.
I have to store the IV because of other features coming in the future.
Originally I was calculating the IV based on: object set, object,
blockid and transaction group (unsigned 64bit ints). I still do
calculate the IV based on those but it needs to be stored.
> 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.
"Version" of the block doesn't really make sense in ZFS in that way
because ZFS is copy on write. Or maybe you can think of the birth
transaction id as the version because the other things like the object
set, object, level and block id identify the logical filesystem
location. The DVA (Data Virtual Address) is the 128 bit disk location
but I don't believe I can use any of that for the IV because in the
future we will allow the physical location of the logical block to
change (and we need that to work without the crypto keys present).
--
Darren J Moffat
