VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

[Dr Paul Dale]

Mark, I agree that the project area would be better for this discussion.

For those not involved, this revolves around the vote to merge PR#9084 and possible alternate mitigations for the underlying problem.


Tim’s explanatory message is:

> For the record, I think we need to do a better job of tackling the underlying issue.
> Dealing with systems on first boot with no entropy is an issue for a class of systems.
> However we should be distinguishing between contexts where we have decent seeding material (from having had reasonable entropy) from those where we haven't.
> We also should be able to persist seeding across boots and have recommendations for how vendors should do that.
> We should be able to fall back to handling it at the user level (i.e. non-root user, persisted in the file system).
> We need knowledge of install state (for FIPS) and that can also act as a first-boot state effectively.
> 
> And this applies equally to getentropy usage - it is only a problem in very limited contexts where blocking actually makes sense to perform.
> That the kernel has no additional entropy available is not necessarily an issue - except in a very limited context (first time boot with no other entropy available from previous contexts). 



Viktor replied:

> I just want to make sure we don't lock ourselves in to a single
> potentially clumsy solution in the library.  Various strategies
> may be appropriate depending on the platform, and ultimately the
> cooperation of the system administrator to enable the required
> mechanisms.
> 
> Potential additional sources for initial entropy on systems
> without getrandom(2) might include:
> 
>   RDSEED/RDRAND
>   TPM (or Virtualized TPM which is sometimes better!)
>   RNG state saved across reboots.
>   ...
> 
> This requires knowledge of various platforms, and potential
> help from the platform vendors.  It might, for example, make
> sense to delegate initial seeding to systemd on platforms
> that use systemd, and work with the systemd maintainers to
> provide a set of sensible entropy sources for initial boot.
> 
> Exposing a decent RNG to virtual guests and containers is
> would be another area of focus.



My suggestion as a fallback would be Stephan Müller’s CPU Jitter <http://chronox.de/jent/doc/CPU-Jitter-NPTRNG.html>.  He’s collected a large corpus of data from many processors and the scheme works relatively quickly.



Pauli
-- 
Dr Paul Dale | Cryptographer | Network Security & Encryption 
Phone +61 7 3031 7217
Oracle Australia



> On 7 Jun 2019, at 5:19 pm, Mark J Cox <mark at awe.com> wrote:
> 
> Could we have this more detailed discussion on -project?
> 
> Mark


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20190607/6829ab7a/attachment-0001.html>