On Fri, Feb 02, 2007 at 08:46:34AM +0000, Darren J Moffat wrote: > 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.
Re-keying and algorithm change should be seen as related. And encryption off -> null encryption algorithm. > 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). I don't see why having a different key per-dnode is so difficult, particularly if the per-dnode key isn't randomly generated, but derived from the filesystem's master key and the dnode number (then you don't have to store it anywhere). And you might have to have per-dnode keys because of the birthday bound on key usage. Just make sure that the master key is always randomly generated, rather than derived from a passphrase. Now, the cipher modes you'll use matter, as you could, over the life of a file, end up using the same block more than once with the same key. A simple counter mode with the counter being based on the block address would leak whether the same data has been written encrypted in the same key; if the counter is based on the file offset and you have per-dnode keys then the leak would be whether the same data has been written at the same file offset in the same file. Can you replace the ZFS checksum function with the MAC from an authenticated encryption cipher mode? If not then not using authenticated encryption would mean not having to worry about where to store a MAC, and the existing ZFS checksum functionality (using a cryptographic hash function) in combination with encryption should buy you integrity protection semantics very close to what you'd get with an authenticated cipher mode. Nico -- _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
