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. 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
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
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. > > 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). >I like option 2. The needless complexity for a key that has no performance impact. Why not set it to the strongest key.. Tony
If you already require an AES wrapping key, I have no objections with option 2. "Require" implies some kind of error handling, how would the API consumers know that the key length was invalid? Cindi 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. > > 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). >
On Wed, 2008-01-09 at 11:07 +0000, 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.what happens when (for whatever reason) we as a community or our users decide AES256 isn''t strong enough any more? Algorithms fall apart over time, so I always get nervous when a design bakes in assumptions about the set of algorithms considered "good enough", and I get doubly nervous when the size of that set is 1. - Bill
The key length is passed along with the key data. It''s already part of the structure that would handle key operations in libzfs. Tony cindi wrote:> If you already require an AES wrapping key, I have no objections with > option 2. "Require" implies some kind of error handling, how would the > API consumers know that the key length was invalid? > > Cindi > > 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. >> >> 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). >> > _______________________________________________ > zfs-crypto-discuss mailing list > zfs-crypto-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-crypto-discuss
Bill Sommerfeld wrote:> On Wed, 2008-01-09 at 11:07 +0000, 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. > > what happens when (for whatever reason) we as a community or our users > decide AES256 isn''t strong enough any more? > > Algorithms fall apart over time, so I always get nervous when a design > bakes in assumptions about the set of algorithms considered "good > enough", and I get doubly nervous when the size of that set is 1. > > - Bill >The limit isn''t for preventing future algorithms and keylengths.. I think Darren''s point is it''s more about simplifying for right now.. Since this is not a pluggable architecture, code will have to be changed with new algorithms/keylengths anyway.. Tony
Bill Sommerfeld wrote:> On Wed, 2008-01-09 at 11:07 +0000, 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. > > what happens when (for whatever reason) we as a community or our users > decide AES256 isn''t strong enough any more?Then we bump the SPA_VERSION (and maybe ZFS_VERSION) of ZFS and add a new capability. I have plans to do that eventually anyway. This hardcoding at AES256 rather than allowing AES128,AES192,AES256 for the master wrapping key is to simplify the phase 1 deliverables without having to provide more config knobs that is necessary.> Algorithms fall apart over time, so I always get nervous when a design > bakes in assumptions about the set of algorithms considered "good > enough", and I get doubly nervous when the size of that set is 1.It isn''t that hardcoded that it isn''t extensible. Plus I have comments in the code saying where we would be changing things to add a different key wrapping algorithm. -- Darren J Moffat