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>