If you run the command cryptsetup luksDump /dev/sda5 (change device to whatever LUKS encrypted device), you will get an output, and at the end there is a section "Digests" which contains something like this:

  0: pbkdf2
    Hash:       sha256
    Iterations: 104492

What does this section represent? Why does it show sha256 here and argon2i in the Keyslots section?

The Keyslots section shows the password hash used as argon2i:

  0: luks2
    Key:        512 bits
    Priority:   normal
    Cipher:     aes-xts-plain64
    Cipher key: 512 bits
    PBKDF:      argon2i

2 Answers 2



So, technically from this set of output, we can observe that :

" cryptsetup() is using LUKS2 and LUKS2 is using Argon2i as a Key Derivation Function. Now, this Argon2i implementation might be using HMAC as PRF and that HMAC is using SHA256 as an underlying hashing function."


A Key Derivation Function (eg. PBKDF2, ARGON2, etc.) is generally a high-level function that needs to work with an underlying PRF (Pseudo-Random Function) and generally, it's HMAC (Hash-based Message Authentication Code).

It's not mandatory to use HMAC but generally, it is used with some Modern KDFs.

Now HMAC needs an underlying Hash Function to work and in this case, it's SHA256.

So it's like when they say "PBKDF2 with SHA256" they are saying "We use PBKDF2 which uses HMAC as Pseudo-Random Function and HMAC uses SHA256 as the underlying hashing function in it"

This theory works with most of the Modern KDFs.
Now when you look at the output again, see it as follows:

  0: pbkdf2
    Hash:       sha256
    Iterations: 104492*

The above output tells us the properties of the PBKDF2 function (or Argon2i in this case). notice 0:pbkdf2.

The next output,

  0: luks2
    Key:        512 bits
    Priority:   normal
    Cipher:     aes-xts-plain64
    Cipher key: 512 bits
    PBKDF:      argon2i

This tells us properties of LUKS2 (Linux Unified Key Setup) notice 0:luks2, which means LUKS2 is using key derivation function - argon2i.

Also, Argon2 is a KDF. Argon2i is optimized to resist side-channel attacks. It accesses the memory array in a password independent order.[wiki]

LUKS1 defaults to PBKDF2 while LUKS2 support Argon2i.

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

*More Resources :*

PBKDF2 : https://en.wikipedia.org/wiki/PBKDF2 | https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-132.pdf | https://www.ietf.org/rfc/rfc2898.txt

HMAC: https://en.wikipedia.org/wiki/HMAC | https://www.ietf.org/rfc/rfc2104.txt

LUKS: https://guardianproject.info/archive/luks/ | https://access.redhat.com/solutions/100463

ARGON2: https://en.wikipedia.org/wiki/Argon2 | https://www.cryptolux.org/images/0/0d/Argon2.pdf

Somewhat HMAC Related Stack* Question : https://crypto.stackexchange.com/questions/35275/whats-the-difference-between-pbkdf-and-sha-and-why-use-them-together

I hope this helps. Please comment below for clarification on any point if needed.

  • 2
    this answer is misleading - argon2 doesn't use hmac or sha256 as its underlying hash function - the pbkdf2 digest and hash is described in the other answer by @clement
    – brynk
    Commented Dec 30, 2022 at 19:56
  • Is it possible to change the number of iterations of a digest?
    – alecov
    Commented Feb 14 at 4:18

The Digest is used to verify that the derived Master Key from any Keyslot can actually be used to decrypt the volume data.
This is done by comparing a "hash" of the Master Key candidate with the saved Digest value (also part of the Digests section). If they match, the entered Passphrase was correct and the Key can be used to decrypt the data.

For security, LUKS doesn't actually just "hash" the candidate with a simple hash function, like only one pass of SHA256, but uses another Key Derivation Function (KDF), in this case PBKDF2. The Hash and Iterations (and also the Salt) fields are merely parameters for the PBKDF2 of the digest check.

One important note here, all this happens after a Passphrase was entered and a Master Key candidate was derived from a Keyslot. The Keyslot KDF is totally separate from the KDF of the later digest check, and in your case already the much more secure Argon2 KDF is used for the key derivation.
(The key derivation, before the digest check, has more to it, the Keyslot KDF is just one part. In fact, it's a pretty clever design, you can find all the details in [1].)

On Argon2

Regarding the underlying hash function of Argon2: Argon2 usually uses BLAKE2 as it's underlying hash function, and so does LUKS.


[1] LUKS2 On-Disk Format Specification (Master Key is also known as 'Volume Key' here)

  • 1
    welcome and merry christmas- this answer needs a bit of work as it misses a lot of the detail of going from keyslot to the unlocked master key, eg. if these details are correct then how can two keyslots unlock the same key, which is a known function of luks/2? see security.stackexchange.com/a/248326/228961 and also gitlab.com/cryptsetup/cryptsetup/-/wikis/LUKS-standard/…; also, presumably the intent of the statement on luks2's use of blake2 is confined to its implementation of argon2? (this could be re-worded sllightly to make this clear)
    – brynk
    Commented Dec 25, 2022 at 21:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .