On Tue, 2018-11-20 at 11:08 +0100, Ondrej Kozina wrote: > 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. Has someone ever evaluated whether e.g. the other algos like SHA3-* can be safely used in these situations? > > 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... Ah I see :-) > 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. Isn't both, like a weak element in the whole security chain? At the one side we try to use Argon2* to get rid of the deficiencies of PBKDF2... and then it's still used for the VK? > 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. At least at some point cryptsetup seems to actually get the error... it's perhaps just that the LUKS container has already been written by then? Thanks, Chris. _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt
