Truncating SHA2 hashes vs shortening a MAC for ZFS Crypto

[Nicolas Williams]

On Tue, Nov 03, 2009 at 07:28:15PM +0000, Darren J Moffat wrote:
> Nicolas Williams wrote:
> >Interesting.  If ZFS could make sure no blocks exist in a pool from more
> >than 2^64-1 transactions ago[*], then the txg + a 32-bit per-transaction
> >block write counter would suffice.  That way Darren would have to store
> >just 32 bits of the IV.  That way he'd have 352 bits to work with, and
> >then it'd be possible to have a 128-bit authentication tag and a 224-bit
> >hash.
> 
> The logical txg (post dedup integration we have physical and logical 
> transaction ids) + a 32 bit counter is interesting.   It was actually my 
> very first design for IV's several years ago!

Excellent.

> All this assumes that the data encryption key is staying the same - we 
> don't have to go on that assumption with ZFS since I have the means to 
> start using a new one for new blocks.  Currently switching to a new data 
> encryption key (distinct from changing the wrapping key the user looks 
> after) is under the admin/users control but it could be done 
> automagically based on time or volume of blocks written.

Not really.  You can change or not change keys, and still, txg+32-bit
counter will give you enough.

> >    If 32 bits for per-transaction block write counters is too low, then
> >    transaction rate could increase (and arguably would have to
> >    anyways); even with the fastest flash 2^32 IOPS seems a long way
> >    away, and there should be enough CPU to jack up the transaction rate
> >    by then to compensate.  Let's suppose that we end up with a txg
> >    per-microsecond: then we get down to a still comfy (though starting
> >    to push it) 584,542 years before we wrap.
> 
> I suspect that sometime in the next 584,542 years the block pointer size 
> for ZFS will increase and I'll have more space to store a bigger MAC, 
> hash and IV.  In fact I guess that will happen even in the next 50 years.

Heh.  txg + 32-bit counter == 96-bit IVs sounds like the way to go.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com