apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Covener <cove...@gmail.com>
Subject Re: ap_init_rng / apr_random question
Date Sun, 01 Nov 2015 15:20:04 GMT
On Tue, Oct 27, 2015 at 8:00 PM, Yann Ylavic <ylavic.dev@gmail.com> wrote:
> On Tue, Oct 27, 2015 at 6:57 PM, Eric Covener <covener@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)

Mime
View raw message