Hey Milan
I was playing a bit around with this on 4.18.10 with cryptsetup 2.0.5 -
all the current unstable versions from Debian (all tried with LUKS2).
Some questions and things arose:
1) Does --hash have an effect on on anything but PBKDF2?
For PBKDF2, a line like
Keyslots:
0: luks2
Key: 512 bits
Priority: normal
Cipher: aes-xts-plain64
PBKDF: pbkdf2
Hash: sha512
**************************
Iterations: 2024276
Salt: 4f fa 24 69 9a 5e 27 f6 3c b6 47 58 21 cb 4f 08
23 02 3c de 01 df e8 93 bf 21 19 8d 88 58 57 79
AF stripes: 4000
Area offset:32768 [bytes]
Area length:258048 [bytes]
Digest ID: 0
will shop up and even hold, e.g.:
Hash: sha3-256
**************************
or give me an error when I specify e.g. just "sha3":
Not compatible PBKDF2 options (using hash algorithm sha3).
But according to the manpage it should also:
>Specifies the hash used in the LUKS key setup scheme and volume
>key digest for luksFormat. The specified hash is used as hash-
>parameter for PBKDF2 and for the AF splitter.
2) Does the VK digest and the one for the AF splitter not show up in
luksDump?
There's:
Tokens:
Digests:
0: pbkdf2
Hash: sha256
Iterations: 76293
Salt: 55 f8 ec f6 9e 92 d0 4a 75 ff 2d 1e 52 31 7b 5d
a0 d1 20 9c 8e a4 be 24 43 a4 4e df 0d dc 55 bb
Digest: 5a 54 5b 8c 3c 50 bc fc fa 4a 22 37 5d 6a 6b f8
ad 04 fa 62 0e 90 45 a0 18 59 3f ce e1 9e 75 1f
But whatever I set, it always gives sha256 there.
3) Why does such a Tokens:/Digests:/0: pbkdf2 show even up when I
selected argon2id? See below:
# cryptsetup --batch-mode --verbose --use-random --cipher aes-xts-plain64 --key-size 512 --hash sha512 --pbkdf argon2id --type luks2 luksFormat /dev/loop0 key
Existing 'crypto_LUKS' superblock signature on device /dev/loop0 will be wiped.
Key slot 0 created.
Command successful.
# cryptsetup luksDump /dev/loop0
LUKS header information
Version: 2
Epoch: 3
Metadata area: 12288 bytes
UUID: 83caef7a-0735-4fe7-990b-cd64522b114a
Label: (no label)
Subsystem: (no subsystem)
Flags: (no flags)
Data segments:
0: crypt
offset: 4194304 [bytes]
length: (whole device)
cipher: aes-xts-plain64
sector: 512 [bytes]
Keyslots:
0: luks2
Key: 512 bits
Priority: normal
Cipher: aes-xts-plain64
PBKDF: argon2id
Time cost: 4
Memory: 1048576
Threads: 4
Salt: b7 09 da 74 b0 69 9a 78 75 14 8a 7a 72 56 ce b0
b2 21 e8 d2 a6 ea a5 c6 8b 32 2a 8a 33 55 5a 56
AF stripes: 4000
Area offset:32768 [bytes]
Area length:258048 [bytes]
Digest ID: 0
Tokens:
Digests:
0: pbkdf2
Hash: sha256
Iterations: 76293
Salt: 55 f8 ec f6 9e 92 d0 4a 75 ff 2d 1e 52 31 7b 5d
a0 d1 20 9c 8e a4 be 24 43 a4 4e df 0d dc 55 bb
Digest: 5a 54 5b 8c 3c 50 bc fc fa 4a 22 37 5d 6a 6b f8
ad 04 fa 62 0e 90 45 a0 18 59 3f ce e1 9e 75 1f
4) Next I wanted to try an AEAD mode:
# cryptsetup --batch-mode --verbose --use-random --cipher aes-xts-plain64 --key-size 512 --hash sha512 --pbkdf argon2id --cipher morus640-random --key-size 128 --integrity aead --type luks2 luksFormat /dev/loop0 key
Key slot 0 created.
device-mapper: reload ioctl on failed: No such file or directory
Command failed with code -1 (wrong or missing parameters).
The reason for the error is probably that Debian doesn't have
MORUS/AEGIS modules compiled... yet it gives me a dumpable LUKS
container:
# cryptsetup luksDump /dev/loop0
LUKS header information
Version: 2
Epoch: 3
Metadata area: 12288 bytes
UUID: 401977c4-5f57-4346-b256-01d0e7839252
Label: (no label)
Subsystem: (no subsystem)
Flags: (no flags)
Data segments:
0: crypt
offset: 4194304 [bytes]
length: (whole device)
cipher: morus640-random
sector: 512 [bytes]
integrity: aead
Keyslots:
0: luks2
Key: 128 bits
Priority: normal
Cipher: aes-xts-plain64
PBKDF: argon2id
Time cost: 4
Memory: 1048576
Threads: 4
Salt: 26 ff e4 24 f4 fa 8a 96 6c 97 78 0f ce 6c 6e 56
f2 71 37 b0 2d 65 73 1f 5b 80 38 ae 81 9d 6e b4
AF stripes: 4000
Area offset:32768 [bytes]
Area length:65536 [bytes]
Digest ID: 0
Tokens:
Digests:
0: pbkdf2
Hash: sha256
Iterations: 161418
Salt: 5f 03 4b 99 60 fa c1 7e 7e 10 64 98 1f 89 b5 97
c0 4e 22 da b8 4a 48 46 9d 19 b4 7f d7 5a 24 0c
Digest: be f8 31 87 ab b4 fe e7 10 85 12 ee 2b a5 63 0c
16 d0 41 f8 1e 9e 4b 03 74 c4 e4 46 be 54 57 97
=> again, some PBKDF2 references, though Argon2id selected...
=> Why is there some aes-xts-plain64 in it?
=> Even if I change the key size to other values it will store it:
e.g. cryptsetup --batch-mode --verbose --use-random --hash sha512 --pbkdf argon2id --cipher morus640-random --key-size 1024 --integrity aead --type luks2 luksFormat /dev/loop0 key
or
cryptsetup --batch-mode --verbose --use-random --hash sha512 --pbkdf argon2id --cipher morus640-random --key-size 768 --integrity aead --type luks2 luksFormat /dev/loop0 key
=> I thought the only valid value for MORUS640 would be 128? And for
MORUS1280 it would be 256? Why does it accept other values and
what would that change?
In case it matters.... kernel gave the following log messages during my
tries above:
Nov 19 20:40:19 heisenberg kernel: device-mapper: table: 253:2: crypt: Error allocating crypto tfm
Nov 19 20:40:19 heisenberg kernel: device-mapper: ioctl: error adding target to table
Nov 19 20:41:43 heisenberg kernel: device-mapper: table: 253:2: crypt: Error allocating crypto tfm
Nov 19 20:41:43 heisenberg kernel: device-mapper: ioctl: error adding target to table
Nov 19 20:42:36 heisenberg kernel: device-mapper: table: 253:2: crypt: Error allocating crypto tfm
Nov 19 20:42:36 heisenberg kernel: device-mapper: ioctl: error adding target to table
Nov 19 20:42:56 heisenberg kernel: device-mapper: table: 253:2: crypt: Error allocating crypto tfm
Nov 19 20:42:56 heisenberg kernel: device-mapper: ioctl: error adding target to table
Nov 19 20:43:24 heisenberg kernel: device-mapper: table: 253:2: crypt: Error allocating crypto tfm
Nov 19 20:43:24 heisenberg kernel: device-mapper: ioctl: error adding target to table
Nov 19 20:43:34 heisenberg kernel: device-mapper: table: 253:2: crypt: Error allocating crypto tfm
Nov 19 20:43:34 heisenberg kernel: device-mapper: ioctl: error adding target to table
Nov 19 20:44:13 heisenberg kernel: device-mapper: table: 253:2: crypt: Error allocating crypto tfm
Nov 19 20:44:13 heisenberg kernel: device-mapper: ioctl: error adding target to table
Nov 19 20:44:43 heisenberg kernel: device-mapper: table: 253:2: crypt: Error allocating crypto tfm
Nov 19 20:44:43 heisenberg kernel: device-mapper: ioctl: error adding target to table
Nov 19 20:45:16 heisenberg kernel: device-mapper: table: 253:2: crypt: Error allocating crypto tfm
Nov 19 20:45:16 heisenberg kernel: device-mapper: ioctl: error adding target to table
Nov 19 20:45:37 heisenberg kernel: device-mapper: table: 253:2: crypt: Error allocating crypto tfm
Nov 19 20:45:37 heisenberg kernel: device-mapper: ioctl: error adding target to table
Nov 19 21:25:02 heisenberg kernel: alg: No test for authenc(hmac(sha256),xts(aes)) (authenc(hmac(sha256-generic),xts-aes-aesni))
Nov 19 21:25:02 heisenberg kernel: device-mapper: crypt: Integrity AEAD, tag size 32, IV size 16.
Nov 19 21:26:13 heisenberg kernel: device-mapper: table: 253:2: crypt: Error decoding and setting key
Nov 19 21:26:13 heisenberg kernel: device-mapper: ioctl: error adding target to table
Nov 19 21:26:28 heisenberg kernel: device-mapper: table: 253:2: crypt: Error decoding and setting key
Nov 19 21:26:28 heisenberg kernel: device-mapper: ioctl: error adding target to table
Nov 19 21:26:43 heisenberg kernel: device-mapper: table: 253:2: crypt: Error decoding and setting key
Nov 19 21:26:43 heisenberg kernel: device-mapper: ioctl: error adding target to table
Nov 19 21:27:04 heisenberg kernel: device-mapper: crypt: Integrity AEAD, tag size 32, IV size 16.
Guess most are because of the missing modules,... but these are strange:
Nov 19 21:25:02 heisenberg kernel: alg: No test for authenc(hmac(sha256),xts(aes)) (authenc(hmac(sha256-generic),xts-aes-aesni))
Nov 19 21:25:02 heisenberg kernel: device-mapper: crypt: Integrity AEAD, tag size 32, IV size 16.
Thanks,
Chris :-)
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
https://www.saout.de/mailman/listinfo/dm-crypt
