[dm-crypt] Difference in decryption/hash speed volume unlock

Milan Broz gmazyland at gmail.com
Tue Nov 12 20:17:51 CET 2013

On 11/12/2013 06:11 PM, anderson jackson wrote:
> I have been experimenting/testing with different encryption schemes using
> Cryptsetup. I mostly focused on increasing iterations and using different hash
> algorithms. I noticed a decrease in the time needed for unlocking the volume
> when using Sha512 and serpent. During volume creation I set the iteration
> value to 12000, however the unlock of the volume only took 8 seconds. This
> does not occur with sha1 and AES which takes the full 12 seconds to unlock the
> volume. The iteration count is about 850.000 for Sha512 and about 2.000.000 for
> Sha1. I used an AMD fx-8150 with eight cores. 
> Does anyone one know why there is a discrepancy between the time needed for
> the volume creation and volume decryption?


as usually, it is not as simple as it seems :-)

First, which version of cryptsetup you are using?
(There was a change in performance check, see below.)

So few points:

- always use last version of cryptsetup (1.6.2 as for today)

- also see "cryptsetup benchmark", you can even try set own hash for KDF
(e.g. "cryptsetup benchmark --hash whirlpool").

- type of block cipher should have only very small influence,
decryption of few block is very quick in comparison with seconds
of pbkdf2 iteration. (IOW the hash and number of iterations have major influence).
To be precise, I suggest you run the test with -c null (no encryption),
dmcrypt will uses cipher_null (which is just plain copy).

- formatting will always take longer because there is a benchmark loop
(depends on system, it can take at least 500ms but it can be even 2s,
see pbkdf_check.c code). This check is performed always if you specify
format command, even if you set number of iterations by parameter.

(Previous versions used timers, now we use getrusage(RUSAGE_SELF) because
it works better. Also handling timer signals inside library was problematic.
So there can be some benchmark differences with old version of cryptsetup.)

- Speed also depends on used crypto backend (default is gcrypt,
but e.g. openssl can be even 2x faster in some cases)
(but I do no think you are recompiling cryptsetup between tests :)

- number of CPU cores should not matter, iteration always run on one core

Anyway, 12 vs 8 second seems strange, can you send more info about your
configuration? (Ideally cryptsetup luksFormat with --debug parameter
and also cryptsetup benchmark output).


More information about the dm-crypt mailing list