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. For CCM the maximum possible IV (nonce field in the CCM_PARAMS) is 13 bytes (104 bits) but that limits the data size to 64k which is two low to store the current maximum size of ZFS block (128k) we could encrypt in one operation. So I have to set the CCM nonce size to 12 bytes (96 bits) so that the size of data that can be encrypted goes up to 16777215 bits. This is the way CCM mode is defined, so again my maximum is a 96 bit IV. > 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. -- Darren J Moffat
