Message-ID: <3143116.x4sn03gNaX@tauon.chronox.de>
Date:   Sun, 24 Nov 2019 10:02:43 +0100
From:   Stephan Mueller <smueller@...onox.de>
To:     Sandy Harris <sandyinchina@...il.com>
Cc:     Arnd Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>, linux-api@...r.kernel.org,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        "Alexander E. Patrakov" <patrakov@...il.com>,
        "Ahmed S. Darwish" <darwish.07@...il.com>,
        "Theodore Y. Ts'o" <tytso@....edu>, Willy Tarreau <w@....eu>,
        Matthew Garrett <mjg59@...f.ucam.org>,
        Vito Caputo <vcaputo@...garu.com>,
        Andreas Dilger <adilger.kernel@...ger.ca>,
        Jan Kara <jack@...e.cz>, Ray Strode <rstrode@...hat.com>,
        William Jon McCann <mccann@....edu>,
        zhangjs <zachary@...shancloud.com>,
        Andy Lutomirski <luto@...nel.org>,
        Florian Weimer <fweimer@...hat.com>,
        Lennart Poettering <mzxreary@...inter.de>,
        Nicolai Stange <nstange@...e.de>,
        "Peter, Matthias" <matthias.peter@....bund.de>,
        Marcelo Henrique Cerri <marcelo.cerri@...onical.com>,
        Roman Drahtmueller <draht@...altsekun.de>,
        Neil Horman <nhorman@...hat.com>
Subject: Re: [PATCH v24 01/12] Linux Random Number Generator

Am Sonntag, 24. November 2019, 05:51:19 CET schrieb Sandy Harris:

Hi Sandy,

> Stephan Müller <smueller@...onox.de> wrote:
> > In an effort to provide a flexible implementation for a random number
> > generator that also ...
> 
> As usual, some of your proposals make considerable sense to me &
> others do not, at least on first reading. I may have more comments
> after reflecting some.
> 
> Meanwhile, a couple of things jump out at me:
> >  (a) When an interrupt occurs, the high-resolution time stamp is mixed
> > 
> > into the LFSR. ...
> > 
> >  (b) HID event data like the key stroke or the mouse coordinates are
> > 
> > mixed into the LFSR. ...
> > 
> >  (c) Device drivers may provide data that is mixed into the LFSR. ...
> 
> Why into the LFSR instead of into the entropy pool?

The LFSR is the state transitioning function of the entropy pool. Thus, when 
handing data to the LFSR, it is "mixed" into the entropy pool. Thus, the LRNG 
should perform the action you would expect, i.e. mixing the data into the 
entropy pool.

> 
> > The LRNG allows the TRNG and secondary DRNG mechanism to be changed
> > at runtime.
> 
> Why? This strikes me as pointless complication.

The reason for this is the construction definition of the German AIS 31.

The TRNG is considered to operate as an NTG.1 in the terms of AIS 31. The 
secondary DRNG(s) act as a DRG.3 in terms of AIS 31.

AIS 31 requires that DRGs (including a DRG.3) must be seeded from either an 
NTG.1 (i.e. the TRNG) or a PTG (a physical noise source which we do not have 
in the kernel).

This implies that the TRNG (NTG.1) seeds the secondary DRNG (DRG.3) and thus 
would be compliant to AIS 31.

Since this construction method does not violate other construction methods, 
such as the recommendations in SP800-90C, the LRNG architecture can be claimed 
to be compliant with multiple different construction methods and requirements 
where the output of either the TRNG or the secondary DRNGs always provide 
random data from a compliant RNG.

Note, this construction is only applied if the TRNG is selected and compiled. 
If the TRNG is not present (i.e. not compiled based on the Linux kernel 
compilation configuration), the secondary DRNGs seed directly from the entropy 
pool. Using this flexibility, the LRNG is intended to be able to serve 
different use cases and requirements.
> 
> > * high performance of interrupt handling code: The LRNG impact on the
> > interrupt handling has been reduced to a minimum. On one example
> > system, the LRNG interrupt handling code executes within an average
> > of 65 cycles whereas the existing /dev/random on the same device
> > takes about 97 cycles when measuring the execution time of
> > add_interrupt_randomness().
> 
> Assuming you do this without sacrificing the input mixing, this
> would be worth submitting as a separate patch. Saving cycles
> on every interrupt definitely looks worth doing.
> 
> > * lockless LFSR to collect raw entropy
> 
> This too.

For both comments, the issue is that patches should always provide code that 
compiles. The issue is that this logic cannot be extracted into a separate 
patch without sacrificing the requirement to make it compile.

Though, the code you refer to is extracted into its own C file which allows an 
independent assessment: please see lrng_sw_noise.c whose purpose is to only 
provide the high-performance interrupt handling code. The lockless LFSR is 
provided with the lrng_pool.c with the function lrng_pool_lfsr_u32.

PS: For those two functions and the ChaCha20 DRNG I have another patch in the 
pipeline that will add power-on self tests which are automatically executed 
during boot. Considering that these three functions are essential to the 
maintenance of entropy, adding the self test for those should provide 
additional assurance to users that the code runs properly.

PPS: If you want to study the operations of both, the high-performance 
interrupt collection and the lockless LFSR, there is user space test code that 
provides the implementation as a user space application: please see the test 
code in [1] and use the code in:

- lfsr_demonstration.c: Full operational LFSR to generate arbitrary amounts of 
data from arbitrary seed data.

- lfsr_testvector_generation.c: LFSR code that I used to generate self-test 
vectors for the pending patch

- time_storage.c: Test code for the high-performance interrupt handling code

In addition the essential ChaCha20 DRNG is available as a user space DRNG for 
study at [2].


[1] https://www.chronox.de/lrng.html

[2] https://www.chronox.de/chacha20_drng.html


Thank you very much for your considerations.

Ciao
Stephan

Powered by blists - more mailing lists