Darren J Moffat wrote:
> Zooko Wilcox-O'Hearn wrote:
>> On Tuesday, 2009-12-01, at 6:45 , Darren J Moffat wrote:
>>
>>> I've settled on 160 bits of SHA256, 96 bit stored IV, and 96 bit
>>> AuthTag/MAC.
>>
>> And this 96-bit stored IV is the only IV, right?  Because auxiliary
>> information such as zbookmark_t and txg can't be used for this purpose?
> 
> The 96 bit IV is calculated by hashing some of the fields from the
> zbookmark_t (object, level, block) and the txg.
> 
>> Have you worked out the birthday paradox consequences for a 96-bit IV?
> 
> GCM mode will GHASH any IV larger than 96 bits down to 96 bits anyway
> and 96 bit is considered the "default" IV size.

Right, but GCM mode (like other CTR-based modes) is designed under the
assumption that the IV is chosen uniquely. If it's a hash, then even
when the inputs to the hash are unique, we expect collisions after
sqrt(2*p) * 2^48 blocks with probability p.

The consequence of a collision is to leak the exclusive-or of the
plaintexts of the colliding blocks (which will often be sufficient to
derive both plaintexts). This security level is significantly less than
the design strength of 128-bit AES. For most applications, this weakness
probably wouldn't matter very much, but the problem is that you don't
know what will be stored in the filesystem or how significant a leak
would be.

>> Another question: does this scheme prevent deduplication?  If two
>> blocks have identical plaintext, but independent random IVs and
>> therefore different ciphertext, then how can the deduper figure out
>> that they could be deduped?
> 
> The IVs aren't randomly generated, and yes that does prevent
> deduplication if I use an IV derived from the zbookmark_t+txg or a
> random IV.
> 
> For deduplication the IV generate is done differently to ensure the
> ciphertext does match, but only when dedup is enabled on those ZFS
> datasets - this means we can dedup with in a dataset and its clones
> (since they by default share data encryption keys_ but not any other
> datasets.

How is the IV derived when dedup is enabled?

-- 
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://mail.opensolaris.org/pipermail/zfs-crypto-discuss/attachments/20091214/5cb7dfec/attachment.bin>

Reply via email to