Thomas, correct me if I'm wrong, but I think that since the salt is changed every time we import the pool, generating the IV from 'DVA[0] + birth txg + salt' would be correct. The problem with doing that arises when we want to do encrypted send/receive. On the receiving end, the block pointer would have a different DVA[0] and birth_txg.
--matt On Mon, Oct 10, 2016 at 7:11 PM, Pawel Jakub Dawidek <[email protected]> wrote: > Hi Thomas, > > I'm going through your OpenZFS presentation and I'd like to get more > info about IV storage. > > In the presentation you mention that you cannot generate IV, that it has > to be stored somewhere. Generating it from 'DVA[0] + birth txg + salt' > does sound like a good idea, but you mentioned that birth txg can rewind > on import. It can, but we still generate new salt every time we store > the block (don't we?) and birth txg could be fixed by simply starting > from some sane value on import, eg. 'on-disk-birth-txg + 1024'. > Consecutive crashes on import might be a problem, though. > In the presentation you address why DVA[0] and birth txg don't give us > uniqueness, but you don't talk about the salt, which is the most > promissing bit. Could you elaborate? > > There is also IV (96 bits) on the slide, but I think I saw you mention > somewhere else (on github?) it is now 128 bits, right? If I wrong, could > you please talk about 96 bits IV too? > > Thanks! > > -- > Pawel Jakub Dawidek http://www.wheelsystems.com > FreeBSD committer http://www.FreeBSD.org > Am I Evil? Yes, I Am! http://mobter.com > ------------------------------------------- openzfs-developer Archives: https://www.listbox.com/member/archive/274414/=now RSS Feed: https://www.listbox.com/member/archive/rss/274414/28015062-cce53afa Modify Your Subscription: https://www.listbox.com/member/?member_id=28015062&id_secret=28015062-f966d51c Powered by Listbox: http://www.listbox.com
