On Jan 9, 2008, at 3:07 AM, Darren J Moffat wrote: > For the case where we generate the master wrapping key (for datasets > using a key wrapped by the pool key [keystype=pool]) from a passphrase > using PKCS#5 we have to pick the size of the resulting key. I've > decided that I see no reason for it not to be an AES 256 bit key. > > However for the case where the wrapping key comes from a file (or > passed > in via the private libzfs.so API from some other source) we could > allow > it to be any of 128, 192, 256. However I think that makes things > overly > complex. Since it allows us to get into a situation where an AES 256 > bit bulk key used for encrypting data is wrapped by an AES 128 bit > wrapping key. That feels wrong - it technically works but it feels > wrong. > > There are couple of options here: > > 1) Don't allow encrypted datasets with key lengths greater than that > of > the wrapping key. This seems safe from a security view but adds a > significant amount of complexity to the code but more importanly it > makes key change have to deal with more cases, in particular what if > the > new key is smaller than the old one (obvious answer disallow it - > but we > would still have to check). > > 2) Require that the pool level wrapping key must be AES 256 bit when > stored in a file or passed in via the (private) API. > > Unless I hear strong objection with justification I'm going with > option > 2 since it means that we always use an AES 256 bit wrapping key.
Works for me. > At the moment the wrapping key must be an AES key but that may not > always be the case, we can deal with the issues of other wrapping > algorithms/key types when they come up. > > > For those that are about to point out that AES 256 bit isn't always > available in Solaris because of the SUNWcry/SUNWcryr packages that > will > be resolved very soon (the changes are in final codereview and testing > now and integration of it is a hard dependency for ZFS crypto anyway). > > -- > Darren J Moffat > _______________________________________________ > zfs-crypto-discuss mailing list > zfs-crypto-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-crypto-discuss
