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 <cove...@gmail.com> wrote: > On Tue, Oct 27, 2015 at 8:00 PM, Yann Ylavic <ylavic....@gmail.com> wrote: >> On Tue, Oct 27, 2015 at 6:57 PM, Eric Covener <cove...@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 cove...@gmail.com
