[dm-crypt] Few questions from a new user
arno at wagner.name
Thu Jan 9 07:51:07 CET 2014
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
> 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
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
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
B can be set up any time you like, C will likely require
that you write code and modify your initrd.
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno at 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
More information about the dm-crypt