Messages in this thread | | | From | Stephan Müller <> | Subject | Re: [ANNOUNCE] /dev/random - a new approach (code for 4.11-rc1) | Date | Sat, 18 Mar 2017 14:31:38 +0100 |
| |
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
| |