OpenSSL now enforces minimal parameters for PBKDF2 according to SP 800-132
key length (112 bits), minimal salt length (128 bits) and minimal number
of iterations (1000).
Our benchmark violates this, causeing cryptsetup misbehave for luksFormat.
Just inrease tet salt to 16 bytes here, it will little bit influence benchmark,
but there is no way back.
The PBKDF2 benchmark heavily depends on exported volume key length,
so we either have to remeber benchmarked length or just run test always.
For other KDFs the dependence on generated key length is negligible,
so we can cache benchmark.
Also cache its value in active context, so we run benchmark
only once.
The patch also changes calculated value for LUKS1 key digest
to 125 miliseconds (it means that for full 8 used slots
the additional slow-down is circa 1 second).
Note that there is no need to have too high iteration count
for key digest; if it is too computationally expensive, attacker
will better decrypt of one sector with candidate key anyway.
(Check for a known signature.)
The reason to have some delay for key digest check was
to complicate brute-force search for volume key with LUKS header
only (and if RNG used to generate volumekey was flawed
allowing such a search i reasonable time).
Code based on patch by Ondrej Mosnacek
The new benchmark works as follows:
Phase 1:
It searches for smallest parameters, such that the duration is 250 ms
(this part is quite fast).
Then it uses that data point to estimate the paramters that will have
the desired duration (and fulfill the basic constraints).
Phase 2:
The candidate parameters are then measured and if their duration falls
within +-5% of the target duration, they are accepted.
Otherwise, new candidate parameters are estimated based on the last
measurement and phase 2 is repeated.
When measuring the duration for given parameters, the measurement
is repeated 3 or 4 times and a minimum of the measured durations
is used as the final duration (to reduce variance in measurements).
A minimum is taken instead of mean, because the measurements definitely
have a certain lower bound, but no upper bound (therefore mean value
would tend to be higher than the value with highest probability density).
The actual "most likely" duration is going to be somewhere just above
the minimum measurable value, so minimum over the observations is
a better estimate than mean.
Signed-off-by: Milan Broz <gmazyland@gmail.com>
Prepare API for PBKDF that can set three costs
- time (similar to iterations in PBKDF2)
- memory (required memory for memory-hard function)
- threads (required number of threads/CPUs).
This patch also removes wrongly designed API call
crypt_benchmark_kdf and replaces it with the new call
crypt_benchmark_pbkdf.
Two functions for PBKDF per context setting
are introduced: crypt_set_pbkdf_type and crypt_get_pbkdf_type.
The patch should be backward compatible when using
crypt_set_iteration_time function (works only for PBKDF2).
Signed-off-by: Milan Broz <gmazyland@gmail.com>
The previous PBKDF2 benchmark code did not take into account
output key length.
For SHA1 (with 160-bits output) and 256-bit keys (and longer)
it means that the final value was higher than it should be.
For other hash algorithms (like SHA256 or SHA512) it caused
that iteration count was smaller (in comparison to SHA1) than
expected for the requested time period.
This patch fixes the code to use key size for the formatted device
(or default LUKS key size if running in informational benchmark mode).
Thanks to A.Visconti, S.Bossi, A.Calo and H.Ragab
(http://www.club.di.unimi.it/) for point this out.
(Based on "What users should know about Full Disk Encryption
based on LUKS" paper to be presented on CANS2015).
Using getrusage seems toi give not adequate precision,
so use clock_gettime and try to scale buffer size a bit
on high performance systems.
If it still fail, return ERANGE error instead calculating
completely unreliable numbers.
Should fix Issue#186.
