8
$\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.

Improve this question
$\endgroup$
5
  • $\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
    Commented Sep 9, 2019 at 15:03
  • $\begingroup$ Thanks. So for a personal use Argon2id should always be advised. $\endgroup$
    – Rand0mMan
    Commented Sep 9, 2019 at 15:53
  • $\begingroup$ If you don't need PBKDF2 then I would say always use Argon2 - until something better comes along. $\endgroup$
    – Swashbuckler
    Commented Sep 10, 2019 at 17:24
  • $\begingroup$ @Swashbuckler Why has Argon2 not received the FIPS certification? $\endgroup$
    – Martin Braun
    Commented Feb 17, 2023 at 20:05
  • 1
    $\begingroup$ @MartinBraun NIST moves slowly. Having said that, just last month NIST asked for feedback on the existing standard including "NIST would appreciate feedback on the industry need for new password-based standards, including memory-hard password-based key derivation functions and password hashing schemes." so I wouldn't be surprised if a new PBKDF gets standardized, but will it be Argon2? Who knows. Even if it is it will take a few years to happen. $\endgroup$
    – Swashbuckler
    Commented Feb 19, 2023 at 16:15

2 Answers 2

Reset to default
5
$\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

Improve this answer
$\endgroup$
1
  • $\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
    Commented Sep 16, 2019 at 16:13
3
$\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.

Improve this answer
$\endgroup$
2
  • 1
    $\begingroup$ It is indeed weird that it uses Argon2i instead of Argon2id. That variant is more vulnerable to TMTO attacks. $\endgroup$
    – forest
    Commented Sep 17, 2019 at 6:15
  • $\begingroup$ The quoted RFC excerpt explicitly states that "Argon2i uses data-independent memory access, which is preferred for password hashing and password-based key derivation"; it also garners the preference of cryptsetup maintainer Milan Broz, as can be read here: "You can use Argon2id though (combination of data dependent and independent processing). I prefer Argon2i for key derivation, but opinions differ here". $\endgroup$
    – neitsab
    Commented Nov 6, 2020 at 19:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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