No need to do many iterations of PBKDF2 with large file keys

[GoogleCodeExporter]

I was reading this article about `systemd-blame` 
(http://0pointer.de/blog/projects/blame-game.html) and found that cryptsetup is 
by-far the slowest part of my boot process. Apparently this is because it 
always runs a lot of iterations of PBKDF2, which seems reasonable when dealing 
with passwords. The problem for me is that the key is a large (256 bytes I 
think?), randomly generated file. With a key that large, brute force attacks 
are impossible, so multiple iterations are unnecessary.

I think it would make sense to only do one iteration of PBKDF2 if the key is 
past a certain length (128 bits is probably safe, somewhere around 300 bits, 
brute force attacks become physically impossible within the energy limits of 
our universe).

The main downside I can think of is that this would leak some information about 
the key (that it's probably stored in a file somewhere). In most cases where 
file keys are used, I assume this would be obvious (like when the root 
partition is password protected, and has the keys for the other partitions).

Original issue reported on code.google.com by s...@brendanlong.com on 21 May 2013 at 4:30

[GoogleCodeExporter]

First, it is important amount of entropy in passphrase/keyfile, not only its 
length there.
(even 1000000 bits of keyfile is not safe if you use /dev/zero as generator :-)

Anyway, you can use --iter-time 1  (or -i 1) in luksFormat in this case 
(iteration will be 1000 which is minimum, please note "-i 0" means auto which 
is 1 second).
You can also change it later by changing the key (even to the 
same)(luksChangeKey -i 1).

Also please read
http://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions#5._Security_As
pects
(section 5.10 was added as direct response to my discussion with Lennart on IRC 
about the "slow" boot problem).

You can limit iteration as mentioned above, if you wish, so there will be 
almost no slowdown. 

I will not change any default just because 1 second irritates someone. Just use 
-i parameter and you are done.

Original comment by gmazyl...@gmail.com on 21 May 2013 at 4:59

• Changed state: WontFix

[GoogleCodeExporter]

I know about -i now, but I didn't for a long time, so I wonder if there are a 
lot of other people waiting for an unnecessarily long time when for brute force 
protection on keys that are immune to brute force attacks already.

Since the concern is that a long key file might be low entropy, another way to 
speed this up would be to have cryptsetup generate a key file for you. It could 
grab 512 bits from /dev/random, write it to a file, then add it to a key slot 
with the minimum iterations. This would encourage people to use a high-entropy 
source for file keys, and make them faster. Win/win?

The use-case I have in mind is when someone has their root drive password 
protected, and then it has long, random file keys for other partitions.

Original comment by s...@brendanlong.com on 21 May 2013 at 5:30

[GoogleCodeExporter]

...write to a keyfile a and store it on unsafe place (because you cannot 
remember generated keyfile). It is not so simple. But if anyone decide 
toimplement this in installer, he can do that (taking responsibility for 
properly checking keyfile quality and safe storage).

BTW 1 second is not a long time.
(Usually default distro encrypted config is one encrypted disk with multiple 
LVM volumes above, thus just one encrypted disk, one second.)

Original comment by gmazyl...@gmail.com on 21 May 2013 at 6:04