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 Fri, 22 Jan 2016 19:16:41 GMT
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 <covener@gmail.com> wrote:
> 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.
>>> (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

View raw message