On 17/11/2010 21:58, Bill Sommerfeld wrote:
In particular, the mechanism by which dedup-friendly block IV's are
chosen based on the plaintext needs public scrutiny. Knowing Darren,
it's very likely that he got it right, but in crypto, all the details
matter and if a spec detailed enough to allow for interoperability isn't
available, it's safest to assume that some of the details are wrong.
That is described here:
http://blogs.sun.com/darren/entry/zfs_encryption_what_is_on
"If dedup=on for the dataset the per block IVs are generated
differently. They are generated by taking an HMAC-SHA256 of the
plaintext and using the left most 96 bits of that as the IV. The key
used for the HMAC-SHA256 is different to the one used by AES for the
data encryption, but is stored (wrapped) in the same keychain entry,
just like the data encryption key a new one is generated when doing a
'zfs key -K <dataset>'. Obviously we couldn't calculate this IV when
doing a read so it has to be stored."
This was also suggested independently by other well known people
involved in encrypted filesystems while it was discussed on a public
forum (most of that thread was cross posted to zfs-crypto-discuss).
--
Darren J Moffat
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
