1) If the calculated costs were the same, it run forever.
2) If the calculation returned final values in the first step,
out costs were not updated and benchmark returned too low values.
When we have measured time smaller than target time, we are decreasing
the parameters. Thus, we should first try to decrease t_cost and only
if that is not possible should we try to decrease m_cost instead. The
original logic was only valid for the case where parameters are being
increased. Most notably this caused unusual parameter combinations for
iteration time < 250 ms.
In this commit we also factor out the now heavily nested parameter
update formula.
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 Argon2i/id is a password hashing function that
won Password Hashing Competiton.
It will be (optionally) used in LUKS2 for passworrd-based
key derivation.
We have to bundle code for now (similar PBKDF2 years ago)
because there is yet no usable implementation in common
crypto libraries.
(Once there is native implementation, cryptsetup
will switch to the crypto library version.)
For now, we use reference (not optimized but portable) implementation.
This patch contains bundled Argon2 algorithm library copied from
https://github.com/P-H-C/phc-winner-argon2
For more info see Password Hashing Competition site:
https://password-hashing.net/
and draft of RFC document
https://datatracker.ietf.org/doc/draft-irtf-cfrg-argon2/
Signed-off-by: Milan Broz <gmazyland@gmail.com>
If backward-compatible API is not defined (-DOPENSSL_API_COMPAT=0x10100000L)
deprecated symbols cannot be used.
Also see https://bugs.gentoo.org/show_bug.cgi?id=604698
Thanks eroen for reporting this.
If measurement function returns exactly 500 ms, the iteration
calculation loop doubles iteration count but instead of repeating
measurement it uses this value directly.
Thanks to Ondrej Mosnacek for bug report.
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).
Apparently there are some people using ECB.
This mode by design do not use any IV, unfortunately
kernel dmcrypt allows to specify them (but userspace crypto api don't).
Let support activation as it was in previous version.
Should fix issue#238.
(Or it rehases key in every iteration.)
- Kernel backens seems not to support >20480 HMAC key
- NSS is slow (without proper key reset)
Add some test vectors (commented out by default).
- config.h must always be the first file to be included
- Use AM_CFLAGS and AM_LDFLAGS consistently and properly.
(Modified to disable build without largefile support etc
by Milan Broz <gmazyland@gmail.com>)
This includes crypto, loopaes, tcrypt handling code I have written myself
and verity code written originally by Mikulas Patocka and modified by me,
copyright by Red Hat.
Other part of library have to stay GPLv2+ only for now
(no agreement from all authors).
