--iter-time behaves differently for different hashes

Issue 185 by J.Fi... on 2013-11-27 10:54:29:

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

Comment by gmazyl... on 2013-11-28 12:42:22:

Labels: Type-Defect, Priority-Medium, Type-Other, Priority-Low

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...

Comment by gmazyl... on 2013-11-28 12:42:46:

Owner: gmazyland

(No comment has been entered for this change)

Comment by J.Fi... on 2013-11-28 16:09:33:

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?

Comment by gmazyl... on 2013-12-01 16:56:46:

Status: Accepted

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.

mentioned in issue #192 (closed)

Reassigned to @mbroz

I hope all of these problems are either fixed or can be setup through new options in cryptsetup 2.0.x already.

closed