Truncating SHA2 hashes vs shortening a MAC for ZFS Crypto

David-Sarah Hopwood david-sarah at jacaranda.org
Fri Nov 6 22:48:07 EST 2009


Nicolas Williams wrote:
> 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!
[...]
>> 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.

I'm confused. How does this allow you to do block-level deduplication,
given that the IV (and hence the ciphertext) will be different for every
block even when the plaintext is the same?

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 292 bytes
Desc: OpenPGP digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20091107/6c640040/attachment.pgp>


More information about the cryptography mailing list