<font size=2 face="sans-serif">The bad case I'm aware of is the fork()
one as it's critical that the RNG state diverge on fork(). Without that
you can get some very nasty behaviour in things like TLS servers. Some
of which have a thread pool + fork() model to handle increasing load.</font><br><br><font size=2 face="sans-serif">While ideally you'd do a complete reseed,
just different state in each RNG is a LOT better than nothing, and even
PID + whatever else you can scrounge up will help a lot. Even the high
res counters available on most current CPU's would help there because forking
multiple processes isn't quite synchronous.</font><br><br><font size=2 face="sans-serif">I don't think 'telling the user to fix
it' is a particularly good option in these cases as in general the user
will be even less capable of dealing with this than OpenSSL. By all means
warn the users that behaviour may not be ideal, but do your best first.</font><br><br><font size=2 face="sans-serif">Peter</font><br><br><br><br><br><br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">Paul Kehrer <paul.l.kehrer@gmail.com></font><br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">"openssl-dev@openssl.org"
<openssl-dev@openssl.org></font><br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">24/08/2017 07:13</font><br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [openssl-dev]
Work on a new RNG for OpenSSL</font><br><font size=1 color=#5f5f5f face="sans-serif">Sent by:
</font><font size=1 face="sans-serif">"openssl-dev"
<openssl-dev-bounces@openssl.org></font><br><hr noshade><br><br><br><font size=2 face="Helvetica">On August 19, 2017 at 2:48:19 AM, Salz,
Rich via openssl-dev (</font><a href="mailto:openssl-dev@openssl.org"><font size=2 color=blue face="Helvetica"><u>openssl-dev@openssl.org</u></font></a><font size=2 face="Helvetica">)
wrote:</font><br><font size=2 face="Helvetica"><br>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. <br></font><br><br><font size=2 face="Helvetica">It appears the current position is that
since there will be edge cases where a reseed would fail (thus either halting
the RNG or silently not reseeding it) that we should not attempt to reseed?
I would argue it is better to attempt to reseed and document that edge
cases may need to reseed themselves. This dramatically narrows the window
from "everybody needs to do it" to "users in certain scenarios
that are becoming rarer by the day need to do it". Given that backwards
compatibility is a concern maybe failure to reseed on fork should only
drop an error on the child process's error queue though? That behavior
could potentially be a separate flag that OpenSSL uses by default (OPENSSL_TRY_TO_INIT_ATFORK),
and then OPENSSL_INIT_ATFORK can be more strict about reseed failures if
desired.</font><br><br><font size=2 face="Helvetica">-Paul</font><tt><font size=2>-- <br>openssl-dev mailing list<br>To unsubscribe: </font></tt><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=K53ZTnW2gq2IjM1tbpz7kYoHgvTfJ_aR8s4bK_o2xzY&m=fF3EsvxEsVa_Gqvi75hhE7fVtPzma348fsGdbb_GMLc&s=OhHmJAPRZokV7vWQaJy75wCYUxEWJLfAf79YJH6Mhao&e="><tt><font size=2>https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=K53ZTnW2gq2IjM1tbpz7kYoHgvTfJ_aR8s4bK_o2xzY&m=fF3EsvxEsVa_Gqvi75hhE7fVtPzma348fsGdbb_GMLc&s=OhHmJAPRZokV7vWQaJy75wCYUxEWJLfAf79YJH6Mhao&e=</font></tt></a><tt><font size=2><br></font></tt><br><br><BR>