On 20/11/2018 14:57, Christoph Anton Mitterer wrote: > 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? For AF, any hash function is ok (it just diffuses the information to multiple sectors, this is a basic property all hash functions provide). (AF makes no much sense with modern drives anyway, the slot encryption and KDF is where the security is important.) For PBKDF2, I think you can also use any cryptographic hash (if there is a problem, I guess the hash has problem itself even without PBKDF2). Argon2 uses BLAKE2 internally and it cannot be changed. >>> 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 think LUKS key digest were discussed here several times and it is apparent candidate for FAQ. No, it is not a weak point. Digest is just a convenient way how to check that candidate decrypted key form keyslot key is correct. If your RNG is not flawed, the key is random, even if there is one iteration for PBKDF2 you have to run bruteforce scan. It should be impossible, so adding weak fingerprint will not make it worse here :) I do not see any additional value to use Argon2 here. So I preferred the digest to be always compatible with LUKS1 (just there is hardcoded sha256, this will be fixed). So: it is always much simpler for attacker to run bruteforce through decryption of a sector (for example searching for known ext4 signature). (Veracrypt for example use this approach.) >> 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? We are checking availability of encryption in kernel by calling encryption of one sector. But I did not yet implemented this function for AEAD modes. So it fails too late - yes, it is ugly, but we will fix it. Milan p.s. You already found one nice bug (non-existant hash is written to metadata), and it was consequence of two issues. The first one is our apparent fault (missing check, despite TODO in code:-) and one very old bug in AF/LUSK1 (this part of code is shared; it lost the error exit code, it otherwise failed much earlier). Fixed already in devel branch, but it need more review. Thanks for the report! _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt
