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