[lkml]   [2017]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [ANNOUNCE] /dev/random - a new approach (code for 4.11-rc1)
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

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
> 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.

> Jeff


 \ /
  Last update: 2017-03-18 14:32    [W:0.073 / U:0.228 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site