Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

> 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 p

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

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 sm

VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

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

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

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 inst

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

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

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

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/r

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

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 discussio

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

>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. I

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

> 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/ura

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

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 versi

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

> 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

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

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 RN

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

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. > > Y

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

> 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

AW: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

> 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

AW: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

> 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

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

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 "unexp

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, becau

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

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'

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

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-u

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

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

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

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 approp

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

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 du

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

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 explanator

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

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 t