Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

2019-06-07 Thread Viktor Dukhovni
> On Jun 7, 2019, at 7:24 PM, Kurt Roeckx  wrote:
> 
> That's all very nice, but nobody is going to run that.

They also don't have to upgrade their kernel, or deploy new
versions of OpenSSL.  If platform release engineers don't
deploy core services that ensure reliably CSPRNG seeding,
then their platform is less secure at boot.  This is their
choice.  Users can vote with their feet for more secure
O/S distributions.

Secure CSPRNG seeding is a platform responsibility, OpenSSL
then runs secure PRNGs seeded from the platform.  There's
only so much we can reasonably do.  The rest has to happen
outside of OpenSSL, as a pre-requisite.

And yes, fallback on RDSEED/RDRAND + TPM (real or virtual)
+ whatever is available, but ideally not in libcrypto, but
rather a service that that seeds the system at boot.

Those other mechanisms are often either not fully trusted in
isolation, not always available, or too expensive at every
process start.  The logic to identify which are available,
and how many are enough, ... is best extracted to run separately
at boot, with the library using either getentropy() or read
/dev/urandom (older kernels).

-- 
Viktor.



Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

2019-06-07 Thread Dr Paul Dale
The devices where I’ve experienced long start up delays didn’t all have a HRNG. 
 The rng-tools wouldn’t have achieved anything.

ColdFire based routers running a 2.0 Linux kernel were the first time I 
personally saw this one.  uClinux still supported 2.0 kernels last I checked — 
they are very small and relatively fast.


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



> On 8 Jun 2019, at 5:25 am, Kurt Roeckx  wrote:
> 
> On Fri, Jun 07, 2019 at 03:08:24PM -0400, Viktor Dukhovni wrote:
>>> On Jun 7, 2019, at 2:41 PM, Kurt Roeckx  wrote:
>>> 
 This is not the sort of thing to bolt into the kernel, but is not
 unreasonable for systemd and the like.
>>> 
>>> The kernel actually already does this in recent versions, if
>>> configured to do it.
>> 
>> We're talking about what to do with for older kernels.
> 
> For older kernels you install rng-tools that feeds the hwrng in
> the kernel.
> 
> 
> Kurt
> 



VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

2019-06-07 Thread Dr Paul Dale
This vote has been closed, it passed 5 votes to 2 with no abstentions.


Up for discussion is the text of the next vote.  I’m proposing this:

Topic: The OpenSSL 3.0.0 release will include mitigation for the low entropy on 
boot and first boot problems.
Comment: PR#9084 removed such mitigation due to the negative side effects.


I’ll make this formal in a day or so, so if anyone wants to suggest alternative 
wording, that’s the time line.  The vote text is the “topic” line, the comment 
is explanatory only.

Note: I’m not mentioning the mechanism used, that still needs to be decided on. 
 This is just saying that 3.0.0 *will* have some mechanism.


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





Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

2019-06-07 Thread Kurt Roeckx
On Fri, Jun 07, 2019 at 07:04:57PM -0400, Viktor Dukhovni wrote:
> On Sat, Jun 08, 2019 at 12:54:36AM +0200, Kurt Roeckx wrote:
> 
> > On Fri, Jun 07, 2019 at 03:37:07PM -0400, Viktor Dukhovni wrote:
> > > > On Jun 7, 2019, at 3:25 PM, Kurt Roeckx  wrote:
> > > > 
> > > > For older kernels you install rng-tools that feeds the hwrng in
> > > > the kernel.
> > > 
> > > Which works for me, and is pretty much the point I'm trying to make.
> > > Then, read /dev/random once early at boot, and do nothing special
> > > libcrypto (safely use /dev/urandom).
> > 
> > The only thing rng-tools will actually solve is the starvation
> > issue. No service will depend on it, since they don't have any
> > relationship with it. Nor can you wait for it, it's not because
> > it's started that it has initialized the kernel. I think I've also
> > seen reports that it got started too late, actually after a
> > services that wants to ask the kernel for random numbers.
> 
> Then a different service can be developed that does block just once
> at boot, and tries to obtain entropy from a configurable set of
> sources (to avoid or reduce unbounded delay, and mix in more
> independent sources).

That's all very nice, but nobody is going to run that.


Kurt



Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

2019-06-07 Thread Viktor Dukhovni
On Sat, Jun 08, 2019 at 12:54:36AM +0200, Kurt Roeckx wrote:

> On Fri, Jun 07, 2019 at 03:37:07PM -0400, Viktor Dukhovni wrote:
> > > On Jun 7, 2019, at 3:25 PM, Kurt Roeckx  wrote:
> > > 
> > > For older kernels you install rng-tools that feeds the hwrng in
> > > the kernel.
> > 
> > Which works for me, and is pretty much the point I'm trying to make.
> > Then, read /dev/random once early at boot, and do nothing special
> > libcrypto (safely use /dev/urandom).
> 
> The only thing rng-tools will actually solve is the starvation
> issue. No service will depend on it, since they don't have any
> relationship with it. Nor can you wait for it, it's not because
> it's started that it has initialized the kernel. I think I've also
> seen reports that it got started too late, actually after a
> services that wants to ask the kernel for random numbers.

Then a different service can be developed that does block just once
at boot, and tries to obtain entropy from a configurable set of
sources (to avoid or reduce unbounded delay, and mix in more
independent sources).

-- 
Viktor.


Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

2019-06-07 Thread Kurt Roeckx
On Fri, Jun 07, 2019 at 03:37:07PM -0400, Viktor Dukhovni wrote:
> > On Jun 7, 2019, at 3:25 PM, Kurt Roeckx  wrote:
> > 
> > For older kernels you install rng-tools that feeds the hwrng in
> > the kernel.
> 
> Which works for me, and is pretty much the point I'm trying to make.
> Then, read /dev/random once early at boot, and do nothing special
> libcrypto (safely use /dev/urandom).

The only thing rng-tools will actually solve is the starvation
issue. No service will depend on it, since they don't have any
relationship with it. Nor can you wait for it, it's not because
it's started that it has initialized the kernel. I think I've also
seen reports that it got started too late, actually after a
services that wants to ask the kernel for random numbers.

An other solution might be that we enable rdrand/rdseed by default
as entropy source, after getentropy() and before /dev/urandom.


Kurt



Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

2019-06-07 Thread Kurt Roeckx
On Fri, Jun 07, 2019 at 07:01:30PM +, Salz, Rich wrote:
> 
> >The kernel actually already does this in recent versions, if
> configured to do it.
>   
> "The" kernel. Which one is that?  Which operating system?
> 
> Modern Linux is fine.  Is that all we care about?

This whole discussion has only been about Linux, we only define
DEVRANDOM_WAIT on Linux.

I think all other OSs have a sane /dev/urandom, but I'm not sure
about NetBSD.

> 1.1.1c made Solaris (and possibly others) more secure. I would be 
> disappointed if 1.1.1d took that away and tried to rationalize that "it's not 
> my job."  *YOU'RE A CRYPTOGRAPHIC LIBRARY* 

Do you have a reference that Solaris allows reading from
/dev/urandom before it's been initialized?


Kurt



Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

2019-06-07 Thread Salz, Rich

>The kernel actually already does this in recent versions, if
configured to do it.
  
"The" kernel. Which one is that?  Which operating system?

Modern Linux is fine.  Is that all we care about?

No issues were raised when the RSA keylength was increased, or MD5 was replaced 
with SHA1.  In fact, that is a very good example; we get many questions about 
"why can't I decrypt old text" because of this.  And here we got what, one 
posting?

1.1.1c made Solaris (and possibly others) more secure. I would be disappointed 
if 1.1.1d took that away and tried to rationalize that "it's not my job."  
*YOU'RE A CRYPTOGRAPHIC LIBRARY* 



Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

2019-06-07 Thread Viktor Dukhovni
> On Jun 7, 2019, at 3:25 PM, Kurt Roeckx  wrote:
> 
> For older kernels you install rng-tools that feeds the hwrng in
> the kernel.

Which works for me, and is pretty much the point I'm trying to make.
Then, read /dev/random once early at boot, and do nothing special
libcrypto (safely use /dev/urandom).

-- 
Viktor.



Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

2019-06-07 Thread Kurt Roeckx
On Fri, Jun 07, 2019 at 03:08:24PM -0400, Viktor Dukhovni wrote:
> > On Jun 7, 2019, at 2:41 PM, Kurt Roeckx  wrote:
> > 
> >> This is not the sort of thing to bolt into the kernel, but is not
> >> unreasonable for systemd and the like.
> > 
> > The kernel actually already does this in recent versions, if
> > configured to do it.
> 
> We're talking about what to do with for older kernels.

For older kernels you install rng-tools that feeds the hwrng in
the kernel.


Kurt



Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

2019-06-07 Thread Viktor Dukhovni
> On Jun 7, 2019, at 2:41 PM, Kurt Roeckx  wrote:
> 
>> This is not the sort of thing to bolt into the kernel, but is not
>> unreasonable for systemd and the like.
> 
> The kernel actually already does this in recent versions, if
> configured to do it.

We're talking about what to do with for older kernels, and in
cases when the kernel cannot promptly obtain sufficient entropy
without external sources.  The kernel's job is to mix in entropy
from natural activity.  Boot-time acquisition of non-trivial entropy
by other means falls outside the kernel, and may be needed when
the kernel cannot obtain sufficient entropy on its own in a timely
manner.

-- 
Viktor.



Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

2019-06-07 Thread Kurt Roeckx
On Fri, Jun 07, 2019 at 02:31:54PM -0400, Viktor Dukhovni wrote:
> 
> That's a different issue.  What I was suggesting was a service that
> waits for seeding to be ready.  So that other services can depend
> on that service, with that service using various sources to adequately
> seed the kernel RNG, with configurable additional sources beyond the
> save file, possibly with a non-zero entropy estimate.  Thus, for example,
> a virtual machine or container might make use of an interface to get a
> a trusted seed from the host hypervisor/OS.  Or a physical host might
> trust its TPM, ...
> 
> This is not the sort of thing to bolt into the kernel, but is not
> unreasonable for systemd and the like.

The kernel actually already does this in recent versions, if
configured to do it.


Kurt



Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

2019-06-07 Thread Kurt Roeckx
On Fri, Jun 07, 2019 at 06:06:02PM +, Dr. Matthias St. Pierre wrote:
> > Introducing DEVRANDOM_WAIT didn't cause any change for us, because
> > we use getentropy(), and a recent kernel. But even systems that
> > use getentropy() with an older kernel can have a large delay after
> > boot.
> 
> Yes, but that's the crucial difference IMHO: while getentropy() on blocks once
> during the early boot phase until its initial seeding completes, the 
> DEVRANDOM_WAIT
> approach will block several times, depending on how much the other processes 
> drain
> the /dev/random device.

I agree that the solution is not ideal, but I think it's better than
not having it.


Kurt



Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

2019-06-07 Thread Viktor Dukhovni
> On Jun 7, 2019, at 2:11 PM, Dr. Matthias St. Pierre 
>  wrote:
> 
>> The init system would
>> need to create this kind of service, and then all software not using
>> getentropy()/getrandom() would need to depend on that service. It
> 
> FWIW: systemd already has a service for saving and restoring a random seed.
> If I understood Tomas correctly, the saved seed is added to the random pool,
> but without crediting any entropy to it (which sounds reasonable to me).

That's a different issue.  What I was suggesting was a service that
waits for seeding to be ready.  So that other services can depend
on that service, with that service using various sources to adequately
seed the kernel RNG, with configurable additional sources beyond the
save file, possibly with a non-zero entropy estimate.  Thus, for example,
a virtual machine or container might make use of an interface to get a
a trusted seed from the host hypervisor/OS.  Or a physical host might
trust its TPM, ...

This is not the sort of thing to bolt into the kernel, but is not
unreasonable for systemd and the like.

Applications can then use getentropy() and not even block at boot
time, if the system collects entropy at boot automatically and
without excessive delay.  The job of improving the source quality
and eliminating avoidable delay is then (correctly IMHO) the
responsibility of the platform's init system.

As for what to do on older platforms, ... add an entropy gathering
service to the system start up configuration, and make applications
that need early seed material depend on that service.

Perhaps the OpenSSL project can curate some examples of such service
configurations/scripts.  The simplest might be just DEVRANDOM_WAIT
as a service that runs at boot, and only reports "ready" once
/dev/random is ready.  After that applications can just use
/dev/urandom with some confidence of adequate seeding.

-- 
Viktor.



AW: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

2019-06-07 Thread Dr. Matthias St. Pierre
> The reason I think nothing will change is that the problem is
> already solved, use getentropy()/getrandom(). 

I agree completely.

> The init system would
> need to create this kind of service, and then all software not using
> getentropy()/getrandom() would need to depend on that service. It

FWIW: systemd already has a service for saving and restoring a random seed.
If I understood Tomas correctly, the saved seed is added to the random pool,
but without crediting any entropy to it (which sounds reasonable to me).

https://www.freedesktop.org/software/systemd/man/systemd-random-seed.service.html


Matthias




AW: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

2019-06-07 Thread Dr. Matthias St. Pierre
> Introducing DEVRANDOM_WAIT didn't cause any change for us, because
> we use getentropy(), and a recent kernel. But even systems that
> use getentropy() with an older kernel can have a large delay after
> boot.

Yes, but that's the crucial difference IMHO: while getentropy() on blocks once
during the early boot phase until its initial seeding completes, the 
DEVRANDOM_WAIT
approach will block several times, depending on how much the other processes 
drain
the /dev/random device.

Matthias


> -Ursprüngliche Nachricht-
> Von: openssl-project  Im Auftrag von 
> Kurt Roeckx
> Gesendet: Freitag, 7. Juni 2019 19:52
> An: Tomas Mraz 
> Cc: openssl-project@openssl.org
> Betreff: Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT
> 
> On Fri, Jun 07, 2019 at 10:18:32AM +0200, Tomas Mraz wrote:
> >
> > From the point of view of distribution maintainer of OpenSSL I would
> > say what we had in 1.1.1 before the introduction of DEVRANDOM_WAIT had
> > no real problems for us.
> 
> Introducing DEVRANDOM_WAIT didn't cause any change for us, because
> we use getentropy(), and a recent kernel. But even systems that
> use getentropy() with an older kernel can have a large delay after
> boot.
> 
> 
> Kurt



Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

2019-06-07 Thread Kurt Roeckx
On Fri, Jun 07, 2019 at 01:28:30PM -0400, Viktor Dukhovni wrote:
> 
> I think that having the RNG behaviour capriciously different on
> different systems based on the whims of whoever built the library
> for that system is not a good idea.  OpenSSL should provide an RNG
> that does not block "unexpectedly", indefinitely, and unpredictably.
> 
> Where "unexpectedly", means except possibly early at boot time, but
> ideally waiting for boot-time entropoy is something that systemd
> and the like take care of, and application start scripts can just
> register a dependency on some sort of "entropy" service, whose
> successful initialization is sufficient to ensure adequately secure
> non-blocking seeding of applications via one of getentropy(),
> getrandom(), /dev/urandom...
> 
> That is, I'd expect most of the work for ensuring adequate entropy
> to happen outside libcrypto, except for perhaps enabling some
> additional sources that may be available on various systems.

It seems unlikely that anything related to this will ever change,
but we can always ask.

The reason I think nothing will change is that the problem is
already solved, use getentropy()/getrandom(). The init system would
need to create this kind of service, and then all software not using
getentropy()/getrandom() would need to depend on that service. It
would be eaier to just switch that software to use
getentropy()/getrandom().

Changing the init system, means that this will only work for new
versions of an OS. But on those new versions we already use
getentropy()/getrandom(). What we want to support is people that
use an old OS, but run a new version of OpenSSL on it. That is,
people that do not use the OS provided OpenSSL version.


Kurt



Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

2019-06-07 Thread Kurt Roeckx
On Fri, Jun 07, 2019 at 10:18:32AM +0200, Tomas Mraz wrote:
> 
> From the point of view of distribution maintainer of OpenSSL I would
> say what we had in 1.1.1 before the introduction of DEVRANDOM_WAIT had
> no real problems for us.

Introducing DEVRANDOM_WAIT didn't cause any change for us, because
we use getentropy(), and a recent kernel. But even systems that
use getentropy() with an older kernel can have a large delay after
boot.


Kurt



Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

2019-06-07 Thread Kurt Roeckx
On Fri, Jun 07, 2019 at 06:03:26PM +1000, Dr Paul Dale wrote:
> 
> 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.

I don't think we should be collecting entropy from CPU jitter
ourself. If that's something useful, it should be up to the OS
to provide it to us. But it seems highly unlikely that that will
happen since there seems to be little trust in that it actually
provides the entropy.


Kurt



Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

2019-06-07 Thread Viktor Dukhovni
On Fri, Jun 07, 2019 at 11:09:45AM +0200, Matthias St. Pierre wrote:

> See the discussion on openssl-users:
> 
> https://mta.openssl.org/pipermail/openssl-users/2019-May/010585.html
> https://mta.openssl.org/pipermail/openssl-users/2019-May/010593.html
> https://mta.openssl.org/pipermail/openssl-users/2019-May/010595.html
> 
> If desired, I can provide an alternative (competing) pull request which
> makes the DEVRANDOM_WAIT feature configurable in a proper and
> reasonable way. The default will be whatever the OMC decides.

I think that having the RNG behaviour capriciously different on
different systems based on the whims of whoever built the library
for that system is not a good idea.  OpenSSL should provide an RNG
that does not block "unexpectedly", indefinitely, and unpredictably.

Where "unexpectedly", means except possibly early at boot time, but
ideally waiting for boot-time entropoy is something that systemd
and the like take care of, and application start scripts can just
register a dependency on some sort of "entropy" service, whose
successful initialization is sufficient to ensure adequately secure
non-blocking seeding of applications via one of getentropy(),
getrandom(), /dev/urandom...

That is, I'd expect most of the work for ensuring adequate entropy
to happen outside libcrypto, except for perhaps enabling some
additional sources that may be available on various systems.

--
Viktor.


Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

2019-06-07 Thread Matthias St. Pierre



On 07.06.19 10:45, Tomas Mraz wrote:



 From the point of view of distribution maintainer of OpenSSL I would
say what we had in 1.1.1 before the introduction of DEVRANDOM_WAIT
had
no real problems for us.

And to clarify myself - we have no problem with the DEVRANDOM_WAIT
introduction either as the -DDEVRANDOM=/dev/urandom works nicely for
us.



Thomas' solution works, but it is not more than a workaround,
a hack which is exploiting the fact that the DEVRANDOM_WAIT
code is placed inside an `# ifndef DEVRANDOM`.

See the discussion on openssl-users:

https://mta.openssl.org/pipermail/openssl-users/2019-May/010585.html
https://mta.openssl.org/pipermail/openssl-users/2019-May/010593.html
https://mta.openssl.org/pipermail/openssl-users/2019-May/010595.html

If desired,  I can provide an alternative (competing) pull request which
makes the DEVRANDOM_WAIT feature configurable in a proper and
reasonable way. The default will be whatever the OMC decides.

Matthias



Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

2019-06-07 Thread Tomas Mraz
On Fri, 2019-06-07 at 10:18 +0200, Tomas Mraz wrote:
> On Fri, 2019-06-07 at 18:03 +1000, Dr Paul Dale wrote:
> > 
> > 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.
> 
> From the point of view of distribution maintainer of OpenSSL I would
> say what we had in 1.1.1 before the introduction of DEVRANDOM_WAIT
> had
> no real problems for us.

And to clarify myself - we have no problem with the DEVRANDOM_WAIT
introduction either as the -DDEVRANDOM=/dev/urandom works nicely for
us.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]




Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

2019-06-07 Thread Dr Paul Dale

Storing entropy has risks — cloning attacks, reading the file attacks, etc.  It 
is better trying than doing nothing.  Counting such stored entropy as 
additional data is good but many systems have no alternative entropy available. 
 I have had to introduce such storing schemes (with generation during 
fulfilment) when devices would take well over ten minutes to find enough 
entropy to generate their initial (long term) key material.  There are ways to 
mitigate the reuse risk — lock the entropy file, read it, add the contents to 
the kernel, regenerate the file and finally unlock it.  Plus regenerating the 
contents and storing them on shutdown (if not periodically).  A cloned VM would 
still be vulnerable (at least for a while).

Also agreed for an option to disable this.  I’d prefer that it is on by default 
(i.e. secure by default and requiring a decision to not be secure).


I’m expecting a somewhat lively discussion about a sensitive topic :)


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



> On 7 Jun 2019, at 6:18 pm, Tomas Mraz  wrote:
> 
> On Fri, 2019-06-07 at 18:03 +1000, Dr Paul Dale wrote:
>> 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). 
> 
> The previous context can easily provide false entropy - for example due
> to the booting system being a cloned virtual machine. Or boot image for
> a small router device which contains such saved entropy which is
> distributed to millions of devices worldwide.
> 
> This was the reason why systemd guys rejected the idea to actually seed
> the kernel rng with such entropy with the call that counts this seed
> entropy. They just use it as additional seed with no accounting for the
> entropy it would provide if it was not reused.
> 
>> 
>> 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.
> 
> From the point of view of distribution maintainer of OpenSSL I would
> say what we had in 1.1.1 before the introduction of DEVRANDOM_WAIT had
> no real problems for us.
> 
> However I can understand that when OpenSSL is built and installed
> separately by application vendors on some legacy system that they do
> not have control of they might appreciate that the library itself tries
> to solve the hard problems related to the entropy gathering for them.
> 
> So I would just ask for one thing - all this additional stuff should be
> optional - I do not of course care wheter it is opt-in or opt-out as
> that is easily handled in our builds.
> 
>> 
>> 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.
> 
> +1 to that.
> 
> -- 
> Tomáš Mráz
> No matter how far down the wrong road you've gone, turn back.
>