2
$\begingroup$

I plan to do a clean install of ArchLinux with Full Disk Encryption (with LUKS) but I'm not sure to understand the default KDF choice (PBKDF2+SHA-256).

I didn't manage to find any pieces of evidence that make PBKDF2 more recommendable than Argon2id. Can someone explain to me ?

In the cryptsetup FAQ, the maintainer says :

5.11 Some people say PBKDF2 is insecure?

There is some discussion that a hash-function should have a "large memory" property, i.e. that it should require a lot of memory to be computed. This serves to prevent attacks using special programmable circuits, like FPGAs, and attacks using graphics cards. PBKDF2 does not need a lot of memory and is vulnerable to these attacks. However, the publication usually referred in these discussions is not very convincing in proving that the presented hash really is "large memory" (that may change, email the FAQ maintainer when it does) and it is of limited usefulness anyways. Attackers that use clusters of normal PCs will not be affected at all by a "large memory" property. For example the US Secret Service is known to use the off-hour time of all the office PCs of the Treasury for password breaking. The Treasury has about 110'000 employees. Assuming every one has an office PC, that is significant computing power, all of it with plenty of memory for computing "large memory" hashes. Bot-net operators also have all the memory they want. The only protection against a resourceful attacker is a high-entropy passphrase, see items 5.9 and 5.10.

Is this point still valid? Can "memory-hard" KDF like Argon2id really "limit" the 2 examples above?

Even if the FAQ is still right, are there any downsides (security wise) of using Argon2id instead of PBKDF2?

PS : Not a native speaker. Sorry for possible language oddities.

$\endgroup$
  • $\begingroup$ I wouldn't say PBKDF2 is insecure assuming the use of proper inputs (e.g. sufficient number of iterations and salt of sufficient length) however it is less expensive for an attacker to break PBKDF2 than to break Argon2. The only downside of Argon2 that I can think of is that it's not FIPS certified so could impact the sale of a product in some markets, however that's not a security issue. $\endgroup$ – Swashbuckler Sep 9 at 15:03
  • $\begingroup$ Thanks. So for a personal use Argon2id should always be advised. $\endgroup$ – Rand0mMan Sep 9 at 15:53
  • $\begingroup$ If you don't need PBKDF2 then I would say always use Argon2 - until something better comes along. $\endgroup$ – Swashbuckler Sep 10 at 17:24
1
$\begingroup$

The default version of LUKS simply does not support Argon2 because, unlike PBKDF2, it requires more parameters than the current header format is designed to store. The newer version, LUKS2, may not be default on your system, but it does support Argon2. This is just a matter of software support.

See also https://gitlab.com/cryptsetup/cryptsetup/blob/master/docs/on-disk-format-luks2.pdf

$\endgroup$
  • $\begingroup$ Thanks for the pdf. It's very interesting. You're right. Actually the default options are not the same for LUKS1 and LUKS2. I read this in the v2.0.0 changelog. $\endgroup$ – Rand0mMan Sep 16 at 16:13
0
$\begingroup$

I found a pretty clear response in the v2.0.0 release notes of cryptsetup :

For now, default LUKS2 PBKDF algorithm is Argon2i (data independent variant) with memory cost set to 128MB, time to 800ms and parallel thread according to available CPU cores but no more than 4.

So I was wrong. The default PBKDF is

  • PBKDF2 for LUKS1 (LUKS1 header format is limiting)
  • Argon2i for LUKS2 (LUKS2 comes with a new header format)

I still don't know why Argon2id wasn't chosen...

Anyway, I'll contact Milan Broz the cryptsetup FAQ maintainer because the FAQ needs to be updated. There is nothing about LUKS2.

$\endgroup$
  • $\begingroup$ It is indeed weird that it uses Argon2i instead of Argon2id. That variant is more vulnerable to TMTO attacks. $\endgroup$ – forest Sep 17 at 6:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.