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

[Arno Wagner <arno@wagner.name>]

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