Re: Work on a new RNG for OpenSSL

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
50 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Work on a new RNG for OpenSSL

OpenSSL - Dev mailing list

Thanks everyone for the discussion (mainly in June) about this.  There’s a blog post describing what we’ve done for the 1.1.1 release: https://www.openssl.org/blog/blog/2017/08/12/random/

 


--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Work on a new RNG for OpenSSL

Blumenthal, Uri - 0553 - MITLL

Thanks everyone for the discussion (mainly in June) about this.  There’s a blog post describing what we’ve done for the 1.1.1 release: https://www.openssl.org/blog/blog/2017/08/12/random/

 

Nice. But some important things could be made clearer.

 

We added a new configuration parameter, --with-rand-seed, which takes a comma-separated list of values for seed sources. Each method is tried in turn, stopping when enough bits of randomness have been collected.

 

  1. What’s the default if “with-rand-seed” was not provided? All of the listed supported types? None of them? Some of them…?
  2. What is the order in which the seed sources are tried (both when “with-random-seed” was and was not given)?
  3. What should I do if I want a given source to be used in addition to the other sources, regardless of whether openssl thinks it got “enough bits” of randomness or not?

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Work on a new RNG for OpenSSL

OpenSSL - Dev mailing list
> 1. What’s the default if “with-rand-seed” was not provided? All of the listed supported types? None of them? Some of them…?

As the first bullet says, it’s “os”.   As for the second part of your question, it is deliberately not answered.   If you care, you’ll have to read the source.  (It’s clean and easy to do so, now.)  We’re not documenting everything.

>2. What is the order in which the seed sources are tried (both when “with-random-seed” was and was not given)?

Read the source.

> 3. What should I do if I want a given source to be used in addition to the other sources, regardless of whether openssl thinks it got “enough bits” of randomness or not?

Modify the source :)

For a few reasons, we’re deliberately not documenting all the details.  Interested parties will have to read the source.



--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Work on a new RNG for OpenSSL

Blumenthal, Uri - 0553 - MITLL
>> 1. What’s the default if “with-rand-seed” was not provided? All of the listed supported types? None of them? Some of them…?
>  
>   As the first bullet says, it’s “os”.  

OK, thanks.

> As for the second part of your question, it is deliberately not answered.   If you care, you’ll have to read the source.  (It’s clean and easy to do so, now.)  We’re not documenting everything.
   
I think it’s a bad approach to not document this important behavior. It has to be security-analyzed, then frozen & published.

>>2. What is the order in which the seed sources are tried (both when “with-random-seed” was and was not given)?
>
> Read the source.

Likewise. It has to be published, and the developers need to figure out the right way here and commit to it (no pun intended).
   
>> 3. What should I do if I want a given source to be used in addition to the other sources, regardless of whether openssl thinks it got “enough bits” of randomness or not?
>
> Modify the source :)

Very bad answer.

When randomness is involved, adding more of diverse sources can only improve the outcome. Therefore there must be a way to tell OpenSSL to *not* stop when it got what it believe to be “enough” but mix in more from other sources. And that mechanism must *not* be an individual hack – but a standard reviewed maintained access method.
   
> For a few reasons, we’re deliberately not documenting all the details.  Interested parties will have to read the source.
   
I have no problem reading the source code. I do have a problem with (a) important decisions like this not “formalized” and documented, and (b) mechanisms to tune the RNG seeding not provided and clearly and comprehensively documented.

I urge the developers to reconsider.


--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Work on a new RNG for OpenSSL

OpenSSL - Dev mailing list
>>> 3. What should I do if I want a given source to be used in addition to the other sources, regardless of whether openssl thinks it got “enough bits” of randomness or not?

>> Modify the source :)
   
>    Very bad answer.

And also a wrong one.  Your application can always call RAND_add().  Sorry for mistake.
   
> I have no problem reading the source code. I do have a problem with (a) important decisions like this not “formalized” and documented, and (b) mechanisms to tune the RNG seeding not provided and clearly and comprehensively documented.
   
This is a mostly volunteer open source project.  We are unlikely to commit to something that requires so much effort when, frankly, most of the consumers aren’t interested, or qualified, to make an assessment.  I am sorry if that sounds obnoxious or conceited.  It shouldn’t; there are many things that I know I’m not qualified to comment on :)  And also, we reserve the right to make changes.

I expect that the FIPS project, just starting, will be of interest to you.

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Work on a new RNG for OpenSSL

Blumenthal, Uri - 0553 - MITLL
   >>> Modify the source :)
    >>  
    >>    Very bad answer.
   >
   >    And also a wrong one.  Your application can always call RAND_add().  Sorry for mistake.
     
And this is a very good answer. Perhaps this guidance deserves being documented somewhere besides this mailing list? Something along the lines of

“RNG Seed Sources can be set by --with-rand-seed. “os” is the default source. Sources are tried until enough bits of randomness have been collected. If you want to mix data from a particular source into the seed, but don’t want to make that source exclusive – use RAND_add() method.”
   
 > This is a mostly volunteer open source project.

Yeah, I realize and appreciate that.

> We are unlikely to commit to something that requires so much effort

I’m not sure I agree here. What effort are you talking about? In order to select an order in which available sources are queried, the developers had to think (hopefully :). Those thought could be documented in a few lines of text.

> when, frankly, most of the consumers aren’t interested, or qualified, to make an assessment.

So they’ll be happy with the default. Fine with me. ;-)

>  I am sorry if that sounds obnoxious or conceited.  It shouldn’t; there are many things that I know I’m not qualified to comment on :)  And also, we reserve the right to make changes.

No offense taken. But you “freeze” interface to and behavior of ciphers and cipher modes, for example. This (how you seed RNG that provides keys to those) is at least equally important. It’s not a minute detail that nobody should care about or nose in.

So while the team clearly has the right to make changes (especially before the interface became public ;), but I’d rather that such changes  are guided by an informed consent from the public (such as yours truly ;).
   
 >   I expect that the FIPS project, just starting, will be of interest to you.
   
Thank you – indeed it is of  interest. (Though I see FIPS more as a curse than as a blessing ;-).
 
One important thing I missed earlier:

>  We also added a separate global DRBG for private key generation and added API’s to use it.
> This object isn’t reachable directly, but it is used by the new BN_priv_rand and BN_priv_rand_range API’s.
> Those API’s, in turn, are used by all private-key generating functions.

I think it is *imperative* for a user to be able to RAND_add() to the DRBG that gnerates private keys. I cannot emphasize enough how critical this is.


--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Work on a new RNG for OpenSSL

OpenSSL - Dev mailing list
And this is a very good answer. Perhaps this guidance deserves being documented somewhere besides this mailing list? Something along the lines of
        It is documented in the RAND_add manpage.

➢ I’m not sure I agree here. What effort are you talking about? In order to select an order in which available sources are queried, the developers had to think (hopefully :). Those thought could be documented in a few lines of text.
   
And what would be the point?  Why should someone trust the documentation, which can get out of date, more than the source?

➢     So while the team clearly has the right to make changes (especially before the interface became public ;), but I’d rather that such changes  are guided by an informed consent from the public (such as yours truly ;).

We aren’t cutting off any avenues of participation.  Email discussion and pull requests are always welcome.  But yes, the barrier to useful participation is that someone has to first read and understand the source.

➢ I think it is *imperative* for a user to be able to RAND_add() to the DRBG that gnerates private keys. I cannot emphasize enough how critical this is.
   
    I am curious to know your justification for this.  It seems to me that if you accept the DRBG document, which we do, then the way we do the seeding is fine.  If you don’t accept the document, then modify the source.


--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Work on a new RNG for OpenSSL

Paul Kehrer
In reply to this post by OpenSSL - Dev mailing list
Great news and congratulations to everyone on landing this work.

I see that the RNG is now capable of automatically reseeding itself on
fork, which will be a huge win for applications that aren't rigorous
about doing so themselves (read: most of them). However, it appears
that OPENSSL_INIT_ATFORK is not set as an option when OpenSSL calls
OPENSSL_init_crypto. Would it be possible to make this default? This
would be a large improvement in terms of protecting applications
linking against OpenSSL.

-Paul Kehrer (reaperhulk)

On Mon, Aug 14, 2017 at 10:45 AM, Salz, Rich via openssl-dev
<[hidden email]> wrote:

> Thanks everyone for the discussion (mainly in June) about this.  There’s a
> blog post describing what we’ve done for the 1.1.1 release:
> https://www.openssl.org/blog/blog/2017/08/12/random/
>
>
>
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Work on a new RNG for OpenSSL

OpenSSL - Dev mailing list
I understand the concern.  The issue I am wrestling with is strict compatibility with the existing code.  Does anyone really *want* the RNG’s to not reseed on fork?  It’s hard to imagine, but maybe somewhere someone is.  And then it’s not about just reseeding, but what about when (if) we add other things, like whether or not the secure arena gets zero’d in a child?

So let me phrase it this way:  does anyone object to changing the default so NO_ATFORK must be used to avoid the reseeding and other things we might add later?

    By the way I noticed that openssl_init_fork_handlers() is not guarded by
    RUN_ONCE(). This should be fixed, too.
   
Yeah, I’ll fix that; thanks.

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Work on a new RNG for OpenSSL

Matt Caswell-2


On 17/08/17 13:22, Salz, Rich via openssl-dev wrote:

> I understand the concern.  The issue I am wrestling with is strict
> compatibility with the existing code.  Does anyone really *want* the
> RNG’s to not reseed on fork?  It’s hard to imagine, but maybe
> somewhere someone is.  And then it’s not about just reseeding, but
> what about when (if) we add other things, like whether or not the
> secure arena gets zero’d in a child?
>
> So let me phrase it this way:  does anyone object to changing the
> default so NO_ATFORK must be used to avoid the reseeding and other
> things we might add later?

It's difficult to think of what circumstances this might break existing
code? What scenario did you have in mind? Even if it does break
something obscure, I think this is a case where security-by-default
takes precedence.

Matt
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Work on a new RNG for OpenSSL

Tomas Mraz-2
In reply to this post by OpenSSL - Dev mailing list
On Thu, 2017-08-17 at 12:22 +0000, Salz, Rich via openssl-dev wrote:

> I understand the concern.  The issue I am wrestling with is strict
> compatibility with the existing code.  Does anyone really *want* the
> RNG’s to not reseed on fork?  It’s hard to imagine, but maybe
> somewhere someone is.  And then it’s not about just reseeding, but
> what about when (if) we add other things, like whether or not the
> secure arena gets zero’d in a child?
>
> So let me phrase it this way:  does anyone object to changing the
> default so NO_ATFORK must be used to avoid the reseeding and other
> things we might add later?

I can hardly see anyone would be broken if the default is to reseed
RNG on fork. However that might not be true for other atfork
functionalities so perhaps there is a need to make each of these future
atfork functions configurable and either on or off by default
individually and not as a whole.


>     By the way I noticed that openssl_init_fork_handlers() is not
> guarded by
>     RUN_ONCE(). This should be fixed, too.
>     
> Yeah, I’ll fix that; thanks.
>
--
Tomáš Mráz
Red Hat

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

 * Google and NSA associates, this message is none of your business.
 * Please leave it alone, and consider whether your actions are
 * authorized by the contract with Red Hat, or by the US constitution.
 * If you feel you're being encouraged to disregard the limits built
 * into them, remember Edward Snowden and Wikileaks.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Work on a new RNG for OpenSSL

OpenSSL - Dev mailing list
In reply to this post by Matt Caswell-2
\
    > somewhere someone is.  And then it’s not about just reseeding, but
    > what about when (if) we add other things, like whether or not the
    > secure arena gets zero’d in a child?
   
    It's difficult to think of what circumstances this might break existing
    code? What scenario did you have in mind?

As excerpted above in my post.

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Work on a new RNG for OpenSSL

Blumenthal, Uri - 0553 - MITLL
I have only one issue with the current design: the apparent absence of RAND_add() interface for the "private" RNG.

I request that it is added (no pun intended, really :).

Regards,
Uri

Sent from my iPhone

> On Aug 17, 2017, at 09:18, Salz, Rich via openssl-dev <[hidden email]> wrote:
>
> \
>> somewhere someone is.  And then it’s not about just reseeding, but
>> what about when (if) we add other things, like whether or not the
>> secure arena gets zero’d in a child?
>
>    It's difficult to think of what circumstances this might break existing
>    code? What scenario did you have in mind?
>
> As excerpted above in my post.
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Work on a new RNG for OpenSSL

Kurt Roeckx
In reply to this post by Tomas Mraz-2
On Thu, Aug 17, 2017 at 02:34:49PM +0200, Tomas Mraz wrote:

> On Thu, 2017-08-17 at 12:22 +0000, Salz, Rich via openssl-dev wrote:
> > I understand the concern.  The issue I am wrestling with is strict
> > compatibility with the existing code.  Does anyone really *want* the
> > RNG’s to not reseed on fork?  It’s hard to imagine, but maybe
> > somewhere someone is.  And then it’s not about just reseeding, but
> > what about when (if) we add other things, like whether or not the
> > secure arena gets zero’d in a child?
> >
> > So let me phrase it this way:  does anyone object to changing the
> > default so NO_ATFORK must be used to avoid the reseeding and other
> > things we might add later?
>
> I can hardly see anyone would be broken if the default is to reseed
> RNG on fork. However that might not be true for other atfork
> functionalities so perhaps there is a need to make each of these future
> atfork functions configurable and either on or off by default
> individually and not as a whole.

There might be cases where after fork you're not able to get to
/dev/urandom anymore.


Kurt

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Work on a new RNG for OpenSSL

Tomas Mraz-2
On Thu, 2017-08-17 at 22:11 +0200, Kurt Roeckx wrote:

> On Thu, Aug 17, 2017 at 02:34:49PM +0200, Tomas Mraz wrote:
> > On Thu, 2017-08-17 at 12:22 +0000, Salz, Rich via openssl-dev
> > wrote:
> > > I understand the concern.  The issue I am wrestling with is
> > > strict
> > > compatibility with the existing code.  Does anyone really *want*
> > > the
> > > RNG’s to not reseed on fork?  It’s hard to imagine, but maybe
> > > somewhere someone is.  And then it’s not about just reseeding,
> > > but
> > > what about when (if) we add other things, like whether or not the
> > > secure arena gets zero’d in a child?
> > >
> > > So let me phrase it this way:  does anyone object to changing the
> > > default so NO_ATFORK must be used to avoid the reseeding and
> > > other
> > > things we might add later?
> >
> > I can hardly see anyone would be broken if the default is to reseed
> > RNG on fork. However that might not be true for other atfork
> > functionalities so perhaps there is a need to make each of these
> > future
> > atfork functions configurable and either on or off by default
> > individually and not as a whole.
>
> There might be cases where after fork you're not able to get to
> /dev/urandom anymore.

I do not think so. Which particular cases do you have on mind? Yes,
after fork+exec you could for example switch SELinux domain and won't
be able to access something but immediately after fork it should not be
so. Also perhaps the reseeding after fork can be made less strict in
regards to failures reading /dev/urandom or so.

--
Tomáš Mráz
Red Hat

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

 * Google and NSA associates, this message is none of your business.
 * Please leave it alone, and consider whether your actions are
 * authorized by the contract with Red Hat, or by the US constitution.
 * If you feel you're being encouraged to disregard the limits built
 * into them, remember Edward Snowden and Wikileaks.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Work on a new RNG for OpenSSL

Kurt Roeckx
On Fri, Aug 18, 2017 at 09:22:48AM +0200, Tomas Mraz wrote:

> On Thu, 2017-08-17 at 22:11 +0200, Kurt Roeckx wrote:
> > On Thu, Aug 17, 2017 at 02:34:49PM +0200, Tomas Mraz wrote:
> > > On Thu, 2017-08-17 at 12:22 +0000, Salz, Rich via openssl-dev
> > > wrote:
> > > > I understand the concern.  The issue I am wrestling with is
> > > > strict
> > > > compatibility with the existing code.  Does anyone really *want*
> > > > the
> > > > RNG’s to not reseed on fork?  It’s hard to imagine, but maybe
> > > > somewhere someone is.  And then it’s not about just reseeding,
> > > > but
> > > > what about when (if) we add other things, like whether or not the
> > > > secure arena gets zero’d in a child?
> > > >
> > > > So let me phrase it this way:  does anyone object to changing the
> > > > default so NO_ATFORK must be used to avoid the reseeding and
> > > > other
> > > > things we might add later?
> > >
> > > I can hardly see anyone would be broken if the default is to reseed
> > > RNG on fork. However that might not be true for other atfork
> > > functionalities so perhaps there is a need to make each of these
> > > future
> > > atfork functions configurable and either on or off by default
> > > individually and not as a whole.
> >
> > There might be cases where after fork you're not able to get to
> > /dev/urandom anymore.
>
> I do not think so. Which particular cases do you have on mind? Yes,
> after fork+exec you could for example switch SELinux domain and won't
> be able to access something but immediately after fork it should not be
> so. Also perhaps the reseeding after fork can be made less strict in
> regards to failures reading /dev/urandom or so.

It seems to me this all depends on the order of things you do to
create a daemon. You could make sure the RNG is inited, chroot,
and then fork for instance. And I suspect there are actually
programs that do it in that order.


Kurt

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Work on a new RNG for OpenSSL

Blumenthal, Uri - 0553 - MITLL
All the items discussed are important.

But I’d like the development team to comment on (and ideally – accept) my request to add RAND_add() method to the RNG that is used in generation of private keys.
Reason/justification: to be able to improve the available randomness by mixing in output from hardware-based TRNG(s).
--
Regards,
Uri Blumenthal


--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Work on a new RNG for OpenSSL

OpenSSL - Dev mailing list
In reply to this post by Kurt Roeckx
    It seems to me this all depends on the order of things you do to
    create a daemon. You could make sure the RNG is inited, chroot,
    and then fork for instance. And I suspect there are actually
    programs that do it in that order.
   

Yes.

I think the safest thing is for us to not change the default.  Programs that know they are going to fork can do the right/safe thing.  It would be nicer if we could automatically always do the right thing, but I don’t think it’s possible.

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Work on a new RNG for OpenSSL

Christian Heimes
In reply to this post by Kurt Roeckx
On 2017-08-18 19:42, Kurt Roeckx wrote:

> On Fri, Aug 18, 2017 at 09:22:48AM +0200, Tomas Mraz wrote:
>> On Thu, 2017-08-17 at 22:11 +0200, Kurt Roeckx wrote:
>>> On Thu, Aug 17, 2017 at 02:34:49PM +0200, Tomas Mraz wrote:
>>>> On Thu, 2017-08-17 at 12:22 +0000, Salz, Rich via openssl-dev
>>>> wrote:
>>>>> I understand the concern.  The issue I am wrestling with is
>>>>> strict
>>>>> compatibility with the existing code.  Does anyone really *want*
>>>>> the
>>>>> RNG’s to not reseed on fork?  It’s hard to imagine, but maybe
>>>>> somewhere someone is.  And then it’s not about just reseeding,
>>>>> but
>>>>> what about when (if) we add other things, like whether or not the
>>>>> secure arena gets zero’d in a child?
>>>>>
>>>>> So let me phrase it this way:  does anyone object to changing the
>>>>> default so NO_ATFORK must be used to avoid the reseeding and
>>>>> other
>>>>> things we might add later?
>>>>
>>>> I can hardly see anyone would be broken if the default is to reseed
>>>> RNG on fork. However that might not be true for other atfork
>>>> functionalities so perhaps there is a need to make each of these
>>>> future
>>>> atfork functions configurable and either on or off by default
>>>> individually and not as a whole.
>>>
>>> There might be cases where after fork you're not able to get to
>>> /dev/urandom anymore.
>>
>> I do not think so. Which particular cases do you have on mind? Yes,
>> after fork+exec you could for example switch SELinux domain and won't
>> be able to access something but immediately after fork it should not be
>> so. Also perhaps the reseeding after fork can be made less strict in
>> regards to failures reading /dev/urandom or so.
>
> It seems to me this all depends on the order of things you do to
> create a daemon. You could make sure the RNG is inited, chroot,
> and then fork for instance. And I suspect there are actually
> programs that do it in that order.

The problem with /dev/urandom will go away sooner or later. All major
platforms either have a CPRNG syscall for years or introduced one
recently. BSD has getentropy(2) for a while, Windows has
CryptGenRandom() and Linux has getrandom(2) since Kernel 3.2 and glibc 2.15.

Christian
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Work on a new RNG for OpenSSL

OpenSSL - Dev mailing list
 
    The problem with /dev/urandom will go away sooner or later. All major
    platforms either have a CPRNG syscall for years or introduced one
    recently. BSD has getentropy(2) for a while, Windows has
    CryptGenRandom() and Linux has getrandom(2) since Kernel 3.2 and glibc 2.15.
   

Agreed.

And when we can make –with-rand-seed=syscall the default, then it will be  a happier place ☺

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
123