Re: [PATCH v31 00/12] /dev/random - a new approach with full SP800-90B

[Stephan Mueller <smueller@chronox.de>]

Am Dienstag, 28. Juli 2020, 22:40:44 CEST schrieb Pavel Machek:

Hi Pavel,

> Hi!
> 
> > The following patch set provides a different approach to /dev/random which
> > is called Linux Random Number Generator (LRNG) to collect entropy within
> > the Linux kernel. The main improvements compared to the existing
> > /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.
> 
> That sounds good.. maybe too good. Where does LRNG get the entropy? That is
> the part that should be carefully documented..
> 
> 									Pavel

The entire description of the LRNG is given in [1].

[1] section 2.1 outlines the general architecture specifying that there are 
currently 3 noise sources. Per default, the interrupt-based noise source is 
the main source.

Section 2.4 outlines the details of the interrupt noise source handling. The 
key now is unlike the existing implementation that there is no separate block/
HID noise collection because they are "just" derivatives of the interrupt 
noise source which would imply that noise events are double credited with 
entropy. This allows for a massively higher valuation of the entropy rate that 
exists in interrupt events.

To support the design, a large scale noise source analysis is performed in 
chapter 3 [1]. Specifically sections 3.2.3 and 3.2.4 provide quantitative 
statements which are further analyzed in subsequent sections. This includes 
reboot tests as well as runtime tests.

[1] appendix C performs these measurements on other CPU architectures, 
including very small environments which could be expected to have too little 
entropy (specifically the first listed ARM system mentioned there and the MIPS 
system are older embedded devices that yet show sufficient entropy). Also, the 
entropy available in virtual environments is shown in appendix C.

The tools perform the aforementioned measurements are provided with the 
enabling of CONFIG_LRNG_RAW_ENTROPY supported by [2]. This allows everybody to 
re-perform the analysis on the system of his choice.

Also, the entire entropy assessment of the LRNG is supported by the entropy 
analysis of the existing implementation in [3]. Specifically section 6.1 shows 
that the existing implementation has much more entropy available in the 
interrupt events than it credits. Yet, due to the design of the existing 
implementation with the fast pool (for which we have no assessment how much 
entropy is lost by it) and the fact of double counting of entropy with HID/
block devices, the massive underestimation of existing entropy with the 
existing /dev/random implementation is warranted.

Lastly, [4] performs the entropy assessment of the existing /dev/random 
implementation in virtualized environments showing that still sufficient 
entropy is available in interrupt events supporting the approach taken in the 
LRNG. Writing the assessment of [4] was the initial trigger point for me to 
start the LRNG implementation.

The second noise source that, however, is credited much less entropy is 
documented in [5] including its entropy assessment.

[1] https://chronox.de/lrng/doc/lrng.pdf

[2] https://chronox.de/lrng/lrng-tests-20200415.tar.xz

[3] https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Studies/
LinuxRNG/LinuxRNG_EN.pdf?__blob=publicationFile

[4] https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/Studien/
ZufallinVMS/Randomness-in-VMs.pdf?__blob=publicationFile

[5] https://chronox.de/jent/doc/CPU-Jitter-NPTRNG.pdf

Ciao
Stephan