lkml.org 
[lkml]   [2020]   [Jul]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH v31 00/12] /dev/random - a new approach with full SP800-90B
Date
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


\
 
 \ /
  Last update: 2020-07-29 09:18    [W:1.456 / U:0.260 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site