Pawel Jakub Dawidek wrote:
On Thu, Feb 01, 2007 at 11:00:07AM +0000, Darren J Moffat wrote:
Neil Perrin wrote:
No it's not the final version or even the latest!
The current on disk format version is 3. However, it hasn't
diverged much and the znode/acl stuff hasn't changed.
and it will get updated as part of zfs-crypto, I just haven't done so yet
because I'm not finished designing yet.
Do you consider adding a new property type (next to readonly and
inherit) - a "oneway" property? Such propery could be only set if the
dataset has no children, no snapshots and no data, and once set can't be
modified. "oneway" would be the type of the "encryption" property.
On the other hand you may still want to support encryption algorithm
change and most likely key change.
I'm not sure I understand what you are asking for.
My current plan is that once set the encryption property that describes
which algorithm (mechanism actually: algorithm, key length and mode, eg
aes-128-ccm) can not be changed, it would be inherited by any clones.
Creating new child file systems "rooted" in an encrypted filesystem you
would be allowed to turn if off (I'd like to have a policy like the acl
one here) but by default it would be inherited.
Key change is a very difficult problem because in some cases it can mean
rewritting all previous data, in other cases it just means start using
the new key now but keep the old one. Which is correct depends on why
you are doing a key change. Key change for data at rest is a very
different problem space from rekey in a network protocol.
In theory the algorithm could be different per dnode_phys_t just like
checksum/compression are today, however having aes-128 on one dnode and
aes-256 on another causes a problem because you also need different keys
for them, it gets even more complex if you consider the algorithm mode
and if you choose completely different algorithms. Having a different
algorithm and key length will certainly be possible for different
filesystems though (eg root with aes-128 and home with aes-256).
Which I think is a long way of saying "yes".
--
Darren J Moffat
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
