On Tue, Aug 15, 2006 at 06:12:47PM -0400, Bill Sommerfeld wrote: > On Tue, 2006-08-15 at 12:47 -0700, Eric Schrock wrote: > > > The copy-on-write nature of ZFS makes this extremely difficult, > > particularly w.r.t. to snapshots. That's not to say it can't be solved, > > only that it won't be solved in the near term (i.e. within the next > > year). The timeframe for ZFS crypto support is much shorter, and this > > requirement is entirely reasonable for an initial implementation. > > So, maybe we're doing these projects in the wrong order, then -- my > experience with implementing systems using cryptography is that unless > you design, implement, *and* test algorithm and key agility from the > beginning, you will have to throw away a lot more than you originally > expected to when you try to add it in later.
This is particularly true for protocols (here everything is local though). A phase 0 project might put re-keying into zfs send/receive. Want to change algorithms, keys? zfs send|zfs receive, move filesystems around. In any case surely key management *has* to fit at least into zfs send or receive -- either send unencrypted or provide a key to zfs receive, else no zfs send/receive of encrypted filesystems, which could not possibly be acceptable. I'd expect key management to also fit into zfs scrubbing (ah, but scrubbing is a pool-wide thing). Want to re-key a whole filesystem? Scrub. Even so, I'd rather set up algorithms and keys in zfs create than in zfs set after creating the filesystem and then having to scrub the fs (though scrubbing a nearly empty filesystem should be no big deal, right). Nico -- _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
