[dm-crypt] list of supported encryption options for LUKS

[dm-crypt] list of supported encryption options for LUKS

[.. ink ..]

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

The most requested feature in my project zuluCrypt has been to have an
option
to set encryption options when creating a volume and i have decided to
implement it
after just receiving another feature request.

"cryptsetup benchmark" mentions a few different combinations and i am
wondering if
these combinations are the only ones supported or if there are more
supported combinations.

[-- Attachment #2: Type: text/html, Size: 494 bytes --]

Re: [dm-crypt] list of supported encryption options for LUKS

[Milan Broz]

On 09/07/2014 06:15 PM, .. ink .. wrote:
> 
> The most requested feature in my project zuluCrypt has been to have an option
> to set encryption options when creating a volume and i have decided to implement it
> after just receiving another feature request.
> 
> "cryptsetup benchmark" mentions a few different combinations and i am wondering if
> these combinations are the only ones supported or if there are more supported combinations.

These are just common and widely used. (I selected AES finalist mainly to
compare speed on particular machine.)

You can use and test anything what kernel provides but you have to know key size etc
(IIRC for blockiphers kernel supports more options including e.g. camelia, cast,
blowfish, ... Dito for block modes. See for example tcrypt tests which tests all
Truecrypt historic images, there are more ciphers.)

But from my experience, I am against providing too many easy available options
for non-expert users.
(Sadly, cryptsetup already requires user to fiddle with too many options sometimes.)

Security experts know how to switch it if needed (and it will be always possible)
but simple list box containing all possible variants will not help anything.

People tend to experiment without thinking about security (and even practical) consequences. 
("I read SHA1 is insecure so I used whirpool everywhere." Recent story...)

If you are able to provide some comment to options (TrueCrypt tried to do that)
it can be better, at least someone read it and decides according to comment.

But I still think that there should be only few strong predefined combinations.

Why the users want to change default?
What's the real problem - cipher speed or they do not trust NIS and NSA or ...
they just want more knobs because more knobs means more security :-) ?

Milan

Re: [dm-crypt] list of supported encryption options for LUKS

[.. ink ..]

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

> But I still think that there should be only few strong predefined
> combinations.
>
>  I will go with only those mentioned in the benchmark as "supported
options".

Why the users want to change default?

What's the real problem - cipher speed or they do not trust NIS and NSA or
> ...
> they just want more knobs because more knobs means more security :-) ?
>
>
I currently do not allow options because i though defaults were good for
everybody but people keep asking for
ability to change them.This post[1] is a good example of that They wished
for more options but did not specify why.

About a week ago,somebody sent me a zuluCrypt source file and asked me to
modify it to change hard coded defaults.They wanted different defaults but
did not trust themselves to change the source file so they asked me to do
it for them.

[1]
http://www.wilderssecurity.com/threads/zulucrypt-easily-create-and-manage-luks-plain-truecrypt-volumes-and-partitions.363255/

[-- Attachment #2: Type: text/html, Size: 1701 bytes --]

Re: [dm-crypt] list of supported encryption options for LUKS

[Arno Wagner]

On Sun, Sep 07, 2014 at 19:30:00 CEST, .. ink .. wrote:
> > But I still think that there should be only few strong predefined
> > combinations.
> >
> >  I will go with only those mentioned in the benchmark as "supported
> options".
> 
> Why the users want to change default?
> 
> What's the real problem - cipher speed or they do not trust NIS and NSA or
> > ...
> > they just want more knobs because more knobs means more security :-) ?
> >
> >
> I currently do not allow options because i though defaults were good for
> everybody but people keep asking for
> ability to change them.This post[1] is a good example of that They wished
> for more options but did not specify why.
> 
> About a week ago,somebody sent me a zuluCrypt source file and asked me to
> modify it to change hard coded defaults.They wanted different defaults but
> did not trust themselves to change the source file so they asked me to do
> it for them.

That is really hilarious: People that do not trust themselves to 
change a few strings, but do trust themselves to evaluate what 
crypto is secure and what is not.

I guess people really have no clue how easy it is to completely break
security with wrong crypto parameters. You should not give in or
at the very least put up strong warnings. Some people will always
manage to shoot themselves in the foot (Dunning-Kruger effect at work),
but at least you can then say "I told you so". 

Arno

> 
> [1]
> http://www.wilderssecurity.com/threads/zulucrypt-easily-create-and-manage-luks-plain-truecrypt-volumes-and-partitions.363255/

> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt


-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

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] list of supported encryption options for LUKS

[Arno Wagner]

On Sun, Sep 07, 2014 at 18:59:21 CEST, Milan Broz wrote:
> On 09/07/2014 06:15 PM, .. ink .. wrote:
> > 
> > The most requested feature in my project zuluCrypt has been to have an
> > option to set encryption options when creating a volume and i have
> > decided to implement it after just receiving another feature request.
> > 
> > "cryptsetup benchmark" mentions a few different combinations and i am
> > wondering if these combinations are the only ones supported or if there
> > are more supported combinations.
> 
> These are just common and widely used. (I selected AES finalist mainly to
> compare speed on particular machine.)
> 
> You can use and test anything what kernel provides but you have to know
> key size etc (IIRC for blockiphers kernel supports more options including
> e.g.  camelia, cast, blowfish, ...  Dito for block modes.  See for example
> tcrypt tests which tests all Truecrypt historic images, there are more
> ciphers.)

Also remember that you need a block cipher for the cipher. Milan 
rightfully pointed this out to me when, in a moment of madness, I 
tried to use RC4 for FAQ Item 6.13. 
 
> But from my experience, I am against providing too many easy available
> options for non-expert users.  (Sadly, cryptsetup already requires user to
> fiddle with too many options sometimes.)

There really is no good way around that. Sadly, security needs
some understanding of things as there are too many attackers
that do not care one bit about the user's security, some of them 
even able to influence hardware and Linux distros.

> Security experts know how to switch it if needed (and it will be always
> possible) but simple list box containing all possible variants will not
> help anything.
> 
> People tend to experiment without thinking about security (and even
> practical) consequences.  ("I read SHA1 is insecure so I used whirpool
> everywhere." Recent story...)

Argggghh! Yes, see FAQ Item 5.20. People are actively getting less
security by messing with settings. Or see Example 2 in FAQ Item 6.13: 
You can use Blowfish with 64 Bit keys, giving you no security against
an attacker with modest security, but it is nicely fast. And a 
non-expert may just think that 64 bits of key are enough.
 
> If you are able to provide some comment to options (TrueCrypt tried to do
> that) it can be better, at least someone read it and decides according to
> comment.

I think you should at the very least warn of low key-lengths, 
broken or expected-to-be-broken soon hashes, insecure modes
(CBC) etc.
 
> But I still think that there should be only few strong predefined
> combinations.

Or at least a few strong suggested combination and strong 
warnings against not using them. For example, the AES finalists
should be fine, ciphers that dropped out earlies are likely
not. 
 
> Why the users want to change default?

> What's the real problem - cipher speed or they do not trust 
> NIS and NSA or ...  they just want more knobs because more 
> knobs means more security :-)
> ?

I think it is mostly a general mistrust against the NSA and NIST
(both deservedly), coupled with no understanding what actually
got compromised by the NSA. Most people do not even know that
the NSA has different parts and some are really dedicated to
making things more secure. People are even mistrusting SELinux
because that was done by the NSA, and completely disregard that
this is an access layer and backdoors can be spotted relatively
easily (i.e. high risk for the NSA of getting caught), unlike 
some crypto-backdoors, where spotting them is impossible.

For example, I really doubt the NSA did anything to weaken AES, 
but the curves for their ECC CPRNG are more than fishy, as is 
Intels RDRAND design. Both are compromised designs, as there is
no way for anybody outside to verify their security. To make
things even more complicated, a compromised design does not
mean things are compromised, the CPRNG and RDRAND could be
perfectly secure. Nobody believes that, of course, but anybody
not a crypto-expert will be completely confused at this point.

To make matters worse, deciding whom to trust when you are not an
expert is really difficult, especially when you see, e.g. Google 
using RC4 for SSL. Are they compromised? Are they just trying to 
save cycles? Do they maybe know that the NSA cannot break RC4 
wholesale? Impossible to answer for a non-expert. Hence people
try to protect themselves by suspecting the defaults and end
up making matters worse.

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

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] list of supported encryption options for LUKS

[.. ink ..]

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

On Sun, Sep 7, 2014 at 12:59 PM, Milan Broz <gmazyland@gmail.com> wrote:



> But I still think that there should be only few strong predefined
> combinations.
>
>
The list of option i am going to support for LUKS volumes is listed below
as taken from cryptsetup benchmark list.

First condition is for plain volumes,second condition for luks and the last
one is for truecrypt.

https://github.com/mhogomchungu/zuluCrypt/blob/c99841c21a6edeea955106134fd54d5935f8e237/zuluCrypt-gui/createvolume.cpp#L238

[-- Attachment #2: Type: text/html, Size: 1038 bytes --]

Re: [dm-crypt] list of supported encryption options for LUKS

[Arno Wagner]

On Mon, Sep 08, 2014 at 21:42:06 CEST, .. ink .. wrote:
> On Sun, Sep 7, 2014 at 12:59 PM, Milan Broz <gmazyland@gmail.com> wrote:
> 
> 
> 
> > But I still think that there should be only few strong predefined
> > combinations.
> >
> >
> The list of option i am going to support for LUKS volumes is listed below
> as taken from cryptsetup benchmark list.
> 
> First condition is for plain volumes,second condition for luks and the last
> one is for truecrypt.
> 
> https://github.com/mhogomchungu/zuluCrypt/blob/c99841c21a6edeea955106134fd54d5935f8e237/zuluCrypt-gui/createvolume.cpp#L238

I would add a warning about gcrypt (see FAQ 8.3) for all
variants with whirlpool. Some people may still use this with
the broken gcrypt implementation.

Apart from that, the list looks fine.

Side-question:
Are the multi-cipher variants like "twofish:aes.xts-plain64.256.ripemd160"
something you do yourself? How do you do them? Additional 
LUKS layers with the same passphrase set-up?

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

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] list of supported encryption options for LUKS

[Arno Wagner]

On Tue, Sep 09, 2014 at 00:33:09 CEST, Arno Wagner wrote:
> On Mon, Sep 08, 2014 at 21:42:06 CEST, .. ink .. wrote:
> > On Sun, Sep 7, 2014 at 12:59 PM, Milan Broz <gmazyland@gmail.com> wrote:
> > 
> > 
> > 
> > > But I still think that there should be only few strong predefined
> > > combinations.
> > >
> > >
> > The list of option i am going to support for LUKS volumes is listed below
> > as taken from cryptsetup benchmark list.
> > 
> > First condition is for plain volumes,second condition for luks and the last
> > one is for truecrypt.
> > 
> > https://github.com/mhogomchungu/zuluCrypt/blob/c99841c21a6edeea955106134fd54d5935f8e237/zuluCrypt-gui/createvolume.cpp#L238
> 
> I would add a warning about gcrypt (see FAQ 8.3) for all
> variants with whirlpool. Some people may still use this with
> the broken gcrypt implementation.
> 
> Apart from that, the list looks fine.
> 
> Side-question:
> Are the multi-cipher variants like "twofish:aes.xts-plain64.256.ripemd160"
> something you do yourself? How do you do them? Additional 
> LUKS layers with the same passphrase set-up?

Ah, sorry, they are for TrueCrypt, obviously.

Arno

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

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] list of supported encryption options for LUKS

[.. ink ..]

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

On Mon, Sep 8, 2014 at 6:33 PM, Arno Wagner <arno@wagner.name> wrote:


> I would add a warning about gcrypt (see FAQ 8.3) for all
> variants with whirlpool. Some people may still use this with
> the broken gcrypt implementation.
>
>
Thanks for the tip.

I have decided to go with allowing whirlpool usage only if the project was
build with libgcrypt >= 1.6.1 and libcryptsetup >= 1.6.4

If the two conditions are not met,the option will not be listed in the GUI
component and the CLI component will just error out.

[-- Attachment #2: Type: text/html, Size: 967 bytes --]