Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Arno Wagner <arno-JoEyUyqlpX17tPAFqOLdPg <at> public.gmane.org>
Subject: Re: Few questions from a new user
Newsgroups: gmane.linux.kernel.device-mapper.dm-crypt
Date: Thursday 9th January 2014 06:51:07 UTC (over 3 years ago)
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:
[email protected]
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
_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt
 
CD: 4ms