--iter-time behaves differently for different hashes

[GoogleCodeExporter]

I've tried luksFormat --iter-time=100000, i.e. requesting 100s of PBKDF2 
iterations with different hashes and then I was measuring how long does 
luksFormat and then luksOpen take.

The surprising results on at least 4 computers, using different CPUs and 
different crypto backends are always the same:

sha1, ripemd160:           format 124s, open 110s
sha256, sha512, whirlpool: format  75s, open  61s

I suppose the iter-time is for open, then sha1, ripemd160 are fine and sha256, 
sha512 and whirlpool MK iterations are lower by 40%?

Also it seems, that the iterations per second reported by "cryptsetup 
benchmark" are like almost exactly 5 to 9 times higher than the one I get 
dividing the MK iterations by the luksOpen time. And it is 5 times for sha256, 
sha512, whirlpool and 9 times for sha1, ripemd160.

Also 9/5 is the ratio of 110/61. The same happens also if I request 10s 
iterations instead of 100s.

*My script:

#!/bin/bash
file=`mktemp`
dd if=/dev/zero bs=1M count=10 of=$file &>/dev/null
cryptsetup benchmark | grep PBKDF
for i in sha1 sha256 sha512 ripemd160 whirlpool
do
        echo "*********************************************************************"
        echo "luksFormat"
        time echo a | cryptsetup luksFormat -q --use-urandom --hash=${i} --iter-time=100000 $file
        cryptsetup luksDump $file | grep Hash
        cryptsetup luksDump $file | grep iterations
        echo "luksOpen"
        time echo a | cryptsetup luksOpen $file enc
        cryptsetup luksClose enc
done
rm $file

*Sample result:

PBKDF2-sha1       165704 iterations per second
PBKDF2-sha256     102240 iterations per second
PBKDF2-sha512      63750 iterations per second
PBKDF2-ripemd160  143404 iterations per second
PBKDF2-whirlpool   69423 iterations per second
*********************************************************************
luksFormat

real    2m4.983s
user    2m3.959s
sys     0m1.030s
Hash spec:      sha1
MK iterations:  2037500
luksOpen

real    1m50.759s
user    1m50.360s
sys     0m0.344s
*********************************************************************
luksFormat

real    1m15.711s
user    1m15.241s
sys     0m0.433s
Hash spec:      sha256
MK iterations:  1250000
luksOpen

real    1m1.664s
user    1m1.347s
sys     0m0.238s
*********************************************************************
luksFormat

real    1m14.874s
user    1m14.205s
sys     0m0.659s
Hash spec:      sha512
MK iterations:  775000
luksOpen

real    1m1.651s
user    1m1.203s
sys     0m0.397s
*********************************************************************
luksFormat

real    2m4.695s
user    2m4.025s
sys     0m0.657s
Hash spec:      ripemd160
MK iterations:  1737500
luksOpen

real    1m50.925s
user    1m50.514s
sys     0m0.354s
*********************************************************************
luksFormat

real    1m16.590s
user    1m15.939s
sys     0m0.643s
Hash spec:      whirlpool
MK iterations:  837500
luksOpen

real    1m1.296s
user    1m0.982s
sys     0m0.242s

Original issue reported on code.google.com by J.Fi...@gmail.com on 27 Nov 2013 at 10:54

[GoogleCodeExporter]

The luksFormat runs benchmark internally (depends on speed, it can take >2 
seconds), so you cannot never compare luksFormat with luksOpen.

Also some time is spent not only on slot iteration but also on MK fingerprint 
iteration (it should be roughly 1/8 of slot iteration time but not less than 
1000 iteration).

cryptsetup benchmark is just informative, the baseline is iterating password 
"foo" with salt "bar" - which can differ from real using password. These are 
also using in internal benchmark). You can probably use your own test using 
crypt_benchmark_kdf() libcryptsetup API.

I will perhaps later write some better benchmarking example using libcryptsetup 
to explain it better...

Original comment by gmazyl...@gmail.com on 28 Nov 2013 at 12:42

• Added labels: Type-Other, Priority-Low
• Removed labels: Type-Defect, Priority-Medium

[GoogleCodeExporter]

Original comment by gmazyl...@gmail.com on 28 Nov 2013 at 12:42

[GoogleCodeExporter]

Yes, I thought that --iter-time is related more to luksOpen than to luksFormat. 
It also makes sense, since you usually use luksOpen more often. Maybe it can be 
mentioned in man.

Also I don't mind the discrepancy of 5 or 9 times between "cryptsetup 
benchmark" and my measured times. As you said, maybe the two approaches measure 
different things. In my script the password is "a", but is salted with 
something more complex than just "bar" I guess. I just tried a password of 24 
characters and the results are the same. Must be the salt then.

What is puzzling me is that two hashes (sha1, ripemd160) get almost the right 
luksOpen time of 110s, but three other hashes (sha256, sha512, whirlpool) get 
all of them just 61s. And it is pretty much constant. How come? Must be some 
kind of miscalculation/typo in the benchmarking code you do during luksFormat 
just in sha256, sha512 and whirlpool case?

Have you tried to run my script?

Original comment by J.Fi...@gmail.com on 28 Nov 2013 at 4:09

[GoogleCodeExporter]

Well, it is not miscalculation. The problem is that KDF benchmarking have 
hardcoded too many attributes. It cannot work properly without adding some 
other variables (final key size, different salt size etc).

(All this probably comes from the days when LUKS had only SHA1 and key size was 
usually 256bits).

Anyway, time to rewrite it better (cryptsetup benchmark will be always just 
some guess, but luksOpen times should be quite precise to -i parameter).

But this is more material for next version (1.7), so will postpone fix to next 
minor release...

Thanks for report.

Original comment by gmazyl...@gmail.com on 1 Dec 2013 at 4:56

• Changed state: Accepted