Hi Herbert, Ted, The venerable Linux /dev/random served users of cryptographic mechanisms well for a long time. Its behavior is well understood to deliver entropic data. In the last years, however, the Linux /dev/random showed signs of age where it has challenges to cope with modern computing environments ranging from tiny embedded systems, over new hardware resources such as SSDs, up to massive parallel systems as well as virtualized environments. With the experience gained during numerous studies of /dev/random, entropy assessments of different noise source designs and assessing entropy behavior in virtual machines and other special environments, I felt to do something about it. I developed a different approach, which I call Linux Random Number Generator (LRNG) to collect entropy within the Linux kernel. The main improvements compared to the legacy /dev/random is to provide sufficient entropy during boot time as well as in virtual environments and when using SSDs. A secondary design goal is to limit the impact of the entropy collection on massive parallel systems and also allow the use accelerated cryptographic primitives. Also, all steps of the entropic data processing are testable. Finally massive performance improvements are visible at /dev/urandom / get_random_bytes. The design and implementation is driven by a set of goals described in [1] that the LRNG completely implements. Furthermore, [1] includes a comparison with RNG design suggestions such as SP800-90B, SP800-90C, and AIS20/31. Please find in [1] the full design discussion covering qualitative assessments of the entropy collection and entropy flow. Furthermore, a full testing of the data collection and data processing is performed. The testing focuses on the calculation of different types of minimum entropy values of raw noise data. All used test code and supportive tools are provided with [2]. The testing is concluded with a comparison to the legacy /dev/random implementation regarding performance and delivery time of entropic random data. To support a proper review of the code without interfering with the current functionality, the attached patch adds the LRNG to the cryptodev-2.6 tree as an option. The patches do not replace or even alter the legacy /dev/random implementation but allows the user to enable the LRNG at compile time. If it is enabled, the legacy /dev/random implementation is not compiled. On the other hand, if the LRNG support is disabled, the legacy /dev/random code is compiled unchanged. With this approach you see that the LRNG is API and ABI compatible with the legacy implementation. Stability tests were executed on 64 and 32 bit systems where the test KVM with 4 vCPUs on 4 hyperthreads compiled the Linux kernel with make -j4 over and over for half a day. In addition, parallel cat /dev/urandom > /dev/null were exercised for a couple of hours. Also, stability tests by generating 500 million interrupts were performed. [1] http://www.chronox.de/lrng/doc/lrng.pdf [2] http://www.chronox.de/lrng.html Stephan Mueller (6): crypto: DRBG - externalize DRBG functions for LRNG random: conditionally compile code depending on LRNG crypto: Linux Random Number Generator crypto: LRNG - enable compile crypto: LRNG - hook LRNG into interrupt handler hyperv IRQ handler: trigger LRNG crypto/Kconfig | 10 + crypto/Makefile | 1 + crypto/drbg.c | 11 +- crypto/lrng.c | 1803 ++++++++++++++++++++++++++++++++++++++++++++++++ drivers/char/random.c | 8 + drivers/hv/vmbus_drv.c | 3 + include/crypto/drbg.h | 7 + include/linux/genhd.h | 5 + include/linux/random.h | 8 + kernel/irq/handle.c | 1 + 10 files changed, 1851 insertions(+), 6 deletions(-) create mode 100644 crypto/lrng.c -- 2.5.5 , Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
