Documentation Technical Details Random Number Generator

# Random Number Generator

The VeraCrypt random number generator (RNG) is used to generate the master encryption key, the secondary key (XTS mode), salt, and keyfiles. It creates a pool of random values in RAM (memory). The pool, which is 320 bytes long, is filled with data from the following sources:

- Mouse movements
- Keystrokes
- Mac OS X and Linux: Values generated by the built-in RNG (both /dev/random and/dev/urandom)
- MS Windows only: MS Windows CryptoAPI (collected regularly at 500-ms interval)
- MS Windows only: Network interface statistics (NETAPI32)
- MS Windows only: Various Win32 handles, time variables, and counters (collected regularly at 500-ms interval)

Before a value obtained from any of the above-mentioned sources is written to the pool, it is divided into individual bytes (e.g., a 32-bit number is divided into four bytes). These bytes are then individually written to the pool with the modulo 28 addition operation (not by replacing the old values in the pool) at the position of the pool cursor. After a byte is written, the pool cursor position is advanced by one byte. When the cursor reaches the end of the pool, its position is set to the beginning of the pool. After every 16th byte written to the pool, the pool mixing function is automatically applied to the entire pool (see below).

## Pool Mixing Function

The purpose of this function is to perform diffusion [2]. Diffusion spreads the influence of individual “raw” input bits over as much of the pool state as possible, which also hides statistical relationships. After every 16th byte written to the pool, this function is applied to the entire pool.

Description of the pool mixing function:

1. Let R be the randomness pool.
2. Let H be the current RNG pool-mixing hash function. In standalone random-pool and keyfile-generation contexts, this is the hash selected by the user. During volume operations, VeraCrypt derives it from the selected header key derivation algorithm: for PBKDF2-HMAC, it is the selected hash (SHA-512, SHA-256, BLAKE2s-256, Whirlpool, or Streebog); for Argon2id, it is BLAKE2b-512.
3. l = byte size of the output of the hash function H (i.e., if H is BLAKE2s-256 or SHA-256, then l = 32; if H is SHA-512, Whirlpool, Streebog, or BLAKE2b-512, l = 64)
4. z = byte size of the randomness pool R (320 bytes)
5. q = z / l – 1 (e.g., if H is Whirlpool, then q = 4)
6. R is divided into l-byte blocks B0...Bq.

   For 0 ≤ i ≤ q (i.e., for each block B) the following steps are performed:

   1. M = H (B0 || B1 || ... || Bq) [i.e., the randomness pool is hashed using the hash function H, which produces a hash M]
   2. Bi = Bi ^ M
7. R = B0 || B1 || ... || Bq

For example, if q = 1, the randomness pool would be mixed as follows:

1. (B0 || B1) = R
2. B0 = B0 ^ H(B0 || B1)
3. B1 = B1 ^ H(B0 || B1)
4. R = B0 || B1

## Generated Values

The content of the RNG pool is never directly exported (even when VeraCrypt instructs the RNG to generate and export a value). Thus, even if the attacker obtains a value generated by the RNG, it is infeasible for him to determine or predict (using the obtained value) any other values generated by the RNG during the session (it is infeasible to determine the content of the pool from a value generated by the RNG).

The RNG ensures this by performing the following steps whenever VeraCrypt instructs it to generate and export a value:

1. Data obtained from the sources listed above is added to the pool as described above.
2. The requested number of bytes is copied from the pool to the output buffer (the copying starts from the position of the pool cursor; when the end of the pool is reached, the copying continues from the beginning of the pool; if the requested number of bytes is greater than the size of the pool, no value is generated and an error is returned).
3. The state of each bit in the pool is inverted (i.e., 0 is changed to 1, and 1 is changed to 0).
4. Data obtained from some of the sources listed above is added to the pool as described above.
5. The content of the pool is transformed using the pool mixing function. Note: The function uses the cryptographically secure one-way hash function associated with the selected KDF/hash option (for more information, see the section Pool Mixing Function above).
6. The transformed content of the pool is XORed into the output buffer as follows:
   1. The output buffer write cursor is set to 0 (the first byte of the buffer).
   2. The byte at the position of the pool cursor is read from the pool and XORed into the byte in the output buffer at the position of the output buffer write cursor.
   3. The pool cursor position is advanced by one byte. If the end of the pool is reached, the cursor position is set to 0 (the first byte of the pool).
   4. The position of the output buffer write cursor is advanced by one byte.
   5. Steps b–d are repeated for each remaining byte of the output buffer (whose length is equal to the requested number of bytes).
   6. The content of the output buffer, which is the final value generated by the RNG, is exported.

## Design Origins

The design and implementation of the random number generator are based on the following works:

- Software Generation of Practically Strong Random Numbers by Peter Gutmann [10]
- Cryptographic Random Numbers by Carl Ellison [11]

Next Section >>