On 11/19/18 10:03 PM, Christoph Anton Mitterer wrote:
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).
Interesting, when applied to LUKS2 it has interesting implications, see
below.
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.
Yes that's correct. The --hash parameter applies also to AF even with
argon2 (LUKS2). And you may set different hash per keyslot with LUKS2.
Unfortunately when I was experimenting with it inspired by your
questions, I discovered ugly bug:
When you request non existing hash the luksAddKey operation or
luksFormat operation (for LUKS2) would pass even though it should have
failed. I've created new issue for it:
https://gitlab.com/cryptsetup/cryptsetup/issues/422
So, thank you for report:)
2) Does the VK digest and the one for the AF splitter not show up in
luksDump?
The hash for AF splitter is not shown in ordinary LUKS2 luksDump
command. But you can see it, if you add --debug among luksDump
parameters. If you do, we print complete LUKS2 json metadata. I'm not
sure if it was omitted from normal luksDump on purpose...
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.
It's currently hardcoded to sha256 in LUKS2, for volume key digests.
There's already issue tracking that:
https://gitlab.com/cryptsetup/cryptsetup/issues/396
3) Why does such a Tokens:/Digests:/0: pbkdf2 show even up when I
selected argon2id? See below:
Volume key digest is currently always pbkdf2, even with LUKS2.
# 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.
(...)
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:
I guess the problem is that we're unable to check the cipher involved in
aead setup is configured properly (or exists in kernel) before we
actually try to activate it via dm-crypt mapping. But Milan will know
better.
Thank you for feedback!
O.
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
https://www.saout.de/mailman/listinfo/dm-crypt
