In current ZFS checksum and compression both have a default "on" value that can be used thus: zfs create -o compression=on tank/foo The current ZFS Crypto code base also has an "on" value. However unlike checksum and compression I think it is harder to provide a rationale for why a given algorithm should map to "on". Also over time that crypto algorithm/keylength/mode may go out of favour so the default should change. Changing what value "on" maps to doesn''t cause any problems for the on disk format since "on" isn''t what is stored it is what it maps too. We could choose that encryption=on is the same as encryption=aes-128-ccm, but then we have to explain why it shouldn''t be encryption=aes-256-ccm now and what about when we add a new algorithm/keylen/mode we then need to decided if it should be the default on value. So should we just omit the concept of "on" and require an explicit value and diverge from what checksum/compression/share* have all done so far ? Or is there sufficient value in mapping on to aes-128-ccm ? Note that this is not about wither encryption should be enabled for a dataset or not - the default value of encryption is off. In terms of the code impact it is about 5 lines of code difference to have an "on" value (3 removed 2 changed and one of those is an ASSERT). -- Darren J Moffat
Hi Darren, Are you making plans for how to support modes other than CCM mode as a potential default in the future? It looks like you are just thinking of 128 bit vs 256 bit key lengths at the moment. I like the idea of requiring an explicit value, for flexibility. Regards, Larry H -----Original Message----- From: zfs-crypto-discuss-bounces at opensolaris.org [mailto:zfs-crypto-discuss-bounces at opensolaris.org] On Behalf Of Darren J Moffat Sent: Wednesday, January 23, 2008 8:04 AM To: zfs-crypto-discuss at opensolaris.org Subject: encryption=on vs encryption=aes... In current ZFS checksum and compression both have a default "on" value that can be used thus: zfs create -o compression=on tank/foo The current ZFS Crypto code base also has an "on" value. However unlike checksum and compression I think it is harder to provide a rationale for why a given algorithm should map to "on". Also over time that crypto algorithm/keylength/mode may go out of favour so the default should change. Changing what value "on" maps to doesn''t cause any problems for the on disk format since "on" isn''t what is stored it is what it maps too. We could choose that encryption=on is the same as encryption=aes-128-ccm, but then we have to explain why it shouldn''t be encryption=aes-256-ccm now and what about when we add a new algorithm/keylen/mode we then need to decided if it should be the default on value. So should we just omit the concept of "on" and require an explicit value and diverge from what checksum/compression/share* have all done so far ? Or is there sufficient value in mapping on to aes-128-ccm ? Note that this is not about wither encryption should be enabled for a dataset or not - the default value of encryption is off. In terms of the code impact it is about 5 lines of code difference to have an "on" value (3 removed 2 changed and one of those is an ASSERT). -- Darren J Moffat _______________________________________________ zfs-crypto-discuss mailing list zfs-crypto-discuss at opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-crypto-discuss
Some people just know that encryption is good and will protect their data if it gets lost. We should provide an "on" value that is what those people should be using. More informed people can set it to something more specific. --matt Darren J Moffat wrote:> In current ZFS checksum and compression both have a default "on" value > that can be used thus: > > zfs create -o compression=on tank/foo > > The current ZFS Crypto code base also has an "on" value. However unlike > checksum and compression I think it is harder to provide a rationale for > why a given algorithm should map to "on". Also over time that crypto > algorithm/keylength/mode may go out of favour so the default should change. > > Changing what value "on" maps to doesn''t cause any problems for the on > disk format since "on" isn''t what is stored it is what it maps too. > > We could choose that encryption=on is the same as > encryption=aes-128-ccm, but then we have to explain why it shouldn''t be > encryption=aes-256-ccm now and what about when we add a new > algorithm/keylen/mode we then need to decided if it should be the > default on value. > > So should we just omit the concept of "on" and require an explicit value > and diverge from what checksum/compression/share* have all done so far ? > Or is there sufficient value in mapping on to aes-128-ccm ? > > Note that this is not about wither encryption should be enabled for a > dataset or not - the default value of encryption is off. > > In terms of the code impact it is about 5 lines of code difference to > have an "on" value (3 removed 2 changed and one of those is an ASSERT). >
On Wed, Jan 23, 2008 at 03:19:43PM -0800, Matthew Ahrens wrote:> Some people just know that encryption is good and will protect their data if > it gets lost. We should provide an "on" value that is what those people > should be using. More informed people can set it to something more specific.I agree, however, when displaying the current setting it should display the cipher/mode/key length. Nico --
Count me amongst the "''on'' is good brigade" - my take on it is: >We could choose that encryption=on is the same as >encryption=aes-128-ccm, but then we have to explain why it shouldn''t >be encryption=aes-256-ccm now no we don''t. we only have to pick one, and justify it as "we picked one". sometimes choice-by-fiat is allowed - one of the joys of coding not being democratic :-) >and what about when we add a new algorithm/keylen/mode we then need >to decided if it should be the default on value. me, I would set ''on'' to be ''a shorthand for the nominally /most/ secure algorithm supported on the current platform and likely to be portable to other platforms'' - and modify future revisions accordingly. -a -- Alec Muffett http://www.google.com/search?q=alec+muffett
Alec Muffett wrote:> > Count me amongst the "''on'' is good brigade" - my take on it is: > > >We could choose that encryption=on is the same as > >encryption=aes-128-ccm, but then we have to explain why it shouldn''t > >be encryption=aes-256-ccm now > > no we don''t.Okay let me re-phrase that. I don''t want to answer streams of emails or talk to customers in the future to justify the choice and explain the process, because I will get dragged into this - I know I will based on past experience [ like explaining why crypt_bsdmd5 and crypt_sunmd5 (even though you wrote the later) are safe despite the fact that MD5 has known collisions ] :-)> we only have to pick one, and justify it as "we picked one".Easy to say when you aren''t the one doing the ARC review :-)> >and what about when we add a new algorithm/keylen/mode we then need > >to decided if it should be the default on value. > > me, I would set ''on'' to be ''a shorthand for the nominally /most/ > secure algorithm supported on the current platform and likely to be > portable to other platforms'' - and modify future revisions accordingly.That would make "on" map to aes-256-ccm for phase 1 rather than aes-128-ccm which is what I was considering being the "on" value. I''m okay with that though. -- Darren J Moffat
Nicolas Williams wrote:> On Wed, Jan 23, 2008 at 03:19:43PM -0800, Matthew Ahrens wrote: >> Some people just know that encryption is good and will protect their data if >> it gets lost. We should provide an "on" value that is what those people >> should be using. More informed people can set it to something more specific. > > I agree, however, when displaying the current setting it should display > the cipher/mode/key length.That would make it different to how "on" is implemented for checksum and compression today. -- Darren J Moffat
On Thu, Jan 24, 2008 at 10:00:56PM +0000, Darren J Moffat wrote:> Nicolas Williams wrote: > >On Wed, Jan 23, 2008 at 03:19:43PM -0800, Matthew Ahrens wrote: > >>Some people just know that encryption is good and will protect their data > >>if it gets lost. We should provide an "on" value that is what those > >>people should be using. More informed people can set it to something > >>more specific. > > > >I agree, however, when displaying the current setting it should display > >the cipher/mode/key length. > > That would make it different to how "on" is implemented for checksum and > compression today.Well, I think that there should be an easy way to find out what "on" really means. Reading a manpage isn''t what I would think of as easy when one has just run zfs get ... -- if I looked at all properperties, then I should know. Nico --
Nicolas Williams wrote:> On Thu, Jan 24, 2008 at 10:00:56PM +0000, Darren J Moffat wrote: >> Nicolas Williams wrote: >>> On Wed, Jan 23, 2008 at 03:19:43PM -0800, Matthew Ahrens wrote: >>>> Some people just know that encryption is good and will protect their data >>>> if it gets lost. We should provide an "on" value that is what those >>>> people should be using. More informed people can set it to something >>>> more specific. >>> I agree, however, when displaying the current setting it should display >>> the cipher/mode/key length. >> That would make it different to how "on" is implemented for checksum and >> compression today. > > Well, I think that there should be an easy way to find out what "on" > really means. Reading a manpage isn''t what I would think of as easy > when one has just run zfs get ... -- if I looked at all properperties, > then I should know.Reading the man page is what you have to do for compression and checksum today. -- Darren J Moffat
On Thu, Jan 24, 2008 at 10:22:35PM +0000, Darren J Moffat wrote:> Nicolas Williams wrote: > >On Thu, Jan 24, 2008 at 10:00:56PM +0000, Darren J Moffat wrote: > >>Nicolas Williams wrote: > >>>On Wed, Jan 23, 2008 at 03:19:43PM -0800, Matthew Ahrens wrote: > >>>>Some people just know that encryption is good and will protect their > >>>>data if it gets lost. We should provide an "on" value that is what > >>>>those people should be using. More informed people can set it to > >>>>something more specific. > >>>I agree, however, when displaying the current setting it should display > >>>the cipher/mode/key length. > >>That would make it different to how "on" is implemented for checksum and > >>compression today. > > > >Well, I think that there should be an easy way to find out what "on" > >really means. Reading a manpage isn''t what I would think of as easy > >when one has just run zfs get ... -- if I looked at all properperties, > >then I should know. > > Reading the man page is what you have to do for compression and checksum > today.I understood. I''m suggesting that that isn''t all that friendly. It *will* do though. Nico --
Well, here''s a different take on it, instead of going with "on", how about "light" and "strong", where "light" represents a weaker but fast and still considered secure cipher, where "strong" defaults to AES-256? -mg This message posted from opensolaris.org
On Mon, Feb 04, 2008 at 07:19:35AM -0800, Mario Goebbels wrote:> Well, here''s a different take on it, instead of going with "on", how > about "light" and "strong", where "light" represents a weaker but fast > and still considered secure cipher, where "strong" defaults to > AES-256?The problem with that is that the relative strength of ciphers varies over time as cryptanalysis progresses. Here we can assume with rather high certainty that strength(AES-256) > strength(AES-128), always. However, we cannot assume that something stronger than AES won''t come along. Notions of "strong" and "weak" crypto are certainly useful, but they have to be local/configurable notions, otherwise they become obsolete with the passage of time. What I mean by "local" (and this is off-topic for this list) is that protocols must not rely on global assignments of cryptographic strength values. Nico --
Mario Goebbels wrote:> Well, here''s a different take on it, instead of going with "on", how > about "light" and "strong", where "light" represents a weaker but fast > and still considered secure cipher, where "strong" defaults to > AES-256?That is a good think for a higher level interface maybe in some appliance using ZFS crypto but not for what we actually use at the lower levels. It is also out of sync with how checksum, compression and many other ZFS properties are presented. Nicolas Williams wrote:> The problem with that is that the relative strength of ciphers varies > over time as cryptanalysis progresses. Here we can assume with rather > high certainty that strength(AES-256) > strength(AES-128), always. > However, we cannot assume that something stronger than AES won''t come > along.Nor can we assume that AES-256-CCM is stronger than AES-256-FOO were FOO is some future mode we choose to add.> Notions of "strong" and "weak" crypto are certainly useful, but they > have to be local/configurable notions, otherwise they become obsolete > with the passage of time. What I mean by "local" (and this is off-topic > for this list) is that protocols must not rely on global assignments of > cryptographic strength values.Agreed. -- Darren J Moffat