You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Eric Covener <co...@gmail.com> on 2015/11/01 16:20:04 UTC
Re: ap_init_rng / apr_random question
On Tue, Oct 27, 2015 at 8:00 PM, Yann Ylavic <yl...@gmail.com> wrote:
> On Tue, Oct 27, 2015 at 6:57 PM, Eric Covener <co...@gmail.com> wrote:
>> IIUC, it takes something like 32k of /dev/random to initialize apr_random.
>>
>> APR_RANDOM_DEFAULT_POOLS*APR_RANDOM_DEFAULT_RESEED_SIZE*APR_RANDOM_DEFAULT_G_FOR_INSECURE
>> (32*32*32)
>>
>> But ap_init_rng() does this with ~4000 8-byte reads of /dev/random.
>>
>> I am working on a platform where access to the crypto facility
>> underneath /dev/random is sometimes audited. Does anyone have any
>> hints about whether larger reads from /dev/random would be better
>> elsewhere? Or if the startup requirement is really this high for data
>> from /dev/random?
>
> AFAICT, /dev/urandom itself only requires 256 bits (32 bytes) of
> (secret) entropy to be secure (cryptographically strong), so I don't
> think more would be needed for httpd (or APR).
> It seems to me that asking for more than 32 bytes of random bytes by
> something like a minute is not very sound (both for the requester AND
> the "others"), so IMHO we should really take that into consideration.
Adding Ben directly (sorry Ben). Ben, you might recall the APR PRNG
http://svn.apache.org/viewvc/apr/apr/trunk/random/unix/apr_random.c?view=log
We noticed it is awfully /dev/random hungry at startup because the
bytes fed to it (AFAICT) get sprayed across 32 pools that need to be
reseeded 32 times each to be able to reach 32 generations to flip over
to being ready to provide insecure bytes. I'm wondering if any of
those factors is somehow inadvertent or if there's any other light you
can shed on it (defaults optimized for hypothetical daemon mode, etc)
(My original report was exacerbated by httpd feeding in entropy 8
bytes at a time)
Re: ap_init_rng / apr_random question
Posted by Eric Covener <co...@gmail.com>.
Maybe another topic for 1.6. Is it wise to keep this code around?
On Sun, Nov 1, 2015 at 10:20 AM, Eric Covener <co...@gmail.com> wrote:
> On Tue, Oct 27, 2015 at 8:00 PM, Yann Ylavic <yl...@gmail.com> wrote:
>> On Tue, Oct 27, 2015 at 6:57 PM, Eric Covener <co...@gmail.com> wrote:
>>> IIUC, it takes something like 32k of /dev/random to initialize apr_random.
>>>
>>> APR_RANDOM_DEFAULT_POOLS*APR_RANDOM_DEFAULT_RESEED_SIZE*APR_RANDOM_DEFAULT_G_FOR_INSECURE
>>> (32*32*32)
>>>
>>> But ap_init_rng() does this with ~4000 8-byte reads of /dev/random.
>>>
>>> I am working on a platform where access to the crypto facility
>>> underneath /dev/random is sometimes audited. Does anyone have any
>>> hints about whether larger reads from /dev/random would be better
>>> elsewhere? Or if the startup requirement is really this high for data
>>> from /dev/random?
>>
>> AFAICT, /dev/urandom itself only requires 256 bits (32 bytes) of
>> (secret) entropy to be secure (cryptographically strong), so I don't
>> think more would be needed for httpd (or APR).
>> It seems to me that asking for more than 32 bytes of random bytes by
>> something like a minute is not very sound (both for the requester AND
>> the "others"), so IMHO we should really take that into consideration.
>
> Adding Ben directly (sorry Ben). Ben, you might recall the APR PRNG
> http://svn.apache.org/viewvc/apr/apr/trunk/random/unix/apr_random.c?view=log
>
> We noticed it is awfully /dev/random hungry at startup because the
> bytes fed to it (AFAICT) get sprayed across 32 pools that need to be
> reseeded 32 times each to be able to reach 32 generations to flip over
> to being ready to provide insecure bytes. I'm wondering if any of
> those factors is somehow inadvertent or if there's any other light you
> can shed on it (defaults optimized for hypothetical daemon mode, etc)
>
> (My original report was exacerbated by httpd feeding in entropy 8
> bytes at a time)
--
Eric Covener
covener@gmail.com
Re: ap_init_rng / apr_random question
Posted by Eric Covener <co...@gmail.com>.
Maybe another topic for 1.6. Is it wise to keep this code around?
On Sun, Nov 1, 2015 at 10:20 AM, Eric Covener <co...@gmail.com> wrote:
> On Tue, Oct 27, 2015 at 8:00 PM, Yann Ylavic <yl...@gmail.com> wrote:
>> On Tue, Oct 27, 2015 at 6:57 PM, Eric Covener <co...@gmail.com> wrote:
>>> IIUC, it takes something like 32k of /dev/random to initialize apr_random.
>>>
>>> APR_RANDOM_DEFAULT_POOLS*APR_RANDOM_DEFAULT_RESEED_SIZE*APR_RANDOM_DEFAULT_G_FOR_INSECURE
>>> (32*32*32)
>>>
>>> But ap_init_rng() does this with ~4000 8-byte reads of /dev/random.
>>>
>>> I am working on a platform where access to the crypto facility
>>> underneath /dev/random is sometimes audited. Does anyone have any
>>> hints about whether larger reads from /dev/random would be better
>>> elsewhere? Or if the startup requirement is really this high for data
>>> from /dev/random?
>>
>> AFAICT, /dev/urandom itself only requires 256 bits (32 bytes) of
>> (secret) entropy to be secure (cryptographically strong), so I don't
>> think more would be needed for httpd (or APR).
>> It seems to me that asking for more than 32 bytes of random bytes by
>> something like a minute is not very sound (both for the requester AND
>> the "others"), so IMHO we should really take that into consideration.
>
> Adding Ben directly (sorry Ben). Ben, you might recall the APR PRNG
> http://svn.apache.org/viewvc/apr/apr/trunk/random/unix/apr_random.c?view=log
>
> We noticed it is awfully /dev/random hungry at startup because the
> bytes fed to it (AFAICT) get sprayed across 32 pools that need to be
> reseeded 32 times each to be able to reach 32 generations to flip over
> to being ready to provide insecure bytes. I'm wondering if any of
> those factors is somehow inadvertent or if there's any other light you
> can shed on it (defaults optimized for hypothetical daemon mode, etc)
>
> (My original report was exacerbated by httpd feeding in entropy 8
> bytes at a time)
--
Eric Covener
covener@gmail.com