Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Stephan =?ISO-8859-1?Q?M=FCller?= <smueller@chronox.de>
To:     Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
        Ted Ts'o <tytso@mit.edu>, John Denker <jsd@av8n.com>,
        Sandy Harris <sandyinchina@gmail.com>
Subject: Re: Lockless /dev/random - Performance/Security/Stability improvement
Date:   Fri, 11 Jun 2021 07:59:28 +0200
Message-ID: <1744453.HlSabMDqgd@positron.chronox.de>
In-Reply-To: <CACXcFmnRAkrj0Q3uFjyLu7RaWQh0VPbmErkj+cUaxZMb=YiGCw@mail.gmail.com>
References: <CALFqKjSnOWyFjp7NQZKMXQ+TfzXMCBS=y8xnv5GE56SHVr5tCg@mail.gmail.com> <CACXcFmnRAkrj0Q3uFjyLu7RaWQh0VPbmErkj+cUaxZMb=YiGCw@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Precedence: bulk

Am Freitag, 11. Juni 2021, 05:59:52 CEST schrieb Sandy Harris:

Hi Sandy,

> The basic ideas here look good to me; I will look at details later.
> Meanwhile I wonder what others might think, so I've added some to cc
> list.
> 
> One thing disturbs me, wanting to give more control to
> "the user who should be free to choose their own security/performance
> tradeoff"
> 
> I doubt most users, or even sys admins, know enough to make such
> choices. Yes, some options like the /dev/random vs /dev/urandom choice
> can be given, but I'm not convinced even that is necessary. Our
> objective should be to make the thing foolproof, incapable of being
> messed up by user actions.

Thank you for your considerations.

I would think you are referring to the boottime/runtime configuration of the 
entropy sources.

I think you are right that normal admins should not have the capability to 
influence the entropy source configuration. Normal users would not be able to 
do that anyway even today.

Yet, I am involved with many different system integrators which must make 
quite an effort to adjust the operation to their needs these days. This 
includes adding proprietary patches. System integrators normally would compile 
their own kernel, I would see no problems in changing the LRNG such that:

- the entropy source configuration is a compile time-only setting with the 
current default values

- the runtime configuration is only enabled with a compile time option that is 
clearly marked as a development / test option and not to be used for runtime 
(like the other test interfaces). It would be disabled by default. Note, I 
have developed a regression test suite to test the LRNG operation and 
behavior. For this, such boottime/runtime settings come in very handy.

Regular administrators would not recompile their kernel. Thus Linux distros 
would simply go with the default by not enabling the test interface and have 
safe defaults. This implies that normal admins do not have the freedom to make 
adjustments. Therefore, I think we would have what you propose: a foolproof 
operation. Yet, people who really need the freedom (as otherwise they will 
make some other problematic changes) have the ability to alter the kernel 
compile time configuration to suit their needs. 

Besides, the LRNG contains the logic to verify the settings and guarantee that 
wrong configurations cannot be applied even at compile time. The term wrong 
configuration refers to configurations which would violate mathematical 
constraints. Therefore, the offered flexibility is still ensuring that such 
integrators cannot mess things up to the extent that mathematically something 
goes wrong.


On the other hand, when you refer to the changing of the used cryptographic 
algorithms, I think all offered options are per definition safe: all offer the 
same security strength. A configuration of the cryptographic algorithms is 
what I would suggest to allow to administrators. This is similar to changing 
the cryptographic algorithms for, say, network communication where the 
administrator is in charge of configuring the allowed / used cipher suites.

Ciao
Stephan