Zooko Wilcox-O'Hearn wrote:
> 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.
I had had seen it and thought about it. In fact I was originally using
information from the zbookmark_t and the txg id.
> 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.
The information in the zbookmark_t + txg works for all cases except for:
send-recv where the data is sent encrypted
deduplication
In both of those cases the zbookmark_t and txg will be different.
I've settled on 160 bits of SHA256, 96 bit stored IV, and 96 bit
AuthTag/MAC.
--
Darren J Moffat
