Note that no longer using SHA1 is just to prevent situation
when it is no longer available on hardened systems, there is
no known security problem (finding collisions is not a problem for LUKS).
Increasing iteration time is in combination with PBKDF2 benchmark
fixes try to keep PBKDF2 iteration count still high enough and
also acceptable for users.
(Long term is to replace PBKDF2 algorithm with Password Hashing
Competiton winner.).
N.B. distributions can change these defaults in compilation time.
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).
If password is entered through terminal (no keyfile specified) and
cryptsetup is compiled with --enable-passwdqc[=/etc/passwdqc.conf],
default system passwdqc settings are used to check password quality.
The cipher_null is no-encryption, it can be used for testing
or temporarily when encrypting device (cryptsetup-reencrypt).
Accepting only empty password prevents situation when you replace
a LUKS header on an unlocking device with the faked header using
null cipher (and the same UUID).
Here a system could think that the device was properly unlocked
(with any entered password) and will try to use this unencrypted
partition instead.
(IOW it prevents situation when attacker intentionaly forces
an user to boot into dirrerent system just by LUKS header manipulation.)
Properly configured systems should have an additional integrity protection
in place here (LUKS here provides only confidentiality) but it is better
to not not allow this situation in the first place.
(Despite the fact that once you allow physical tampering of your system
it cannot be properly secured anymore.)
If reencrypt removes encryption (or adds encryption to not yet encrypted system)
there is a temporary header using null (none) cipher.
We do not need to pass through password when unlocking these devices.
