Darren J Moffat wrote: > Wyllys Ingersoll wrote: > > Some comments on the ZFS crypto design document: > > > > * Encryption policy - I'm not understanding why it is not possible > > to toggle the on/off encryption property on a dataset once it is > > defined. I think this might be viewed as a problem, or at least a > > minor-annoyance, in the future. When the Key Change feature > > (section 3.1.1) is implemented, perhaps that solution would also > > make it possible to toggle the crypto since it is a similar > > operation. > > The reason you can't turn crypto on and off at will for a given data > set is because unlike compression it actually matters if all the > blocks are written encrypted or not. Consider this: > > At time t0 I do: zfs create home/darrenm/Documents > > At time t1 before any data is written I do > > zfs set -o encryption=aes-128-cbc home/darrenm/Documents > > At time t2 I put some really private data into that directory, and > all the blocks in it get encrypted. > > At time t3 I or an admin does this: > > zfs set -o encryption=off home/darrenm/Documents > > I update that private document (lets say I didn't actually hit save > but an application auto-save happened), but it causes only part of > the file to get rewritten so some blocks are encrypted and some are > in the clear. > > At time t4 I or the admin notices our boo-boo and does > > zfs set -o encryption=on home/darrenm/Documents > > Question is am I safe ? > > Answer no you aren't because at time t3 cleartext blocks got written > out. However I can't tell using the zfs(1) command that this > happened, in fact I have very little change of knowing that happened.
OK. What if the zfs command restricted the use of the encryption flag by only making it possible to change the value when that filesystem was not currently mounted? That would prevent the above scenario and still leave it possible to make the change, albeit under strict conditions. -Wyllys > > > Now if this was compression, it really doesn't mater all that happens > is that blocks that may have been compressed aren't so it is just a > cpu/diskspace trade off. With crypto its a security issue. > > Even if we had the ability to go and write new versions of all the > clear text blocks we still need a way to overwrite them with a > suitable secure pattern (maybe N times) to make them safe. > > There are similar problems with just changing between various values > of encryption that all imply doing something other than cleartext. > This is because it isn't always possible to say that one > algorithm/keylength/mode is stronger than another, and if they need > different keys you have to keep all the keys around. > >
