On Wed, 26 Feb 2014 22:07, mailinglis...@hauke-laging.de 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). Shalom-Salam, Werner 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: rndlinux Uses the operating system provided `/dev/random' and `/dev/urandom' devices. rndunix 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. rndegd 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. rndw32 Targeted for the Microsoft Windows OS. It uses certain properties of that system and is the only gathering module available for that OS. rndhw 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 implemented. 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 variant. 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 generators. 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. _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users