[dm-crypt] Few questions from a new user

[dm-crypt] Few questions from a new user

[Konrad]

I am new to disk encryption and I have been reading on it for the last 
days, but I am still confused on some points. I would appreciate if 
someone knowledgeable could clue me in.


1. Is SHA1 just as secure for this purpose as SHA512? After reading 
cryptsetup docs I have a feeling that yes, but I get conflicting 
opinions from various people, so I thought it's best ask at the source.

Also, does the hash used have any impact on performance of disk 
access/read/write once the system is booted? Again, I suppose not, but 
better to make sure, especially since my laptop is not a powerhouse.


2. The more I read, the more I am confused about the algorythms. 
Everything I read says that AES is the fastest, and Serpent is the 
slowest. But not according to my laptop:

$ cryptsetup benchmark
Tests are approximate using memory only (no storage IO).
PBKDF2-sha1       344926 iterations per second
PBKDF2-sha256     198593 iterations per second
PBKDF2-sha512     129007 iterations per second
PBKDF2-ripemd160  271933 iterations per second
PBKDF2-whirlpool  134295 iterations per second
#  Algorithm | Key |  Encryption |  Decryption
      aes-cbc   128b   149.8 MiB/s   147.9 MiB/s
  serpent-cbc   128b    51.0 MiB/s   196.4 MiB/s
  twofish-cbc   128b   127.6 MiB/s   152.5 MiB/s
      aes-cbc   256b   114.3 MiB/s   113.8 MiB/s
  serpent-cbc   256b    51.2 MiB/s   198.9 MiB/s
  twofish-cbc   256b   129.8 MiB/s   167.5 MiB/s
      aes-xts   256b   153.3 MiB/s   150.6 MiB/s
  serpent-xts   256b   176.4 MiB/s   184.1 MiB/s
  twofish-xts   256b   160.8 MiB/s   159.8 MiB/s
      aes-xts   512b   115.4 MiB/s   112.1 MiB/s
  serpent-xts   512b   178.6 MiB/s   184.2 MiB/s
  twofish-xts   512b   160.7 MiB/s   158.9 MiB/s

I suppose this is because it has no AES-IN optimisation (it is one of 
the last Core 2 Duo P9500), but still Serpent beats the others by quite 
a margin.
Plus, on top of that, it seems to be the fastest with the most complex 
key. I  thought it should be the other way around...?

So should I go ahead and use  serpent-xts   512b, or is there a catch?



3. I would like to do full disk encryption, and would like to have those 
methods of unlocking upon boot:
A - my short but complex password
B - long but easy-to-dictate password that I would give to people who 
need to access my laptop when I'm not there, without compromising my own 
password
C - if a USB key with key file is present, I want the computer to not as 
for the password upon boot

Are all three possible with dm-crypt+LUKS? And if so, do I have to set 
them all up while I enctypt my disks, or can B and/or C  be done 
afterwards?

Re: [dm-crypt] Few questions from a new user

[Arno Wagner]

Hi Konrad,

On Wed, Jan 08, 2014 at 23:35:42 CET, Konrad wrote:
> I am new to disk encryption and I have been reading on it for the
> last days, but I am still confused on some points. I would
> appreciate if someone knowledgeable could clue me in.

If you have not found it yet, the FAQ is at
http://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions
 
> 1. Is SHA1 just as secure for this purpose as SHA512? After reading
> cryptsetup docs I have a feeling that yes, but I get conflicting
> opinions from various people, so I thought it's best ask at the
> source.

It is. These "various people" likely do not understand what the
attacks on SHA1 actually are but merely heard that it was "insecure".
See also FAQ Item 5.20

> Also, does the hash used have any impact on performance of disk
> access/read/write once the system is booted? Again, I suppose not,
> but better to make sure, especially since my laptop is not a
> powerhouse.

No. It is used once when your passphrase is processed. After that,
the master-key is known to the kernel and used directly. See
also FAQ item 6.10

> 2. The more I read, the more I am confused about the algorythms.
> Everything I read says that AES is the fastest, and Serpent is the
> slowest. But not according to my laptop:
>
> $ cryptsetup benchmark
> Tests are approximate using memory only (no storage IO).
> PBKDF2-sha1       344926 iterations per second
> PBKDF2-sha256     198593 iterations per second
> PBKDF2-sha512     129007 iterations per second
> PBKDF2-ripemd160  271933 iterations per second
> PBKDF2-whirlpool  134295 iterations per second
> #  Algorithm | Key |  Encryption |  Decryption
>      aes-cbc   128b   149.8 MiB/s   147.9 MiB/s
>  serpent-cbc   128b    51.0 MiB/s   196.4 MiB/s
>  twofish-cbc   128b   127.6 MiB/s   152.5 MiB/s
>      aes-cbc   256b   114.3 MiB/s   113.8 MiB/s
>  serpent-cbc   256b    51.2 MiB/s   198.9 MiB/s
>  twofish-cbc   256b   129.8 MiB/s   167.5 MiB/s
>      aes-xts   256b   153.3 MiB/s   150.6 MiB/s
>  serpent-xts   256b   176.4 MiB/s   184.1 MiB/s
>  twofish-xts   256b   160.8 MiB/s   159.8 MiB/s
>      aes-xts   512b   115.4 MiB/s   112.1 MiB/s
>  serpent-xts   512b   178.6 MiB/s   184.2 MiB/s
>  twofish-xts   512b   160.7 MiB/s   158.9 MiB/s
> 
> I suppose this is because it has no AES-IN optimisation (it is one
> of the last Core 2 Duo P9500), but still Serpent beats the others by
> quite a margin.

Actually it does not. For CBC, Serpent is a lot slower for
encryption and in particular slower than most disks. That may 
or may not matter for your application. In the end, it depends
on the CPU.

> Plus, on top of that, it seems to be the fastest with the most
> complex key. I  thought it should be the other way around...?
> 
> So should I go ahead and use  serpent-xts   512b, or is there a catch?

The only catch is that serpent is less well studied than AES, but
possibly not much so as it was very nearly selected as AES.
Still, some new attacks may get less attention for Serpent.
 
> 3. I would like to do full disk encryption, and would like to have
> those methods of unlocking upon boot:
> A - my short but complex password
> B - long but easy-to-dictate password that I would give to people
> who need to access my laptop when I'm not there, without
> compromising my own password
> C - if a USB key with key file is present, I want the computer to
> not as for the password upon boot

That is a distribution question. cryptsetup does not support 
full-disk encryption in any way. For it to work, the distribution
needs to put some wrapper around cryptsetup into the initrd.
But this sounds like you would have to write what you want 
yourself for C. A and B are simply covered by the key-management
of LUKS. It tries to unlock each key-slot with the given passphrase, 
so A and B would be automatically recognized. 
 
> Are all three possible with dm-crypt+LUKS? And if so, do I have to
> set them all up while I enctypt my disks, or can B and/or C  be done
> afterwards?

B can be set up any time you like, C will likely require
that you write code and modify your initrd.

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
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.  --Tony Hoare

Re: [dm-crypt] Few questions from a new user

[.. ink ..]

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

On Thu, Jan 9, 2014 at 1:51 AM, Arno Wagner <arno@wagner.name> wrote:

> Hi Konrad,
>
> On Wed, Jan 08, 2014 at 23:35:42 CET, Konrad wrote:
> > I am new to disk encryption and I have been reading on it for the
> > last days, but I am still confused on some points. I would
> > appreciate if someone knowledgeable could clue me in.
>
> If you have not found it yet, the FAQ is at
> http://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions
>
> > 1. Is SHA1 just as secure for this purpose as SHA512? After reading
> > cryptsetup docs I have a feeling that yes, but I get conflicting
> > opinions from various people, so I thought it's best ask at the
> > source.
>
> It is. These "various people" likely do not understand what the
> attacks on SHA1 actually are but merely heard that it was "insecure".
> See also FAQ Item 5.20
>
>
We live in the world of twitter where you automatically loose when you need
to explain yourself.

More and more of this type of question will start to show up and this
inquiry just showed an explanation in the FAQ is not enought to offer
assurance and giving an answer each and every time here will get boring
pretty soon and rudeness will ensue.

Whats the worse that could happen if the default is switched to SHA2?If it
makes no practical difference,then switching seem to be a better
alternative just to silence these kind of questions as their existence puts
doubt in cryptsetup's security robustness.

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

Re: [dm-crypt] Few questions from a new user

[shmick]

.. ink ..:
> On Thu, Jan 9, 2014 at 1:51 AM, Arno Wagner <arno@wagner.name> wrote:
> 
>> Hi Konrad,
>>
>> On Wed, Jan 08, 2014 at 23:35:42 CET, Konrad wrote:
>>> I am new to disk encryption and I have been reading on it for the
>>> last days, but I am still confused on some points. I would
>>> appreciate if someone knowledgeable could clue me in.
>>
>> If you have not found it yet, the FAQ is at
>> http://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions
>>
>>> 1. Is SHA1 just as secure for this purpose as SHA512? After reading
>>> cryptsetup docs I have a feeling that yes, but I get conflicting
>>> opinions from various people, so I thought it's best ask at the
>>> source.
>>
>> It is. These "various people" likely do not understand what the
>> attacks on SHA1 actually are but merely heard that it was "insecure".
>> See also FAQ Item 5.20
>>
>>
> We live in the world of twitter where you automatically loose when you need
> to explain yourself.

you might - not everybody else does

> 
> More and more of this type of question will start to show up and this
> inquiry just showed an explanation in the FAQ is not enought to offer
> assurance and giving an answer each and every time here will get boring
> pretty soon and rudeness will ensue.

wouldn't need to if one slows down, takes a cup of coffee and read
elsewhere on the big old internet

patience is a virtue; you won't be secure if you're in a hurry

> 
> Whats the worse that could happen if the default is switched to SHA2?If it
> makes no practical difference,then switching seem to be a better
> alternative just to silence these kind of questions as their existence puts
> doubt in cryptsetup's security robustness.

you don't have to use defaults - you're free to do what you like

but show us that defaults are not safe; please do


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

Re: [dm-crypt] Few questions from a new user

[Arno Wagner]

On Thu, Jan 09, 2014 at 15:58:18 CET, shmick@riseup.net wrote:
> 
[...]
> patience is a virtue; you won't be secure if you're in a hurry

Not only that. Quite a few things become impossible to achieve 
without it. Those that want a magic button to make it all secure
all will only have that button but no security at all in the end.

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
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.  --Tony Hoare

Re: [dm-crypt] Few questions from a new user

[Arno Wagner]

On Thu, Jan 09, 2014 at 12:22:08 CET, .. ink .. wrote:
> On Thu, Jan 9, 2014 at 1:51 AM, Arno Wagner <arno@wagner.name> wrote:
[...]
> > It is. These "various people" likely do not understand what the
> > attacks on SHA1 actually are but merely heard that it was "insecure".
> > See also FAQ Item 5.20
> >
> >
> We live in the world of twitter where you automatically loose when you need
> to explain yourself.

Only apparently. You do not get security without understanding what
you are doing. The "twittiots" (just created that myself, but I 
do not claim originality ;-) have already lost here and nothing is
going to save them. Insignt and care cannot be replaces by anything
else. 

> More and more of this type of question will start to show up and this
> inquiry just showed an explanation in the FAQ is not enought to offer
> assurance and giving an answer each and every time here will get boring
> pretty soon and rudeness will ensue.

The FAQ is not read by most people. I am aware of that. Occasionally
I get feedback from people that are really glad to have found it though.

The primary use of the FAQ is to make an answer brief: 
   "See FAQ Item 5.20".

The secondary use is "I told you so" when yest somebody again manages 
to destroy their data becasue they have not bothered to find out how
to handle LUKS right. 

The tertiary use is for the few that are aware that this is difficult
and actually read the FAQ before messing up. 
 
> Whats the worse that could happen if the default is switched to SHA2?

Complete breakdown. The LUKS header does not support a hash-spec
in this place at the moment, so it would need to be done via
some kind of dirty hack. Also, SHA2 may not actually be much
more secure than SHA1. It is usually only recommended as 
intermediate solution until SHA-3 becomes available. As the
NSA seems to have messed with SHA-3, that might take a while.

> If it makes no practical difference,then switching seem to be a better
> alternative just to silence these kind of questions as their existence
> puts doubt in cryptsetup's security robustness.

It does make a significant practical difference with regard to
the software engineering aspects.

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
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.  --Tony Hoare

Re: [dm-crypt] Few questions from a new user

[Arno Wagner]

On Fri, Jan 10, 2014 at 07:25:57 CET, Iggy wrote:
> Would you mind explaining hash-spec?  Meaning that there is no internal
> mechanism to use different hashes/detect which has was used on a given
> volume?
> 
> Thanks for your time!
> 
> -Iggy

(Follow-up to the list, because others may wonder this too, 
also correction, as I posted nonsense. Sorry about that.)

If you look at the header specification linked here:
  http://code.google.com/p/cryptsetup/wiki/Specification

in Figure 1 you find the cipher and mode for the actual disk 
encryption, and the "hash-spec" which is the hash-function 
used by PBKDF2. 

Sorry, I was confused yesterday, you can change the hash.
(I had just though about PBKDF2 which you cannot easily 
change to, say, scrypt...)

Now the thing is that while you can change SHA-1 to, say, 
SHA-512, the attacks on SHA-1 are preimage collisions, i.e. 
you can find two input values that hash to the same value. 
That means an attacker could possibly create a second 
passphrase for one he already knows in plain which is not 
useful and hence this vulnerability of SHA-1 has no effect. 
(Actually this even is harder, I am simplifying here...)

What these attacks are useful for is, for example, 
creating two certificates with different identities in 
them but the same hash. Then you can have one signed
by some authority, but use the otehr one with the different
identity in it as the auhority signs the hash, not the 
actual identity in the certificate. For MD5, this is
really easy. For SHA-1 it is just about becomming feasible.

But this is completely useless for reversing a hash
and that is what an attacker would need to do in LUKS.
And he would need to reverse an iterated hash, iterated,
e.g., 200'000 times on my test machine. Reversing a hash 
is usually only possible by brute-force, attacks that make 
this much easier require very serious flaws in the hash. 
There are no such attacks for SHA-1 that I am aware of, 
and certainly none for an iterated SHA-1. 

So changing the hash does not do anything, really as the
attacker can only try to brute-force the passphrase and
that takes the same effort for SHA-1 and for SHA-512.

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
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.  --Tony Hoare

Re: [dm-crypt] Few questions from a new user

[.. ink ..]

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

> If you look at the header specification linked here:
>   http://code.google.com/p/cryptsetup/wiki/Specification
>
> in Figure 1 you find the cipher and mode for the actual disk
> encryption, and the "hash-spec" which is the hash-function
> used by PBKDF2.
>
> Sorry, I was confused yesterday, you can change the hash.
> (I had just though about PBKDF2 which you cannot easily
> change to, say, scrypt...)
>
>
Thanks for the clarification,your comment seemed to be in contradiction
with what i was understanding from reading the spec and i even peeked at
cryptsetup source code to make a sense of your comment before giving up
because i was spending too much time on something that will amount to
nothing.



> So changing the hash does not do anything, really as the
> attacker can only try to brute-force the passphrase and
> that takes the same effort for SHA-1 and for SHA-512.
>
>
cryptsetup 1.6.0 changed default cipher mode from cbc to xts not because
cbc had practical issues but because xts was becoming a
standard[1].Sometimes it makes sense to be where everybody else is if being
anywhere is just as good as being anywhere else.If it makes not practical
difference btw SHA1 and SHA2,then moving away from SHA1 seem like a good
idea with the reason being having one less thing to explain in the FAQ.

[1] http://comments.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/6409

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

Re: [dm-crypt] Few questions from a new user

[Arno Wagner]

On Fri, Jan 10, 2014 at 16:33:56 CET, .. ink .. wrote:
> > So changing the hash does not do anything, really as the
> > attacker can only try to brute-force the passphrase and
> > that takes the same effort for SHA-1 and for SHA-512.
> >
> >
> cryptsetup 1.6.0 changed default cipher mode from cbc to xts not because
> cbc had practical issues but because xts was becoming a
> standard[1].Sometimes it makes sense to be where everybody else is if being
> anywhere is just as good as being anywhere else.If it makes not practical
> difference btw SHA1 and SHA2,then moving away from SHA1 seem like a good
> idea with the reason being having one less thing to explain in the FAQ.
> 
> [1] http://comments.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/6409

CBC has issues that XTS avoids and some of them are pretty 
practical, for example the watermark attack. SHA1 has
no such issues as it is used in LUKS.

Sorry, but changing default algorithms to reduce questions 
by people is about the worst possible reason to do it. 

Also, I do not see the questions by people as such a bad 
thing. We can point them in the right direction and maybe
learn a thing or two about what concerns LUKS users have
and maybe some of them actually read parts of the FAQ.

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
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.  --Tony Hoare

Re: [dm-crypt] Few questions from a new user

[Milan Broz]

On 01/10/2014 03:31 PM, Arno Wagner wrote:
> If you look at the header specification linked here:
>   http://code.google.com/p/cryptsetup/wiki/Specification
> 
> in Figure 1 you find the cipher and mode for the actual disk 
> encryption, and the "hash-spec" which is the hash-function 
> used by PBKDF2. 

Just one more addition - specified hash algorithm (in hash-spec
header field) is also used in LUKS anti-forensic filter.

Also there using SHA1 causes no problem, AF solves different problem
there (split key into multiple sectors). See spec above as well.

Milan