Header Key Derivation, Salt, and Iteration Count

Header key is used to encrypt and decrypt the encrypted area of the VeraCrypt volume header (for system encryption, of the keydata area), which contains the master key and other data (see the sections Encryption Scheme and VeraCrypt Volume Format Specification). In volumes created by VeraCrypt (and for system encryption), the area is encrypted in XTS mode (see the section Modes of Operation). VeraCrypt supports two key derivation functions for generating header keys: PBKDF2 (specified in PKCS #5 v2.0) and Argon2id.

The PBKDF2 method uses HMAC-based pseudorandom functions with the following hash algorithms available: SHA-512, SHA-256, BLAKE2s-256, Whirlpool, or Streebog (see [8, 9, 20, 22]) – the user selects which. The length of the derived key does not depend on the size of the output of the underlying hash function. For example, a header key for the AES-256 cipher is always 256 bits long even if HMAC-SHA-512 is used (in XTS mode, an additional 256-bit secondary header key is used; hence, two 256-bit keys are used for AES-256 in total). For more information, refer to [7]. A large number of iterations of the key derivation function have to be performed to derive a header key, which increases the time necessary to perform an exhaustive search for passwords (i.e., brute force attack) [7].

Argon2id is a memory-hard key derivation function that provides resistance against both time-memory trade-off attacks and side-channel attacks. Unlike PBKDF2-HMAC, Argon2id does not use a separate hash algorithm selection – it uses its own internal hash function (BLAKE2b). Argon2id requires three parameters: memory cost (amount of memory used), time cost (number of iterations), and parallelism (number of threads). VeraCrypt sets the parallelism parameter to 1 for all cases.

512-bit salt is used for both key derivation functions, which means there are 2⁵¹² keys for each password. This significantly decreases vulnerability to 'off-line' dictionary/'rainbow table' attacks (pre-computing all the keys for a dictionary of passwords is very difficult when a salt is used) [7]. The salt consists of random values generated by the VeraCrypt random number generator during the volume creation process.

Prior to version 1.12, VeraCrypt always used PBKDF2-HMAC with a fixed number of iterations that depended only on the volume type and the hash algorithm used. Starting from version 1.12, the PIM field (Personal Iterations Multiplier) enables users to have more control over the computational parameters used by the key derivation function.

PBKDF2-HMAC Parameters

When a PIM value is not specified or if it is equal to zero, VeraCrypt uses the default values expressed below:

• For system partition encryption (boot encryption) that uses SHA-256, BLAKE2s-256 or Streebog, 200000 iterations are used.
• For system encryption that uses SHA-512 or Whirlpool, 500000 iterations are used.
• For non-system encryption and file containers, all derivation algorithms will use 500000 iterations.

When a PIM value is given by the user, the number of iterations of the PBKDF2 key derivation function is calculated as follows:

• For system encryption that doesn't use SHA-512 or Whirlpool: Iterations = PIM x 2048
• For system encryption that uses SHA-512 or Whirlpool: Iterations = 15000 + (PIM x 1000)
• For non-system encryption and file containers: Iterations = 15000 + (PIM x 1000)

Argon2id Parameters

When Argon2id is selected as the key derivation function, the PIM value controls both memory and time costs as described in the PIM section. If no PIM is specified, default parameters equivalent to PIM = 12 are used (416 MiB memory, 6 iterations).

Header keys used by ciphers in a cascade are mutually independent, even though they are derived from a single password (to which keyfiles may have been applied). For example, for the AES-Twofish-Serpent cascade, the header key derivation function is instructed to derive a 768-bit encryption key from a given password (and, for XTS mode, in addition, a 768-bit secondary header key from the given password). The generated 768-bit header key is then split into three 256-bit keys (for XTS mode, the secondary header key is split into three 256-bit keys too, so the cascade actually uses six 256-bit keys in total), out of which the first key is used by Serpent, the second key is used by Twofish, and the third by AES (in addition, for XTS mode, the first secondary key is used by Serpent, the second secondary key is used by Twofish, and the third secondary key by AES). Hence, even when an adversary has one of the keys, he cannot use it to derive the other keys, as there is no feasible method to determine the password from which the key was derived (except for brute force attack mounted on a weak password).

Next Section >>