I wrote this note on 2009-11-04 22:32:34 but I haven't seen a reply. I wanted to make sure that the ZFS crypto engineers thought about this, because if there *is* any information which fits the bill then it could help.
On Wednesday,2009-11-04, at 8:04 , Darren J Moffat wrote: > One of the possible future features that would need access to the > IV is if we do a version of 'zfs send' (which takes a ZFS > filesystem and makes a stream out of it for replication purposes) > that transfers the blocks as they are on disk (ie compressed and > encrypted). Currently the 'zfs send' works at the DMU layer of ZFS > and doesn't deal in transactions or even disk blocks - it deals in > DMU objects and the send stream is all decrypted and > decompressed. To be able to send ciphertext blocks we will need > to send the IV to the remote side too. Which is why we need to > store the IV rather than calculate it - the remote side won't be > putting that ciphertext on disk in the same txg number. I don't > want to do anything now that would make that difficult to do later. > Is there some information that does come with and then get stored by the "zfs recv" side that you could use for (partial) IV? Maybe an objset id? Anything which is stable through zfs send-and-receive and which is unique to this block could be used for (part of) the IV and thus shorten the amount of bits you need to store for the IV. Regards, Zooko
