key generation: paranoia mode - explicit random input

Werner Koch wk at
Thu Feb 27 18:31:23 CET 2014

On Wed, 26 Feb 2014 22:07, mailinglisten at said:

> I had a look at that but I am not sure what you want me to read. Could 
> you be more precise about that?

Below and also Peter Gutmann's book (see footnote in the text below).



16.6 Random-Number Subsystem Architecture

Libgcrypt provides 3 levels or random quality: The level
`GCRY_VERY_STRONG_RANDOM' usually used for key generation, the level
`GCRY_STRONG_RANDOM' for all other strong random requirements and the
function `gcry_create_nonce' which is used for weaker usages like
nonces.  There is also a level `GCRY_WEAK_RANDOM' which in general maps
to `GCRY_STRONG_RANDOM' except when used with the function
`gcry_mpi_randomize', where it randomizes an multi-precision-integer
using the `gcry_create_nonce' function.

There are two distinct random generators available:

   * The Continuously Seeded Pseudo Random Number Generator (CSPRNG),
     which is based on the classic GnuPG derived big pool
     implementation.  Implemented in `random/random-csprng.c' and used
     by default.

   * A FIPS approved ANSI X9.31 PRNG using AES with a 128 bit key.
     Implemented in `random/random-fips.c' and used if Libgcrypt is in
     FIPS mode.

Both generators make use of so-called entropy gathering modules:

     Uses the operating system provided `/dev/random' and
     `/dev/urandom' devices.

     Runs several operating system commands to collect entropy from
     sources like virtual machine and process statistics.  It is a kind
     of poor-man's `/dev/random' implementation. It is not available in
     FIPS mode.

     Uses the operating system provided Entropy Gathering Daemon (EGD).
     The EGD basically uses the same algorithms as rndunix does.
     However as a system daemon it keeps on running and thus can serve
     several processes requiring entropy input and does not waste
     collected entropy if the application does not need all the
     collected entropy. It is not available in FIPS mode.

     Targeted for the Microsoft Windows OS.  It uses certain properties
     of that system and is the only gathering module available for that

     Extra module to collect additional entropy by utilizing a hardware
     random number generator.  As of now the only supported hardware
     RNG is the Padlock engine of VIA (Centaur) CPUs.  It is not
     available in FIPS mode.

16.6.1 Description of the CSPRNG

This random number generator is loosely modelled after the one
described in Peter Gutmann's paper: "Software Generation of Practically
Strong Random Numbers".(1)

   A pool of 600 bytes is used and mixed using the core RIPE-MD160 hash
transform function.  Several extra features are used to make the robust
against a wide variety of attacks and to protect against failures of
subsystems.  The state of the generator may be saved to a file and
initially seed form a file.

   Depending on how Libgcrypt was build the generator is able to select
the best working entropy gathering module.  It makes use of the slow
and fast collection methods and requires the pool to initially seeded
form the slow gatherer or a seed file.  An entropy estimation is used
to mix in enough data from the gather modules before returning the
actual random output.  Process fork detection and protection is

   The implementation of the nonce generator (for `gcry_create_nonce')
is a straightforward repeated hash design: A 28 byte buffer is
initially seeded with the PID and the time in seconds in the first 20
bytes and with 8 bytes of random taken from the `GCRY_STRONG_RANDOM'
generator.  Random numbers are then created by hashing all the 28 bytes
with SHA-1 and saving that again in the first 20 bytes.  The hash is
also returned as result.

   ---------- Footnotes ----------

   (1) Also described in chapter 6 of his book "Cryptographic Security
Architecture", New York, 2004, ISBN 0-387-95387-6.

16.6.2 Description of the FIPS X9.31 PRNG

The core of this deterministic random number generator is implemented
according to the document "NIST-Recommended Random Number Generator
Based on ANSI X9.31 Appendix A.2.4 Using the 3-Key Triple DES and AES
Algorithms", dated 2005-01-31.  This implementation uses the AES

   The generator is based on contexts to utilize the same core functions
for all random levels as required by the high-level interface.  All
random generators return their data in 128 bit blocks.  If the caller
requests less bits, the extra bits are not used.  The key for each
generator is only set once at the first time a generator context is
used.  The seed value is set along with the key and again after 1000
output blocks.

   On Unix like systems the `GCRY_VERY_STRONG_RANDOM' and
`GCRY_STRONG_RANDOM' generators are keyed and seeded using the rndlinux
module with the `/dev/random' device. Thus these generators may block
until the OS kernel has collected enough entropy.  When used with
Microsoft Windows the rndw32 module is used instead.

   The generator used for `gcry_create_nonce' is keyed and seeded from
the `GCRY_STRONG_RANDOM' generator.  Thus is may also block if the
`GCRY_STRONG_RANDOM' generator has not yet been used before and thus
gets initialized on the first use by `gcry_create_nonce'.  This special
treatment is justified by the weaker requirements for a nonce generator
and to save precious kernel entropy for use by the "real" random

   A self-test facility uses a separate context to check the
functionality of the core X9.31 functions using a known answers test.
During runtime each output block is compared to the previous one to
detect a stuck generator.

   The DT value for the generator is made up of the current time down to
microseconds (if available) and a free running 64 bit counter.  When
used with the test context the DT value is taken from the context and
incremented on each use.

Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

More information about the Gnupg-users mailing list