On Fri, Feb 02, 2007 at 08:46:34AM +0000, Darren J Moffat wrote: > 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.
I'm sorry it seems I started my explanations from too deep. I started to play with encryption on my own by creating a "crypto" compression algorithm. Currently there are few types of property (readonly, inherited, etc.), but non of them seems to be suitable for encryption. When you enable encryption there should be no data, or you know that existing data is going to be encrypted and plaintext data securely removed automatically. Of course the later is much more complex to implement. > 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. Right. I forget that a dataset created under another dataset doesn't share data with the parent. > 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. Key change is nice and algorithm change possibility is also nice in case the one you use become broken. What I'm doing in geli (my disk encryption software for FreeBSD) is to use random, strong master key, which is encrypted by user's passphrase, keyfiles, etc. This is nice because changing user's passphrase doesn't affect the master key, thus doesn't cost any I/O operations. Another nice thing about it is that you can have many copies of the master key protected by different passphrases. For example two persons can decrypt your data: you and security officer in your company. On the other hand, changing the master key should also be possible. A good starting point IMHO will be to support user's passphrase (keyfile, etc.) change (without touching the master key) and document changing the master key, algorithm, key length, etc. via eg. local zfs send/recv. > 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). Maybe keys should be pool's properties? You add new key to the pool and then assign selected key to the given datasets. You can then "unlock" the key using zpool(1M) or you'll be asked to "unlock" all keys used by a dataset when you want to mount/attach it (file system or zvol). Once the key is "unlocked", the remaining datasets that use the same key can be mounted/attached automatically. Just a thought... -- Pawel Jakub Dawidek http://www.wheel.pl [EMAIL PROTECTED] http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am!
pgpnlZmnidmyi.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
