VOTE Apply PR#9084 reverting DEVRANDOM_WAIT
Dr Paul Dale
paul.dale at oracle.com
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).
> 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
> 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 <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.
Dr Paul Dale | Cryptographer | Network Security & Encryption
Phone +61 7 3031 7217
> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openssl-project