[dm-crypt] different default key sizes for CREATE and LUKSFORMAT

[dm-crypt] different default key sizes for CREATE and LUKSFORMAT

[Stefan Xenon]

Hi!
In the man page for cryptsetup is written regarding the option --key-size :

"Can be used for create or luksFormat,  all
other  LUKS  actions  will  ignore this flag, as the key-size is
specified by the partition header. Default is 128 for luksFormat
and 256 for create."

I am wondering what is the reason for two different default key sizes?

Thanks
Stefan

Re: [dm-crypt] different default key sizes for CREATE and LUKSFORMAT

[Arno Wagner]

"create" is plain dm-crypt, luskFormat is creation of
a LUKS header. I suspect the reason is historical, as
these are two different encryption systems.

Arno



On Tue, Nov 17, 2009 at 11:45:40PM +0100, Stefan Xenon wrote:
> Hi!
> In the man page for cryptsetup is written regarding the option --key-size :
> 
> "Can be used for create or luksFormat,  all
> other  LUKS  actions  will  ignore this flag, as the key-size is
> specified by the partition header. Default is 128 for luksFormat
> and 256 for create."
> 
> I am wondering what is the reason for two different default key sizes?
> 
> Thanks
> Stefan
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
> 

-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

Re: [dm-crypt] different default key sizes for CREATE and LUKSFORMAT

[Stefan Xenon]

If the reason is historically only, it might be a kind of security issue
(low priority) because this behaviour could result in wrong expectations
of users on the system regarding the default key size. A user who learns
that the default key size (using "create") is 256 bit but uses
"luksFormat" (which uses 128 bit) instead, may be misleaded. Therefore
it may be better to harmonize both default values.

Stefan


Arno Wagner schrieb:
> "create" is plain dm-crypt, luskFormat is creation of
> a LUKS header. I suspect the reason is historical, as
> these are two different encryption systems.
> 
> Arno
> 
> 
> 
> On Tue, Nov 17, 2009 at 11:45:40PM +0100, Stefan Xenon wrote:
>> Hi!
>> In the man page for cryptsetup is written regarding the option --key-size :
>>
>> "Can be used for create or luksFormat,  all
>> other  LUKS  actions  will  ignore this flag, as the key-size is
>> specified by the partition header. Default is 128 for luksFormat
>> and 256 for create."
>>
>> I am wondering what is the reason for two different default key sizes?
>>
>> Thanks
>> Stefan
>>
>> _______________________________________________
>> dm-crypt mailing list
>> dm-crypt@saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt
>>
> 

Re: [dm-crypt] different default key sizes for CREATE and LUKSFORMAT

[Arno Wagner]

I am not sure this really is a security issue. It may confuse users,
but they will still be secure. Most probably use defaults anyways.

But if we change this, I propose to make aes-cbc-essiv:sha256
the default for plain dm-crypt and to increase LUKS key length 
to 256 bits as well. The performance loss is apparently very 
small (10% or so).

Arno


On Wed, Nov 18, 2009 at 11:01:18AM +0100, Stefan Xenon wrote:
> If the reason is historically only, it might be a kind of security issue
> (low priority) because this behaviour could result in wrong expectations
> of users on the system regarding the default key size. A user who learns
> that the default key size (using "create") is 256 bit but uses
> "luksFormat" (which uses 128 bit) instead, may be misleaded. Therefore
> it may be better to harmonize both default values.
> 
> Stefan
> 
> 
> Arno Wagner schrieb:
> > "create" is plain dm-crypt, luskFormat is creation of
> > a LUKS header. I suspect the reason is historical, as
> > these are two different encryption systems.
> > 
> > Arno
> > 
> > 
> > 
> > On Tue, Nov 17, 2009 at 11:45:40PM +0100, Stefan Xenon wrote:
> >> Hi!
> >> In the man page for cryptsetup is written regarding the option --key-size :
> >>
> >> "Can be used for create or luksFormat,  all
> >> other  LUKS  actions  will  ignore this flag, as the key-size is
> >> specified by the partition header. Default is 128 for luksFormat
> >> and 256 for create."
> >>
> >> I am wondering what is the reason for two different default key sizes?
> >>
> >> Thanks
> >> Stefan
> >>
> >> _______________________________________________
> >> dm-crypt mailing list
> >> dm-crypt@saout.de
> >> http://www.saout.de/mailman/listinfo/dm-crypt
> >>
> > 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
> 

-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

Re: [dm-crypt] different default key sizes for CREATE and LUKSFORMAT

[Milan Broz]

On 11/18/2009 11:25 AM, Arno Wagner wrote:
> I am not sure this really is a security issue. It may confuse users,
> but they will still be secure. Most probably use defaults anyways.

Or distro installation defaults.. e.g. Fedora12 installer switched
to AES in XTS mode (with 512bit - so it uses AES-256)...

> But if we change this, I propose to make aes-cbc-essiv:sha256
> the default for plain dm-crypt and to increase LUKS key length 
> to 256 bits as well. The performance loss is apparently very 
> small (10% or so).

I thought about default change for LUKS in cryptsetup 1.1.0, but...

For default LUKS cipher:

I agree with switching default to 256bits for LUKS)
(aes-cbc-essiv:sha256 is already default), just some ideas

- some discussions about recent theoretic attacks against AES-256
(related key), maybe some people want use AES-128...

- for recent kernel, XTS mode is more appropriate, but it cause
backward incompatibility (XTS is not available in old kernels)
(IOW default to aes-xts-plain ?)

(Ignoring the 32-only plain IV problem here, because XTS suggested use
is for volumes <1TB. I have already patch for plain64 dm-crypt IV btw,
just it got lost in Alasdair's upstream patch queue.)

For default LUKS header hash:

- default is SHA1

switching to another (probably SHA-256?) means complete incompatibility
with all cryptsetup <1.1.x, this need some time when all most distros
use new cryptsetup.
No need to hurry, there is no problem with SHA1 in this application
of hash function.

For plain cipher mode:

I am not sure if it is good idea to change default, if anyone using
default in crypttab, it cause serious incompatibility with possible data loss.
But I agree that aes-cbc-essiv:sha256 is better default here.

Can distro maintainers think about this? There is not problem
for encryption of swap using random key.
Maybe it will need some warning during upgrade if there is such plain
volume in crypttab.

Please correct me if I am wrong:-)

So, if there are no objections, I'll change default key size for LUKS to 256bits
in final cryptsetup 1.1.0 release. The plain default is still open question.

Milan
--
mbroz@redhat.com

Re: [dm-crypt] different default key sizes for CREATE and LUKSFORMAT

[Milan Broz]

On 11/18/2009 12:20 PM, Milan Broz wrote:
> For default LUKS header hash:
> 
> - default is SHA1
> 
> switching to another (probably SHA-256?) means complete incompatibility
> with all cryptsetup <1.1.x, this need some time when all most distros
> use new cryptsetup.
> No need to hurry, there is no problem with SHA1 in this application
> of hash function.

Also I think we can increase MK digest iterations
(default is now 10, increasing it to 1000 should not cause any performance
problems. Just make the possible attack to MK digest more complicated
if some hash is completely broken in future.)

Does this make sense of it is not needed?

Milan

Re: [dm-crypt] different default key sizes for CREATE and LUKSFORMAT

[Heinz Diehl]

On 18.11.2009, Milan Broz wrote: 

> Does this make sense of it is not needed?

That makes good sense, just do it :-)

Re: [dm-crypt] different default key sizes for CREATE and LUKSFORMAT

[Arno Wagner]

On Wed, Nov 18, 2009 at 12:20:05PM +0100, Milan Broz wrote:
> On 11/18/2009 11:25 AM, Arno Wagner wrote:
> > I am not sure this really is a security issue. It may confuse users,
> > but they will still be secure. Most probably use defaults anyways.
> 
> Or distro installation defaults.. e.g. Fedora12 installer switched
> to AES in XTS mode (with 512bit - so it uses AES-256)...
 
> > But if we change this, I propose to make aes-cbc-essiv:sha256
> > the default for plain dm-crypt and to increase LUKS key length 
> > to 256 bits as well. The performance loss is apparently very 
> > small (10% or so).
> 
> I thought about default change for LUKS in cryptsetup 1.1.0, but...
> 
> For default LUKS cipher:
> 
> I agree with switching default to 256bits for LUKS)
> (aes-cbc-essiv:sha256 is already default), just some ideas
> 
> - some discussions about recent theoretic attacks against AES-256
> (related key), maybe some people want use AES-128...

Last I read was that they have something of similar strength for 
AES-128 now. I think the currenct worst case is that AES-256
drops down to the security level of AES-128. IS somebody really
wants AES--128, they can still override the defaults.

> - for recent kernel, XTS mode is more appropriate, but it cause
> backward incompatibility (XTS is not available in old kernels)
> (IOW default to aes-xts-plain ?)
> 
> (Ignoring the 32-only plain IV problem here, because XTS suggested use
> is for volumes <1TB. I have already patch for plain64 dm-crypt IV btw,
> just it got lost in Alasdair's upstream patch queue.)

Hmm. Well, XTS has more reputable support as essiv (which was done by
Clemens himself), and the provision against doing your own crypto may 
apply. Personally, I see nothing wrong with essiv, and it cannot really 
be less secure thain plain CBC.
 
> For default LUKS header hash:
> 
> - default is SHA1
> 
> switching to another (probably SHA-256?) means complete incompatibility
> with all cryptsetup <1.1.x, this need some time when all most distros
> use new cryptsetup.
> No need to hurry, there is no problem with SHA1 in this application
> of hash function.

I completely agree. The current attacks on sha1 do not even suggest 
a possible attack against its use here. IN addition, SHA256 is more
of a stopgap, so if no emergency arises (SHA1 easily reversible or 
the like), it is probably bets to wait for the outcome of NIST's
hash challenge for a possible replacement.

 
> For plain cipher mode:
> 
> I am not sure if it is good idea to change default, if anyone using
> default in crypttab, it cause serious incompatibility with possible 
> data loss.
> But I agree that aes-cbc-essiv:sha256 is better default here.
> 
> Can distro maintainers think about this? There is not problem
> for encryption of swap using random key.
> Maybe it will need some warning during upgrade if there is such plain
> volume in crypttab.

I think an appropriate warning on packet upgrade is needed (hence the
distro's job, a clear warning in README/INSTALL/CHANGELOG is certainly 
a good idea). Crypttab can be adjusted to list a different cipher per 
volume after all, it just has to be done. It would also be possible 
to ask the user on packet upgrade whether all old entries without
cipher specification should be marked with the old default to keep 
them going.
 
> Please correct me if I am wrong:-)
> 
> So, if there are no objections, I'll change default key size for LUKS to
> 256bits in final cryptsetup 1.1.0 release. The plain default is still open
> question.

Sounds reasonable.

Arno

-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

Re: [dm-crypt] different default key sizes for CREATE and LUKSFORMAT

[Arno Wagner]

On Wed, Nov 18, 2009 at 02:26:10PM +0100, Milan Broz wrote:
> On 11/18/2009 12:20 PM, Milan Broz wrote:
> > For default LUKS header hash:
> > 
> > - default is SHA1
> > 
> > switching to another (probably SHA-256?) means complete incompatibility
> > with all cryptsetup <1.1.x, this need some time when all most distros
> > use new cryptsetup.
> > No need to hurry, there is no problem with SHA1 in this application
> > of hash function.
> 
> Also I think we can increase MK digest iterations
> (default is now 10, increasing it to 1000 should not cause any performance
> problems. Just make the possible attack to MK digest more complicated
> if some hash is completely broken in future.)
> 
> Does this make sense of it is not needed?

If I understand this correctly, this is the "iteration-count" 
parameter to PBKDF2. If so, then RFC 2898 recommends a minimum 
count of 1000 anyways. This is hovever not protection against 
a broken hash, as even a very weak hash should be extremely 
hard to break when iterated 10 times. The main purpose of this 
parameter is to make exhaustive search more expensive. I think 
this should definitely go up to 1000.

Arno
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

Re: [dm-crypt] different default key sizes for CREATE and LUKSFORMAT

[Heinz Diehl]

On 19.11.2009, Arno Wagner wrote: 

> If I understand this correctly, this is the "iteration-count" 
> parameter to PBKDF2. If so, then RFC 2898 recommends a minimum 
> count of 1000 anyways.

This has been discussed in various places, and the conclusion was that it
should not be lower than 50.000 iterations. See f.ex. rfc3962 on
implemetation of PBKDF2 for Kerberos5.

> The main purpose of this parameter is to make exhaustive search more expensive.

Yes, it should make bruteforcing a lot more time-expensive.

> I think this should definitely go up to 1000.

I think this should maybe go up to 50.000 or 100.000. 
If I understood all correctly, so should a bump-up to 100.000 not have
much noticeable impact on the main speed either.

Please correct me if I'm wrong.

Thanks,
Heinz.

Re: [dm-crypt] different default key sizes for CREATE and LUKSFORMAT

[Arno Wagner]

On Thu, Nov 19, 2009 at 10:21:07AM +0100, Heinz Diehl wrote:
> On 19.11.2009, Arno Wagner wrote: 
> 
> > If I understand this correctly, this is the "iteration-count" 
> > parameter to PBKDF2. If so, then RFC 2898 recommends a minimum 
> > count of 1000 anyways.
> 
> This has been discussed in various places, and the conclusion was that it
> should not be lower than 50.000 iterations. See f.ex. rfc3962 on
> implemetation of PBKDF2 for Kerberos5.
> 
> > The main purpose of this parameter is to make exhaustive search more expensive.
> 
> Yes, it should make bruteforcing a lot more time-expensive.
> 
> > I think this should definitely go up to 1000.
> 
> I think this should maybe go up to 50.000 or 100.000. 
> If I understood all correctly, so should a bump-up to 100.000 not have
> much noticeable impact on the main speed either.
> 
> Please correct me if I'm wrong.

Just did a few benchmarks with a 10MB loopback on a dual
Athlon 64 5600+. As the master key iterations are not accessible
via commandline, I have tried some time settings for the
slot key (-i <milisec>). They should have similar effort.

Iteration time     Iterations     time (elapsed) for luksOpen
   1 ms                 301              1.01 sec             
  10 ms               3 029              1.01 sec
 100 ms              30 247              1.06 sec 
   1 sec            303 694              1.51 sec
  10 sec          3 043 420              6.02 sec
 100 sec         30 212 200             50.92 sec
 
Ok, something is going on, that should be > 100 sec on the
last one. Nonetheless a rough estimation is possible. Maybe
a cache issue.

I would estimate that the time for 100'000 iterations is below
1 sec even for weak systems. For mine it is around 0.15 sec.

This makes going to 100'000 on mk_iter entirely feasible.

I curretntly do not see whether this is really needed, but 
clearly it is not a problem and 100'000 is the recommended
value, so let's use it. Anybody having real slowdown because
they run this on a 25 Mhz 386SX CPU can still reduce the
count via commandline.

Arno
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

Re: [dm-crypt] different default key sizes for CREATE and LUKSFORMAT

[Arno Wagner]

On Thu, Nov 19, 2009 at 01:24:45PM +0100, Arno Wagner wrote:
[...]
> I curretntly do not see whether this is really needed, but 
> clearly it is not a problem and 100'000 is the recommended
> value, so let's use it. Anybody having real slowdown because
> they run this on a 25 Mhz 386SX CPU can still reduce the
> count via commandline.

Ah, nonsense. Better: It would be good to have a commandline
option to reduce/set the mk_iter count. That would be good anyways.

Arno

-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

Re: [dm-crypt] different default key sizes for CREATE and LUKSFORMAT

[Heinz Diehl]

On 19.11.2009, Arno Wagner wrote: 

> Anybody having real slowdown because they run this 
> on a 25 Mhz 386SX CPU can still reduce the count via commandline.

I'm afraid there is no commandline option to change that. "--iter-time" is 
related to the iterations of the passphrase, not the MK.

Re: [dm-crypt] different default key sizes for CREATE and LUKSFORMAT

[Stefan Xenon]

Nevertheless how many iterations are agreed it seems that the amount of
iterations will be increased in a next version. Does this require to
"upgrade" an already existing partition created with the current default
values or is it sufficient just to use the new version? If an "upgrade"
would be required, how to do it?

Cheers
Stefan

Arno Wagner schrieb:
> On Thu, Nov 19, 2009 at 10:21:07AM +0100, Heinz Diehl wrote:
>> On 19.11.2009, Arno Wagner wrote: 
>>
>>> If I understand this correctly, this is the "iteration-count" 
>>> parameter to PBKDF2. If so, then RFC 2898 recommends a minimum 
>>> count of 1000 anyways.
>> This has been discussed in various places, and the conclusion was that it
>> should not be lower than 50.000 iterations. See f.ex. rfc3962 on
>> implemetation of PBKDF2 for Kerberos5.
>>
>>> The main purpose of this parameter is to make exhaustive search more expensive.
>> Yes, it should make bruteforcing a lot more time-expensive.
>>
>>> I think this should definitely go up to 1000.
>> I think this should maybe go up to 50.000 or 100.000. 
>> If I understood all correctly, so should a bump-up to 100.000 not have
>> much noticeable impact on the main speed either.
>>
>> Please correct me if I'm wrong.
> 
> Just did a few benchmarks with a 10MB loopback on a dual
> Athlon 64 5600+. As the master key iterations are not accessible
> via commandline, I have tried some time settings for the
> slot key (-i <milisec>). They should have similar effort.
> 
> Iteration time     Iterations     time (elapsed) for luksOpen
>    1 ms                 301              1.01 sec             
>   10 ms               3 029              1.01 sec
>  100 ms              30 247              1.06 sec 
>    1 sec            303 694              1.51 sec
>   10 sec          3 043 420              6.02 sec
>  100 sec         30 212 200             50.92 sec
>  
> Ok, something is going on, that should be > 100 sec on the
> last one. Nonetheless a rough estimation is possible. Maybe
> a cache issue.
> 
> I would estimate that the time for 100'000 iterations is below
> 1 sec even for weak systems. For mine it is around 0.15 sec.
> 
> This makes going to 100'000 on mk_iter entirely feasible.
> 
> I curretntly do not see whether this is really needed, but 
> clearly it is not a problem and 100'000 is the recommended
> value, so let's use it. Anybody having real slowdown because
> they run this on a 25 Mhz 386SX CPU can still reduce the
> count via commandline.
> 
> Arno

Re: [dm-crypt] different default key sizes for CREATE and LUKSFORMAT

[Milan Broz]

On 11/19/2009 02:00 PM, Heinz Diehl wrote:
> On 19.11.2009, Arno Wagner wrote: 
> 
>> Anybody having real slowdown because they run this 
>> on a 25 Mhz 386SX CPU can still reduce the count via commandline.
> 
> I'm afraid there is no commandline option to change that. "--iter-time" is 
> related to the iterations of the passphrase, not the MK.

yes but I do not want add another iteration option, too confusing to users.

What about derive the MK digest iteration count from calculated keyslot
iteration time (I suggest 1/5 of calculated time) - so for default 1 second
it is cca 200ms - not accurate, because benchmark uses different message on input)
but with minimum 1000 iterations?

(on my quite slow testing VM it is cca 20000 iterations)

This should be enough.
This will add maximum 1.6 second processing time if all 8 slots is used,
so it is acceptable but also provides needed slow-down for brute force.

Milan
--
mbroz@redhat.com

Re: [dm-crypt] different default key sizes for CREATE and LUKSFORMAT

[Milan Broz]

On 11/19/2009 09:00 PM, Stefan Xenon wrote:
> Nevertheless how many iterations are agreed it seems that the amount of
> iterations will be increased in a next version. Does this require to
> "upgrade" an already existing partition created with the current default
> values or is it sufficient just to use the new version? If an "upgrade"
> would be required, how to do it?

You can now format using pre-generated master key, so you can reformat luks header
without data loss (you will need to know all used passphrases though and specify
exactly the same other arguments like cipher and data offset)

Probably not big problem to write a script or C program using libcryptsetup
to automate this. (libcryptsetup API have all needed calls now).
(I thought about luksReFormat command but not sure if it is really needed.)

But I think better no automatic updates of header here (it causes MK digest change)

Milan
--
mbroz@redhat.com

Re: [dm-crypt] different default key sizes for CREATE and LUKSFORMAT

[Jonas Meurer]

[-- Attachment #1: Type: text/plain, Size: 2079 bytes --]

hey milan,

On 18/11/2009 Milan Broz wrote:
> I thought about default change for LUKS in cryptsetup 1.1.0, but...
> 
> For default LUKS cipher:
> 
> I agree with switching default to 256bits for LUKS)
> (aes-cbc-essiv:sha256 is already default), just some ideas
> 
> - some discussions about recent theoretic attacks against AES-256
> (related key), maybe some people want use AES-128...
> 
> - for recent kernel, XTS mode is more appropriate, but it cause
> backward incompatibility (XTS is not available in old kernels)
> (IOW default to aes-xts-plain ?)
> 
> (Ignoring the 32-only plain IV problem here, because XTS suggested use
> is for volumes <1TB. I have already patch for plain64 dm-crypt IV btw,
> just it got lost in Alasdair's upstream patch queue.)
> 
> For default LUKS header hash:
> 
> - default is SHA1
> 
> switching to another (probably SHA-256?) means complete incompatibility
> with all cryptsetup <1.1.x, this need some time when all most distros
> use new cryptsetup.
> No need to hurry, there is no problem with SHA1 in this application
> of hash function.
> 
> For plain cipher mode:
> 
> I am not sure if it is good idea to change default, if anyone using
> default in crypttab, it cause serious incompatibility with possible data loss.
> But I agree that aes-cbc-essiv:sha256 is better default here.
> 
> Can distro maintainers think about this? There is not problem
> for encryption of swap using random key.
> Maybe it will need some warning during upgrade if there is such plain
> volume in crypttab.

in debian we already warned the users to explicitly set all cipher, size
and hash settings for plain dm-crypt in /etc/crypttab, as defaults may
change with new releases.

so no objections from me against changing defaults in 1.1.0 release.

> So, if there are no objections, I'll change default key size for LUKS to 256bits
> in final cryptsetup 1.1.0 release. The plain default is still open question.

please go ahead, and i also vote for changing plain default as well.

greetings,
 jonas

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [dm-crypt] different default key sizes for CREATE and LUKSFORMAT

[Heinz Diehl]

On 20.11.2009, Milan Broz wrote: 

> What about derive the MK digest iteration count from calculated keyslot
> iteration time (I suggest 1/5 of calculated time) - so for default 1 second
> it is cca 200ms - not accurate, because benchmark uses different message on input)
> but with minimum 1000 iterations?

Sounds fine to me (and is a good and practical idea, too).

Thanks,
Heinz.

Re: [dm-crypt] different default key sizes for CREATE and LUKSFORMAT

[Arno Wagner]

On Fri, Nov 20, 2009 at 01:14:56PM +0100, Milan Broz wrote:
> On 11/19/2009 02:00 PM, Heinz Diehl wrote:
> > On 19.11.2009, Arno Wagner wrote: 
> > 
> >> Anybody having real slowdown because they run this 
> >> on a 25 Mhz 386SX CPU can still reduce the count via commandline.
> > 
> > I'm afraid there is no commandline option to change that. "--iter-time" is 
> > related to the iterations of the passphrase, not the MK.
> 
> yes but I do not want add another iteration option, too confusing to users.
> 
> What about derive the MK digest iteration count from calculated keyslot
> iteration time (I suggest 1/5 of calculated time) - so for default 1 second
> it is cca 200ms - not accurate, because benchmark uses different message on input)
> but with minimum 1000 iterations?
> 
> (on my quite slow testing VM it is cca 20000 iterations)
> 
> This should be enough.
> This will add maximum 1.6 second processing time if all 8 slots is used,
> so it is acceptable but also provides needed slow-down for brute force.
> 
> Milan

Good idea, I like it. However use the same time as for the keyslots.
There is really no reason to have one use less iterations than
the other. 

The two iterations are linked security-wise, so treating them the same
makes sense.

Incidentially, it should only add the time once, there is only
one Master Key. 

Arno
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

Re: [dm-crypt] different default key sizes for CREATE and LUKSFORMAT

[Stefan Xenon]

> Good idea, I like it. However use the same time as for the keyslots.
> There is really no reason to have one use less iterations than
> the other. 
> 
> The two iterations are linked security-wise, so treating them the same
> makes sense.
> 
> Incidentially, it should only add the time once, there is only
> one Master Key. 

Sounds good for me as well. While I don't know the details I am
wondering if the result may be influenced by other processes executed at
the same time. This means, when heavy processes are running in the
background (e.g. compilation), the iteration calculation may become
slower and thus the amount of iterations smaller as it would be
normally. Please note that I don't know the implementation details but
just want to point out this theoretical problem.

Also the possibility to recalculate the iterations might be useful,
after an upgrade of the computer (but with remaining storage device).
Especially external hard drives might be in use for more years compared
to the CPU.

Stefan

Re: [dm-crypt] different default key sizes for CREATE and LUKSFORMAT

[Arno Wagner]

On Sat, Nov 21, 2009 at 01:40:05PM +0100, Stefan Xenon wrote:
> > Good idea, I like it. However use the same time as for the keyslots.
> > There is really no reason to have one use less iterations than
> > the other. 
> > 
> > The two iterations are linked security-wise, so treating them the same
> > makes sense.
> > 
> > Incidentially, it should only add the time once, there is only
> > one Master Key. 
> 
> Sounds good for me as well. While I don't know the details I am
> wondering if the result may be influenced by other processes executed at
> the same time. This means, when heavy processes are running in the
> background (e.g. compilation), the iteration calculation may become
> slower and thus the amount of iterations smaller as it would be
> normally. Please note that I don't know the implementation details but
> just want to point out this theoretical problem.

Sopuld not be an issue. If done right, this is CPU miliseconds,
not elapsed miliseconds. An being off by 50% does not matter
a lot in this application anyways.
 
> Also the possibility to recalculate the iterations might be useful,
> after an upgrade of the computer (but with remaining storage device).
> Especially external hard drives might be in use for more years compared
> to the CPU.

That is done on reformat, which also is really the only simple
way to change such a setting. On the other hand, the used values
are already intended for "many years", so I think this is not
a concern.

Arno
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

Re: [dm-crypt] different default key sizes for CREATE and LUKSFORMAT

[Roscoe]

On Thu, Nov 19, 2009 at 5:41 PM, Arno Wagner <arno@wagner.name> wrote:
> If I understand this correctly, this is the "iteration-count"
> parameter to PBKDF2. If so, then RFC 2898 recommends a minimum
> count of 1000 anyways. This is hovever not protection against
> a broken hash, as even a very weak hash should be extremely
> hard to break when iterated 10 times. The main purpose of this
> parameter is to make exhaustive search more expensive. I think
> this should definitely go up to 1000.

I'd like to point out that this use of PBKDF2 is is not as a KDF but
as a hash function. The recommendations in the RFC 2898 will be from a
KDF perspective. The idea of someone doing an exhaustive search in the
LUKS mk context seems silly (RNG quality aside)

-- Roscoe.

Re: [dm-crypt] different default key sizes for CREATE and LUKSFORMAT

[Milan Broz]

On 11/23/2009 02:45 PM, Roscoe wrote:
> On Thu, Nov 19, 2009 at 5:41 PM, Arno Wagner <arno@wagner.name> wrote:
>> If I understand this correctly, this is the "iteration-count"
>> parameter to PBKDF2. If so, then RFC 2898 recommends a minimum
>> count of 1000 anyways. This is hovever not protection against
>> a broken hash, as even a very weak hash should be extremely
>> hard to break when iterated 10 times. The main purpose of this
>> parameter is to make exhaustive search more expensive. I think
>> this should definitely go up to 1000.
> 
> I'd like to point out that this use of PBKDF2 is is not as a KDF but
> as a hash function. The recommendations in the RFC 2898 will be from a
> KDF perspective. The idea of someone doing an exhaustive search in the
> LUKS mk context seems silly (RNG quality aside)

You are right, but note for normal exhaustive key search (brute force,
because key is random here) you need to know some plain text
on the disk (not problem with known FS signature though).

Here you have always digest of hashed key (+ known salt).
If the PBKDF2 with iterations is very quick and cheap,
the exhaustive search for key candidates is much more
simpler here than other technique.

Adding iterations for mk digest is quite cheap and almost make
this search unusable (even if it is just theoretic or silly attack).

Or am I missing anything?

Milan
--
mbroz@redhat.com

Re: [dm-crypt] different default key sizes for CREATE and LUKSFORMAT

[Arno Wagner]

On Mon, Nov 23, 2009 at 03:29:51PM +0100, Milan Broz wrote:
> On 11/23/2009 02:45 PM, Roscoe wrote:
> > On Thu, Nov 19, 2009 at 5:41 PM, Arno Wagner <arno@wagner.name> wrote:
> >> If I understand this correctly, this is the "iteration-count"
> >> parameter to PBKDF2. If so, then RFC 2898 recommends a minimum
> >> count of 1000 anyways. This is hovever not protection against
> >> a broken hash, as even a very weak hash should be extremely
> >> hard to break when iterated 10 times. The main purpose of this
> >> parameter is to make exhaustive search more expensive. I think
> >> this should definitely go up to 1000.
> > 
> > I'd like to point out that this use of PBKDF2 is is not as a KDF but
> > as a hash function. The recommendations in the RFC 2898 will be from a
> > KDF perspective. The idea of someone doing an exhaustive search in the
> > LUKS mk context seems silly (RNG quality aside)
> 
> You are right, but note for normal exhaustive key search (brute force,
> because key is random here) you need to know some plain text
> on the disk (not problem with known FS signature though).
> 
> Here you have always digest of hashed key (+ known salt).
> If the PBKDF2 with iterations is very quick and cheap,
> the exhaustive search for key candidates is much more
> simpler here than other technique.
> 
> Adding iterations for mk digest is quite cheap and almost make
> this search unusable (even if it is just theoretic or silly attack).
> 
> Or am I missing anything?

Well, it depends on th size of the key and its entropy
contents. If it is a >= 128 bit high entropy key, then
exhaustive search will not work, no matter what. If
the entropy is lower (bad PRNG), a high interation
count will make the search a lot harder. 
 
As we have seen in the past, messing up randomness for 
crypto does happen. Example: The last Debian problem 
ith OpenSSL, although the resulting key space was so 
small (16 bit), that requiring a second of hashing 
would only have lead to a day or so of attack time. But 
if a key has only, say, 40 bits of entropy, a second of
hashing gives something like 17'000 years of CPU time
for exhaustive search. Doable but expensive.

Bottom line: This should not be needed, but it 
does make the whole construct more resilient 
against bad PRNG and it has not real cost as it 
is a one-time effort on volume mount.

Arno

-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

Re: [dm-crypt] different default key sizes for CREATE and LUKSFORMAT

[Heinz Diehl]

On 23.11.2009, Milan Broz wrote: 

> Adding iterations for mk digest is quite cheap and almost make
> this search unusable (even if it is just theoretic or silly attack).
 
> Or am I missing anything?

Nope, you're absolutely right.