Am Samstag, 18. März 2017, 11:11:57 CET schrieb Jeffrey Walton: Hi Jeffrey,
> > The design and implementation is driven by a set of goals described in [2] > > that the LRNG completely implements. Furthermore, [2] includes a > > comparison with RNG design suggestions such as SP800-90B, SP800-90C, and > > AIS20/31. > > A quick comment about SP800 and the hardware instructions... RDSEED is > 2 to 5 times slower than RDRAND on Intel hardware, depending on the > architecture and microarchitecture. I am not sure how this statement relates to the quote above. RDSEED is the CBC-MACed output of the flip-flop providing the raw noise. RDRAND is the output of the SP800-90A CTR DRBG that is seeded by the CBC-MAC that also feeds RDSEED. Thus, RDSEED is as fast as the noise source where RDRAND is a pure deterministic RNG that tries to be (re)seeded as often as possible. Both instructions are totally unrelated to the SP800-90A DRBG available to the Linux kernel. > AMD's implementation of RDRAND is > orders of magnitude slower than Intel's. Testing on an Athlon 845 X4 > (Bulldozer v4) @ 3.5 GHz shows it runs between 4100 and 4500 cycles > per byte. It works out to be about 1 MiB/s. Please consider my speed measurements given in [1] section 3.4.6. The DRBG is just slightly slower than the ChaCha20 on small block sizes and twice as fast on larger block sizes using AES-NI on x86. As the DRBG implementation has no relationship to the RDRAND DRBG, I am not sure about your argument. When I refer to hardware instructions and SP800-90A, I consider the SP800-90A DRBG implementation in crypto/drbg.c provided with the kernel crypto API which uses the raw AES/SHA cipher implementation provided by the kernel crypto API. Here, the implementation uses the fastest one, such as the AES-NI raw AES implementation on x86. Or it uses the ARM NEON SHA implementation for the HMAC/Hash DRBG. > > While the LRNG may reach a cryptographically acceptable seed level > much earlier then the existing /dev/random, it may not be early > enough. The LRNG will initialize as a DRBG during late_initcall. Thus, the DRBG is always present if user space calls. However, during kernel boot, there is of course a need for earlier randomness. This is covered by the init DRNG documented in [1] section 2.10. > Some components, like systemd, will ask for random numbers and > truck-on even if they are not available. Systemd does not block or > wait if get_random_bytes fails to produce. In the bigger picture, > don't expect that software layered above will do the expected thing in > all cases. The LRNG works as a full ABI and API replacement for the current /dev/random implementation. I run it on my servers. It delivers random data for all use cases, during early kernel and user space boot as well as during runtime. [1] http://www.chronox.de/lrng/doc/lrng.pdf > > Jeff Ciao Stephan
