sha256 in "AF hash" despite using sha512 during luksFormat

sha256 in "AF hash" despite using sha512 during luksFormat

[doffloster]

[-- Attachment #1: Type: text/plain, Size: 677 bytes --]

Dear cryptsetup/LUKS Team,

I was using sha512 in the luksFormat command.
Later I used luksAddKey while thinking that it should be using the
sha512 hash that I defined in luksFormat.
But, when I did luksDump, then I noticed that the field "AF hash" for
the second key (which was added via luksAddKey ; its keyslot is #1)
contains the value "sha256".
I expected it to contain sha512.
Notice that keyslot#0 has "sha512" in its corresponding "AF hash" field.

Attached script which reproduces that issue, filename
"reproduce_commands_without_hash.sh".
Attached output of the script, filename
"reproduce_commands_without_hash.log.txt".

Did I miss something?

Best regards,
David.

[-- Attachment #2: reproduce_commands_without_hash.log.txt --]
[-- Type: text/plain, Size: 11146 bytes --]

LUKS Format:
# cryptsetup 2.4.3 processing "cryptsetup --type=luks2 --verbose --debug --hash sha512 --key-size 512 --header /tmp/header.img --key-file - --iter-time=50 luksFormat /dev/sdb1"
# Running command luksFormat.
# Locking memory.
# Installing SIGINT/SIGTERM handler.
# Unblocking interruption on signal.
# Allocating context for crypt device /tmp/header.img.
# Trying to open and read device /tmp/header.img with direct-io.
# Trying to open device /tmp/header.img without direct-io.
# Initialising device-mapper backend library.
WARNING: Device /tmp/header.img already contains a 'crypto_LUKS' superblock signature.
# STDIN descriptor passphrase entry requested.
# Crypto backend (OpenSSL 3.0.2 15 Mar 2022 [default][legacy]) initialized in cryptsetup library version 2.4.3.
# Detected kernel Linux 5.15.0-43-generic x86_64.
# PBKDF argon2id, time_ms 50 (iterations 0), max_memory_kb 1048576, parallel_threads 4.
Existing 'crypto_LUKS' superblock signature on device /tmp/header.img will be wiped.
Existing 'crypto_LUKS' superblock signature on device /tmp/header.img will be wiped.
# Formatting device /tmp/header.img as type LUKS2.
# Auto-detected optimal encryption sector size for device /tmp/header.img is 4096 bytes.
# dm version   [ opencount flush ]   [16384] (*1)
# dm versions   [ opencount flush ]   [16384] (*1)
# Detected dm-ioctl version 4.45.0.
# Device-mapper backend running with UDEV support enabled.
# Trying to open and read device /dev/sdb1 with direct-io.
# Checking if cipher aes-xts-plain64 is usable.
# Using userspace crypto wrapper to access keyslot area.
# Formatting LUKS2 with JSON metadata area 12288 bytes and keyslots area 16744448 bytes.
# Creating new digest 0 (pbkdf2).
# Setting PBKDF2 type key digest 0.
# Running pbkdf2(sha512) benchmark.
# PBKDF benchmark: memory cost = 0, iterations = 1638400, threads = 0 (took 20 ms)
# PBKDF benchmark: memory cost = 0, iterations = 1741820, threads = 0 (took 301 ms)
# PBKDF benchmark: memory cost = 0, iterations = 1744718, threads = 0 (took 601 ms)
# Benchmark returns pbkdf2(sha512) 1744718 iterations, 0 memory, 0 threads (for 512-bits key).
# Segment 0 assigned to digest 0.
# Wiping LUKS areas (0x000000 - 0x001000) with zeroes.
# Wiping keyslots area (0x008000 - 0x1000000) with random data.
# Reusing open rw fd on device /tmp/header.img
# Device size 16777216, offset 16777216.
# Acquiring write lock for device /tmp/header.img.
# Verifying lock handle for /tmp/header.img.
# Device /tmp/header.img WRITE lock taken.
# Trying to write LUKS2 header (16384 bytes) at offset 0.
# Reusing open rw fd on device /tmp/header.img
# Checksum:7080b40cfa78985838b93520b7c434e4abe4f4352f431614b57ac4a13eb87363 (in-memory)
# Trying to write LUKS2 header (16384 bytes) at offset 16384.
# Reusing open rw fd on device /tmp/header.img
# Checksum:3008ee2430be15229759d89ce03daf169a1a0cd40472bfbe0c6395fba356e427 (in-memory)
# Device /tmp/header.img WRITE lock released.
# Adding new keyslot -1 using volume key.
# Adding new keyslot -1 with volume key assigned to a crypt segment.
# Selected keyslot 0.
# Keyslot 0 assigned to digest 0.
# Trying to allocate LUKS2 keyslot 0.
# Found area 32768 -> 290816
# Running argon2id() benchmark.
# PBKDF benchmark: memory cost = 65536, iterations = 4, threads = 4 (took 60 ms)
# PBKDF benchmark: memory cost = 273066, iterations = 4, threads = 4 (took 228 ms)
# PBKDF benchmark: memory cost = 299414, iterations = 4, threads = 4 (took 252 ms)
# Benchmark returns argon2id() 4 iterations, 65536 memory, 4 threads (for 512-bits key).
# Calculating attributes for LUKS2 keyslot 0.
# Acquiring write lock for device /tmp/header.img.
# Verifying lock handle for /tmp/header.img.
# Device /tmp/header.img WRITE lock taken.
# Checking context sequence id matches value stored on disk.
# Reusing open ro fd on device /tmp/header.img
# Running keyslot key derivation.
# Updating keyslot area [0x8000].
# Reusing open rw fd on device /tmp/header.img
# Device size 16777216, offset 16777216.
# Device /tmp/header.img WRITE lock already held.
# Trying to write LUKS2 header (16384 bytes) at offset 0.
# Reusing open rw fd on device /tmp/header.img
# Checksum:7c8b2c722311412a14c3721ec7a01c4b11894701f4aa94500caf854cad8c6cc6 (in-memory)
# Trying to write LUKS2 header (16384 bytes) at offset 16384.
# Reusing open rw fd on device /tmp/header.img
# Checksum:f3826f590069d99638ea2cc1d58c976f29f39b1582fdac1a82c26b3ff3059696 (in-memory)
# Device /tmp/header.img WRITE lock released.
Key slot 0 created.
# Releasing crypt device /tmp/header.img context.
# Releasing device-mapper backend.
# Closing read only fd for /tmp/header.img.
# Closing read write fd for /tmp/header.img.
# Unlocking memory.
Command successful.

Add a key file:
# cryptsetup 2.4.3 processing "cryptsetup --verbose --debug --key-file - --iter-time=50 luksAddKey /tmp/header.img /tmp/key"
# Running command luksAddKey.
# Locking memory.
# Installing SIGINT/SIGTERM handler.
# Unblocking interruption on signal.
# Allocating context for crypt device /tmp/header.img.
# Trying to open and read device /tmp/header.img with direct-io.
# Trying to open device /tmp/header.img without direct-io.
# Initialising device-mapper backend library.
# Trying to load any crypt type from device /tmp/header.img.
# Crypto backend (OpenSSL 3.0.2 15 Mar 2022 [default][legacy]) initialized in cryptsetup library version 2.4.3.
# Detected kernel Linux 5.15.0-43-generic x86_64.
# Loading LUKS2 header (repair disabled).
# Acquiring read lock for device /tmp/header.img.
# Verifying lock handle for /tmp/header.img.
# Device /tmp/header.img READ lock taken.
# Trying to read primary LUKS2 header at offset 0x0.
# Opening locked device /tmp/header.img
# Verifying locked device handle (regular file)
# LUKS2 header version 2 of size 16384 bytes, checksum sha256.
# Checksum:7c8b2c722311412a14c3721ec7a01c4b11894701f4aa94500caf854cad8c6cc6 (on-disk)
# Checksum:7c8b2c722311412a14c3721ec7a01c4b11894701f4aa94500caf854cad8c6cc6 (in-memory)
# Trying to read secondary LUKS2 header at offset 0x4000.
# Reusing open ro fd on device /tmp/header.img
# LUKS2 header version 2 of size 16384 bytes, checksum sha256.
# Checksum:f3826f590069d99638ea2cc1d58c976f29f39b1582fdac1a82c26b3ff3059696 (on-disk)
# Checksum:f3826f590069d99638ea2cc1d58c976f29f39b1582fdac1a82c26b3ff3059696 (in-memory)
# Device size 16777216, offset 16777216.
# Device /tmp/header.img READ lock released.
# PBKDF argon2id, time_ms 2000 (iterations 0), max_memory_kb 1048576, parallel_threads 4.
# PBKDF argon2id, time_ms 50 (iterations 0), max_memory_kb 1048576, parallel_threads 4.
# STDIN descriptor passphrase entry requested.
# Checking volume passphrase [keyslot -1] using passphrase.
# Keyslot 0 priority 1 != 2 (required), skipped.
# Trying to open LUKS2 keyslot 0.
# Running keyslot key derivation.
# Reading keyslot area [0x8000].
# Acquiring read lock for device /tmp/header.img.
# Verifying lock handle for /tmp/header.img.
# Device /tmp/header.img READ lock taken.
# Reusing open ro fd on device /tmp/header.img
# Device /tmp/header.img READ lock released.
# Verifying key from keyslot 0, digest 0.
# dm version   [ opencount flush ]   [16384] (*1)
# dm versions   [ opencount flush ]   [16384] (*1)
# Detected dm-ioctl version 4.45.0.
# Device-mapper backend running with UDEV support enabled.
Key slot 0 unlocked.
# File descriptor passphrase entry requested.
# Adding new keyslot, existing passphrase provided,new passphrase provided.
# Selected keyslot 1.
# Keyslot 0 priority 1 != 2 (required), skipped.
# Trying to open LUKS2 keyslot 0.
# Running keyslot key derivation.
# Reading keyslot area [0x8000].
# Acquiring read lock for device /tmp/header.img.
# Verifying lock handle for /tmp/header.img.
# Device /tmp/header.img READ lock taken.
# Reusing open ro fd on device /tmp/header.img
# Device /tmp/header.img READ lock released.
# Verifying key from keyslot 0, digest 0.
# Keyslot 1 assigned to digest 0.
# Trying to allocate LUKS2 keyslot 1.
# Found area 290816 -> 548864
# Running argon2id() benchmark.
# PBKDF benchmark: memory cost = 65536, iterations = 4, threads = 4 (took 52 ms)
# PBKDF benchmark: memory cost = 315076, iterations = 4, threads = 4 (took 261 ms)
# Benchmark returns argon2id() 4 iterations, 65536 memory, 4 threads (for 512-bits key).
# Calculating attributes for LUKS2 keyslot 1.
# Acquiring write lock for device /tmp/header.img.
# Verifying lock handle for /tmp/header.img.
# Device /tmp/header.img WRITE lock taken.
# Checking context sequence id matches value stored on disk.
# Reusing open ro fd on device /tmp/header.img
# Running keyslot key derivation.
# Updating keyslot area [0x47000].
# Opening locked device /tmp/header.img
# Verifying locked device handle (regular file)
# Device size 16777216, offset 16777216.
# Device /tmp/header.img WRITE lock already held.
# Trying to write LUKS2 header (16384 bytes) at offset 0.
# Reusing open rw fd on device /tmp/header.img
# Checksum:3600aeb87da586f74cf113089e0e37faefe420338e89f24c65a18ba8ea329d37 (in-memory)
# Trying to write LUKS2 header (16384 bytes) at offset 16384.
# Reusing open rw fd on device /tmp/header.img
# Checksum:91a974803aa8ab158440983c51b9fdebb88b21240b168d1c4bb246a2443e00e1 (in-memory)
# Device /tmp/header.img WRITE lock released.
Key slot 1 created.
# Releasing crypt device /tmp/header.img context.
# Releasing device-mapper backend.
# Closing read only fd for /tmp/header.img.
# Closing read write fd for /tmp/header.img.
# Unlocking memory.
Command successful.

LUKS header information
Version:       	2
Epoch:         	4
Metadata area: 	16384 [bytes]
Keyslots area: 	16744448 [bytes]
UUID:          	49f5c9d2-00d3-4d5b-8a9a-0197077be6c9
Label:         	(no label)
Subsystem:     	(no subsystem)
Flags:       	(no flags)

Data segments:
  0: crypt
	offset: 0 [bytes]
	length: (whole device)
	cipher: aes-xts-plain64
	sector: 4096 [bytes]

Keyslots:
  0: luks2
	Key:        512 bits
	Priority:   normal
	Cipher:     aes-xts-plain64
	Cipher key: 512 bits
	PBKDF:      argon2id
	Time cost:  4
	Memory:     65536
	Threads:    4
	Salt:       a0 2f 35 ff 70 ab 22 d8 5f c8 93 29 63 8b 54 e9 
	            8a 18 f2 fe c6 dd 27 bf ba 61 07 2d 4a c0 9b f5 
	AF stripes: 4000
	AF hash:    sha512
	Area offset:32768 [bytes]
	Area length:258048 [bytes]
	Digest ID:  0
  1: luks2
	Key:        512 bits
	Priority:   normal
	Cipher:     aes-xts-plain64
	Cipher key: 512 bits
	PBKDF:      argon2id
	Time cost:  4
	Memory:     65536
	Threads:    4
	Salt:       a2 a0 a7 94 cb cc 61 84 cc 79 75 52 39 5a c1 4c 
	            1d 39 ee 2e f2 89 0c 53 81 e0 54 5e c9 1f 5a 5a 
	AF stripes: 4000
	AF hash:    sha256
	Area offset:290816 [bytes]
	Area length:258048 [bytes]
	Digest ID:  0
Tokens:
Digests:
  0: pbkdf2
	Hash:       sha512
	Iterations: 218089
	Salt:       1b 9a 78 f6 a5 fe 3d f7 70 8c be c8 a2 3a 4d 12 
	            1a aa 61 ff ad 56 d7 93 0b 93 15 10 b8 7a 6a af 
	Digest:     b8 15 55 0f 66 b2 4d bc 67 e3 a0 75 4a 4c b6 6f 
	            62 c3 22 c2 3c 11 9d a4 e7 4b 3f 63 bc d8 80 8e 
	            4f 16 58 61 cf 0e 8c a3 51 27 1c b1 ea 5a 02 fe 
	            1f 33 35 70 49 57 22 4e e5 63 9c 88 69 b4 1d 38 

[-- Attachment #3: reproduce_commands_without_hash.sh --]
[-- Type: application/x-shellscript, Size: 1972 bytes --]

Re: sha256 in "AF hash" despite using sha512 during luksFormat

[Milan Broz]

On 10/09/2022 00:50, doffloster@gmail.com wrote:
> Dear cryptsetup/LUKS Team,
> 
> I was using sha512 in the luksFormat command.
> Later I used luksAddKey while thinking that it should be using the
> sha512 hash that I defined in luksFormat.
> But, when I did luksDump, then I noticed that the field "AF hash" for
> the second key (which was added via luksAddKey ; its keyslot is #1)
> contains the value "sha256".

The digest hash remains the same. it is changed only if the digest
is recalculated later (reencryption).

(In LUKS1 there was only one hash algorithm used for everything,
in LUKS2 you can have different algorihms per keyslots, digest and AF but
for digest and AF there is no API co change it later.)

BTW SHA512, specially for AF, is overkill, it will not help anything.
Why do you want to use it there? The whole idea for AF is just to
diffuse the key on a larger area - any hash algorithm here works ok.

For digest it has no security improvement either, as the input is
randomly generated key and if you want to run bruteforce on it, it is much
faster to try to decrypt some sector where you can detect correct plaintext
than to use slow digest PBKDF2 here.

m.

Re: sha256 in "AF hash" despite using sha512 during luksFormat

[doffloster]

Hi Milan,

I appreciate your reply.

Note that I don't have a very good knowledge in crypto.

I prefer sha512 over sha256 only because I've read that it is slightly
more difficult for GPUs to brute force, because they normally have
32bit operations.
Links to two sources (same author, "Thomas Pornin"):
https://security.stackexchange.com/questions/86082/hashing-algorithm-for-cryptsetup
https://security.stackexchange.com/questions/40208/recommended-options-for-luks-cryptsetup

I don't mind the relatively minor performance impact for read/write operations.

> it is much
> faster to try to decrypt some sector where you can detect correct plaintext
> than to use slow digest PBKDF2 here.

Do you mean that in the given scenario it is much faster to find the
LUKS master key by decrypting a plaintext sector which is encrypted
with AES rather than trying to find the LUKS master key via PBKDF2?
Which means that in the given scenario AES is "weaker" than PBKDF2?
Also, I assume it is difficult to find an encrypted sector which has a
high chance to be plaintext when it is decrypted.
I assume that plaintext sectors probably are the least common type of
sector (there are images, videos, executables etc. which easily take
space on the storage )

Best regards,
David.






On Sat, Sep 10, 2022 at 8:25 AM Milan Broz <gmazyland@gmail.com> wrote:
>
> On 10/09/2022 00:50, doffloster@gmail.com wrote:
> > Dear cryptsetup/LUKS Team,
> >
> > I was using sha512 in the luksFormat command.
> > Later I used luksAddKey while thinking that it should be using the
> > sha512 hash that I defined in luksFormat.
> > But, when I did luksDump, then I noticed that the field "AF hash" for
> > the second key (which was added via luksAddKey ; its keyslot is #1)
> > contains the value "sha256".
>
> The digest hash remains the same. it is changed only if the digest
> is recalculated later (reencryption).
>
> (In LUKS1 there was only one hash algorithm used for everything,
> in LUKS2 you can have different algorihms per keyslots, digest and AF but
> for digest and AF there is no API co change it later.)
>
> BTW SHA512, specially for AF, is overkill, it will not help anything.
> Why do you want to use it there? The whole idea for AF is just to
> diffuse the key on a larger area - any hash algorithm here works ok.
>
> For digest it has no security improvement either, as the input is
> randomly generated key and if you want to run bruteforce on it, it is much
> faster to try to decrypt some sector where you can detect correct plaintext
> than to use slow digest PBKDF2 here.
>
> m.



-- 

Best regards,
David.

Re: sha256 in "AF hash" despite using sha512 during luksFormat

[Michael Kjörling]

On 10 Sep 2022 10:26 +0300, from doffloster@gmail.com:
> I prefer sha512 over sha256 only because I've read that it is slightly
> more difficult for GPUs to brute force, because they normally have
> 32bit operations.

Someone correct me if I'm wrong, but my understanding is that GPUs per
se excel at vector operations, because that's a big part of what's
needed for 3D graphics. (They also happen to be very useful for some
other types of workloads.) The SHA* series of hashes, including SHA3,
rely primarily on simple integer arithmetic; addition and subtraction
modulo some value, XOR, and similar operations. That can of course be
offloaded to GPUs, and it might be easier to parallelize GPU workloads
in a single system, but it's not a GPU's primary strong suit.


>> it is much
>> faster to try to decrypt some sector where you can detect correct plaintext
>> than to use slow digest PBKDF2 here.
> 
> Do you mean that in the given scenario it is much faster to find the
> LUKS master key by decrypting a plaintext sector which is encrypted
> with AES rather than trying to find the LUKS master key via PBKDF2?
> Which means that in the given scenario AES is "weaker" than PBKDF2?

If you have a candidate key, a hash of the correct key, and some
amount of ciphertext encrypted with the correct key, then to check if
the candidate key is likely correct you can choose between hashing the
key and comparing H(K)=h, or decrypting the ciphertext with it and see
if D_K(C) is a probable plaintext. Which you choose depends on which
is faster on the system you're running on. Since AES is already
hardware-accelerated on many modern CPUs, it may well be faster. Once
H(K) is an expensive operation, such as with iterated hashes or hashes
designed to be expensive (such as Argon2), it's highly likely to be
faster. Keep in mind that in both cases, the search space is the same.
The search space also isn't really affected by the output hash size of
the hash algorithm, especially if that is larger than the unknown
portion of the input; in the latter case, the hash serves largely as a
diffuser.

> Also, I assume it is difficult to find an encrypted sector which has a
> high chance to be plaintext when it is decrypted.
> I assume that plaintext sectors probably are the least common type of
> sector (there are images, videos, executables etc. which easily take
> space on the storage )

Most useful data has some bias. Encrypted data, including when
decrypted with the wrong key, is essentially random; this is a
property of almost any good encryption algorithm (without knowledge of
the key, encrypted data is indistinguishable from random data).
Therefore, if the decrypted data has more than some threshold of one
bit value compared to the other (for example, more than 60% of bits
are of either value), then it's plausibly plaintext and you can apply
more expensive checks. Counting the number of bits of each value is a
rather simple operation that is commonly implemented in hardware; GCC,
for example, offers __builtin_popcount() for the purpose.

Also, if the device hasn't been filled with random data for padding,
storage allocation patterns can give a lot away even if you can't tell
what exactly is there. A volume holding an ext3 file system looks
_very_ different in terms of allocation patterns compared to, say, a
Btrfs volume or a NTFS volume. Once you have a reasonable guess as to
what file system a container holds, there are usually signatures in
known locations that you can use to hugely narrow down the set of
possible plaintexts and therefore confirm whether a candidate key is
plausibly correct. Or you can take a shot and look for signatures for
any of the few dozen most common file systems. "Known plaintext"
sounds like it would be a meaningless attack against encrypted data
(why try to decrypt the ciphertext if you already have the
plaintext?), but surprisingly often, it's a _very_ practical starting
point precisely because you can make very good educated guesses about
what the plaintext might look like.

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
 “Remember when, on the Internet, nobody cared that you were a dog?”

Re: sha256 in "AF hash" despite using sha512 during luksFormat

[Milan Broz]

On 10/09/2022 09:26, doffloster@gmail.com wrote:
> Hi Milan,
> 
> I appreciate your reply.
> 
> Note that I don't have a very good knowledge in crypto.

Then it is always better use defaults :-)

> 
> I prefer sha512 over sha256 only because I've read that it is slightly
> more difficult for GPUs to brute force, because they normally have
> 32bit operations.
> Links to two sources (same author, "Thomas Pornin"):
> https://security.stackexchange.com/questions/86082/hashing-algorithm-for-cryptsetup
> https://security.stackexchange.com/questions/40208/recommended-options-for-luks-cryptsetup

Both are obsoleted for LUKS2 as we switched to Argon2 from PBKDF2 for keyslot
password key derivation. This is what is important here.
(Argon2 is memory hard algorithm and uses internally Blake64b hash.)

For the remaining use of hash (digest, AF, checskum etc) there is no reason
to use anything else than sha256. Of course, you you can, but it will not improve
security of your device.
  
> I don't mind the relatively minor performance impact for read/write operations.

These are not used for data, only for key derivation and has no impact for any
IO operation.  (Please read cryptsetup FAQ document, I think many things are explained there.)

m.

Re: sha256 in "AF hash" despite using sha512 during luksFormat

[Milan Broz]

And just reading your log...

# cryptsetup 2.4.3 processing "cryptsetup --type=luks2 --verbose --debug --hash sha512 --key-size 512 --header /tmp/header.img --key-file - --iter-time=50 luksFormat /dev/sdb1"

If you want to improve security DO NOT decrease keyslot iteration time!

You set 50ms (--iter-time=50) that will cause all KDF parameters to use absolute *minimum*.
(Default is 2000 = 2 seconds!)

The whole discussion about changing hash is pointless then...

m.

On 10/09/2022 00:50, doffloster@gmail.com wrote:
> Dear cryptsetup/LUKS Team,
> 
> I was using sha512 in the luksFormat command.
> Later I used luksAddKey while thinking that it should be using the
> sha512 hash that I defined in luksFormat.
> But, when I did luksDump, then I noticed that the field "AF hash" for
> the second key (which was added via luksAddKey ; its keyslot is #1)
> contains the value "sha256".
> I expected it to contain sha512.
> Notice that keyslot#0 has "sha512" in its corresponding "AF hash" field.
> 
> Attached script which reproduces that issue, filename
> "reproduce_commands_without_hash.sh".
> Attached output of the script, filename
> "reproduce_commands_without_hash.log.txt".
> 
> Did I miss something?
> 
> Best regards,
> David.

Re: sha256 in "AF hash" despite using sha512 during luksFormat

[doffloster]

> Then it is always better use defaults :-)

Haha, indeed I somewhat agree, though I do want to learn a little bit
and be more aware of my configurations.


> Both are obsoleted for LUKS2 as we switched to Argon2 from PBKDF2 for keyslot
> password key derivation. This is what is important here.
> (Argon2 is memory hard algorithm and uses internally Blake64b hash.)

Do you mean that the choice of 'sha512' for the flag '--hash' is
reducing the security strength?
From what I could understand, it shouldn't reduce the security strength.

I executed "cryptsetup --help" and found that the following default
values are defined:

"
Default compiled-in key and passphrase parameters:
    Maximum keyfile size: 8192kB, Maximum interactive passphrase
length 512 (characters)
Default PBKDF for LUKS1: pbkdf2, iteration time: 2000 (ms)
Default PBKDF for LUKS2: argon2id
    Iteration time: 2000, Memory required: 1048576kB, Parallel threads: 4

Default compiled-in device cipher parameters:
    loop-AES: aes, Key 256 bits
    plain: aes-cbc-essiv:sha256, Key: 256 bits, Password hashing: ripemd160
    LUKS: aes-xts-plain64, Key: 256 bits, LUKS header hashing: sha256,
RNG: /dev/urandom
    LUKS: Default keysize with XTS mode (two internal keys) will be doubled.
"


As far as I understand, for LUKS2 the default PBKDF algorithm is
'argon2id' and default hash is 'sha256'.
So, I only changed the default hash to 'sha512' by using the flag
'--hash', though I didn't change the PBKDF algorithm, so it should
stay the default value, i.e. 'argon2id'.
And indeed we can see these values in the log file
("reproduce_commands_without_hash.log.txt") which is attached to the
previous email that I sent - boths keyslots (keyslot #0 and keyslot
#1) have the following property:
"PBKDF:      argon2id"

Thus, the 'PBKDF' algorithm is still the best for LUKS2 in the
cryptsetup flags configuration that I chose, I think.

Also, I didn't find any mention of the 'Blake64b' hash.

> These are not used for data, only for key derivation and has no impact for any
> IO operation.  (Please read cryptsetup FAQ document, I think many things are  explained there.)

I understand.
I've read the cryptsetup FAQ but will try giving it another read,
perhaps things could be clearer.


On Sat, Sep 10, 2022 at 1:28 PM Milan Broz <gmazyland@gmail.com> wrote:
>
> On 10/09/2022 09:26, doffloster@gmail.com wrote:
> > Hi Milan,
> >
> > I appreciate your reply.
> >
> > Note that I don't have a very good knowledge in crypto.
>
> Then it is always better use defaults :-)
>
> >
> > I prefer sha512 over sha256 only because I've read that it is slightly
> > more difficult for GPUs to brute force, because they normally have
> > 32bit operations.
> > Links to two sources (same author, "Thomas Pornin"):
> > https://security.stackexchange.com/questions/86082/hashing-algorithm-for-cryptsetup
> > https://security.stackexchange.com/questions/40208/recommended-options-for-luks-cryptsetup
>
> Both are obsoleted for LUKS2 as we switched to Argon2 from PBKDF2 for keyslot
> password key derivation. This is what is important here.
> (Argon2 is memory hard algorithm and uses internally Blake64b hash.)
>
> For the remaining use of hash (digest, AF, checskum etc) there is no reason
> to use anything else than sha256. Of course, you you can, but it will not improve
> security of your device.
>
> > I don't mind the relatively minor performance impact for read/write operations.
>
> These are not used for data, only for key derivation and has no impact for any
> IO operation.  (Please read cryptsetup FAQ document, I think many things are explained there.)
>
> m.



-- 

Best regards,
David.

Re: sha256 in "AF hash" despite using sha512 during luksFormat

[doffloster]

Thank you for inspecting my log.
I used the low iteration time just for the reproduction example - in
the script there is the following line:

> ITER_TIME=50 # Just to make it fast

So, I am aware of the iteration time issue.
In reality I use an iteration time which is higher than the default
(default iteration time is 2000ms).

On Sat, Sep 10, 2022 at 1:34 PM Milan Broz <gmazyland@gmail.com> wrote:
>
> And just reading your log...
>
> # cryptsetup 2.4.3 processing "cryptsetup --type=luks2 --verbose --debug --hash sha512 --key-size 512 --header /tmp/header.img --key-file - --iter-time=50 luksFormat /dev/sdb1"
>
> If you want to improve security DO NOT decrease keyslot iteration time!
>
> You set 50ms (--iter-time=50) that will cause all KDF parameters to use absolute *minimum*.
> (Default is 2000 = 2 seconds!)
>
> The whole discussion about changing hash is pointless then...
>
> m.
>
> On 10/09/2022 00:50, doffloster@gmail.com wrote:
> > Dear cryptsetup/LUKS Team,
> >
> > I was using sha512 in the luksFormat command.
> > Later I used luksAddKey while thinking that it should be using the
> > sha512 hash that I defined in luksFormat.
> > But, when I did luksDump, then I noticed that the field "AF hash" for
> > the second key (which was added via luksAddKey ; its keyslot is #1)
> > contains the value "sha256".
> > I expected it to contain sha512.
> > Notice that keyslot#0 has "sha512" in its corresponding "AF hash" field.
> >
> > Attached script which reproduces that issue, filename
> > "reproduce_commands_without_hash.sh".
> > Attached output of the script, filename
> > "reproduce_commands_without_hash.log.txt".
> >
> > Did I miss something?
> >
> > Best regards,
> > David.



-- 

Best regards,
David.

Re: sha256 in "AF hash" despite using sha512 during luksFormat

[Milan Broz]

On 10/09/2022 14:53, doffloster@gmail.com wrote:
> 
> Do you mean that the choice of 'sha512' for the flag '--hash' is
> reducing the security strength?
>  From what I could understand, it shouldn't reduce the security strength.

No, I said it will not increase security (while it can increase processing
time and keyslot storage space).

> I executed "cryptsetup --help" and found that the following default
> values are defined:
> 
> "
> Default compiled-in key and passphrase parameters:
...

> As far as I understand, for LUKS2 the default PBKDF algorithm is
> 'argon2id' and default hash is 'sha256'.
> So, I only changed the default hash to 'sha512' by using the flag
> '--hash', though I didn't change the PBKDF algorithm, so it should
> stay the default value, i.e. 'argon2id'.

Yes, it is visible in the luksDump output.
SHA hash was used only for AF for that keyslot.

> Also, I didn't find any mention of the 'Blake64b' hash.

Sorry, my mistake, I meant Blake2b; it uses 64bit words.

See Argon2 RFC:
https://www.rfc-editor.org/rfc/rfc9106.html


Milan

Re: sha256 in "AF hash" despite using sha512 during luksFormat

[doffloster]

I understand.
Thank you for all the help!

On Thu, Sep 15, 2022 at 5:17 PM Milan Broz <gmazyland@gmail.com> wrote:
>
> On 10/09/2022 14:53, doffloster@gmail.com wrote:
> >
> > Do you mean that the choice of 'sha512' for the flag '--hash' is
> > reducing the security strength?
> >  From what I could understand, it shouldn't reduce the security strength.
>
> No, I said it will not increase security (while it can increase processing
> time and keyslot storage space).
>
> > I executed "cryptsetup --help" and found that the following default
> > values are defined:
> >
> > "
> > Default compiled-in key and passphrase parameters:
> ...
>
> > As far as I understand, for LUKS2 the default PBKDF algorithm is
> > 'argon2id' and default hash is 'sha256'.
> > So, I only changed the default hash to 'sha512' by using the flag
> > '--hash', though I didn't change the PBKDF algorithm, so it should
> > stay the default value, i.e. 'argon2id'.
>
> Yes, it is visible in the luksDump output.
> SHA hash was used only for AF for that keyslot.
>
> > Also, I didn't find any mention of the 'Blake64b' hash.
>
> Sorry, my mistake, I meant Blake2b; it uses 64bit words.
>
> See Argon2 RFC:
> https://www.rfc-editor.org/rfc/rfc9106.html
>
>
> Milan



-- 

Best regards,
David.