Re: Work on a new RNG for OpenSSL

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