From 5e1fffa87191c3566bcbe20c6e8d29d5f21651d5 Mon Sep 17 00:00:00 2001 From: Mounir IDRASSI Date: Sat, 13 May 2017 17:34:16 +0200 Subject: Add HTML documentation. --- doc/html/Header Key Derivation.html | 86 +++++++++++++++++++++++++++++++++++++ 1 file changed, 86 insertions(+) create mode 100644 doc/html/Header Key Derivation.html (limited to 'doc/html/Header Key Derivation.html') diff --git a/doc/html/Header Key Derivation.html b/doc/html/Header Key Derivation.html new file mode 100644 index 00000000..1a6a9c72 --- /dev/null +++ b/doc/html/Header Key Derivation.html @@ -0,0 +1,86 @@ + + + + +VeraCrypt - Free Open source disk encryption with strong security for the Paranoid + + + + + + +
+VeraCrypt +
+ + + +
+

+Documentation +>> +Technical Details +>> +Header Key Derivation, Salt, and Iteration Count +

+ +
+

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). The method that VeraCrypt uses to generate the header key and the secondary header key (XTS mode) is PBKDF2, specified in PKCS #5 v2.0; see + +[7].
+
+512-bit salt is used, which means there are 2512 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. The header key derivation function is based on HMAC-SHA-512, HMAC-SHA-256, HMAC-RIPEMD-160, or HMAC-Whirlpool (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-RIPEMD-160 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].
+
+

Prior to version 1.12, VeraCrypt always used a fixed number of iterations depending on the volume type and the derivation algorithm used:

+
    +
  • For system partition encryption (boot encryption), 200000 iterations are used for the HMAC-SHA-256 derivation function and +327661 iterations are used for HMAC-RIPEMD-160.
  • For standard containers and other partitions, 655331 iterations are used for HMAC-RIPEMD-160 and +500000 iterations are used for HMAC-SHA-512, HMAC-SHA-256 and HMAC-Whirlpool. +
+

Starting from version 1.12, the +PIM field (Personal Iterations Multiplier) enables users to have more control over the number of iterations used by the key derivation function.

+

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

+

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

+
    +
  • For system partition encryption (boot encryption): Iterations = PIM x 2048 +
  • For standard containers and other partitions: Iterations = 15000 + (PIM x 1000) +
+
+
+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 >>
+
\ No newline at end of file -- cgit v1.2.3