This patch is for issue #287
In the code for returning block size ( device_block_size_fd in lib/utils_device.c ),
always returns zero in case of files and device_read_test is not executed.
This patch is to fix device_block_size_fd to return block size correctly incase of files.
Signed-off-by: Athira Rajeevatrajeev@linux.vnet.ibm.com
udev cookies should be set right in before the dm_task_run()
call otherwise we risk a hang while waiting for a cookie
associated with not yet executed dm task.
For example: failing to add table line (dm_task_add_target())
results in such hang.
This can happen if write buffer size is smaller than underlying
block size and initial buffer is misaligned.
Also use size_t for buffer length variables.
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).
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.)
The patch adds the two options
--perf-same_cpu_crypt
--perf-submit_from_crypt_cpus
that set the same named options inside dmcrypt
(available in Linux kernel 3.20 and later).
For historic reasons, in the plain mode the hashing is not used
if keyfile is used (with exception of --key-file=-).
Print warning if the parameters are ignored.
For other cases, uses keyfile offset, keyfile size and hash
as psecified on commandline.
Partially fixes issue#243
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.
If LUKS device was configured to use detached header, suspend operation
required --header option. For now it is enough that active device in-kernel
UUID type is set properly.
FIxes issue#229.
- cryptsetup library is not required to be FIPS certified anymore
due to fact gcrypt PBKDF2 algorithm can be used instead of
cryptsetup internal one.
- check in library constructor is no longer needed and therefore
removed.
- all other checks regarding MK extraction or random generator
restrictions remain the same
