VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

Dr Paul Dale paul.dale at
Fri Jun 7 08:03:26 UTC 2019

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:
>   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 <>.  He’s collected a large corpus of data from many processors and the scheme works relatively quickly.

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> wrote:
> Could we have this more detailed discussion on -project?
> Mark

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the openssl-project mailing list