RAND_poll and the heap walk
David Miller
We are using OpenSSL to create an https connection between our Win32=20
application and an Apache web server. The application we are using generate=
s=20
a large number of HEAPENTRY32 and HEAPLIST32 structs. So many, in fact, tha=
t=20
it takes 30 seconds to establish the first https connection because we are=
=20
busy seeding the PRNG in RAND_poll().=20
=46rom looking at the list archives, I see that a few other people had a si=
milar=20
issue, and in response the code was changed to limit the number of=20
HEAPENTRY32s walked through to 80 per HEAPLIST32. Our number of HEAPLIST32s=
=20
and HEAPENTRY32s is REALLY big. So big, in fact, that even limiting the=20
HEAPENTRYs to 80 results in an unacceptable wait time (20 seconds) for the=
=20
first SSL connection to be established.
My question is this - is there a minimum number of HEAPENTRYs and HEAPLISTs=
we=20
must include in the seeding to prevent generation of weak keys? Can we redu=
ce=20
the number of HEAPENTRYs further (below the current 80) or somehow limit th=
e=20
number of HEAPLISTs we walk through in RAND_poll()?
As a test, we've eliminated the walking down the HEAPENTRY chain entirely=20
(leaving in the HEAPLIST walk), and as a result that first SSL connection i=
s=20
established MUCH faster.
Thanks in advance,
Aaron
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openss...@openssl.org
Automated List Manager majo...@openssl.org
Richard Levitte - VMS Whacker
amiller> We are using OpenSSL to create an https connection between
amiller> our Win32 application and an Apache web server. The
amiller> application we are using generates a large number of
amiller> HEAPENTRY32 and HEAPLIST32 structs. So many, in fact, that it
amiller> takes 30 seconds to establish the first https connection
amiller> because we are busy seeding the PRNG in RAND_poll().
I understand that is not really acceptable. The question is how
little data you need and still get enough entropy.
A cheak trick to get around this problem would be to get RAND_poll()
to run when the application is initialising, if that's more
acceptable. Just try to fetch 1 byte of randomness using RAND_bytes()
or something similar.
amiller> My question is this - is there a minimum number of HEAPENTRYs
amiller> and HEAPLISTs we must include in the seeding to prevent
amiller> generation of weak keys? Can we reduce the number of
amiller> HEAPENTRYs further (below the current 80) or somehow limit
amiller> the number of HEAPLISTs we walk through in RAND_poll()?
Of course you can, you have the source! :-)
Seriously, I see no real problem with limiting the number of HEAPLISTs
to traverse. If you limit it to, say, 20, just to pick a nice number,
would that be fast enough for you? That would generate a maximum of
460 bytes of entropy (according to the values given to RAND_add()),
which seems to be large enough.
An idea could be to have entrycnt start with a larger value like, say,
1024, and decrease with the number given as last argument to
RAND_add() each time RAND_add() is called, and stop the loops when
entrycnt reaches a value <= 0.
-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
--
Richard Levitte \ Tunnlandsvägen 52 \ LeV...@stacken.kth.se
Redakteur@Stacken \ S-168 36 BROMMA \ T: +46-708-26 53 44
\ SWEDEN \
Procurator Odiosus Ex Infernis -- po...@bofh.se
Member of the OpenSSL development team: http://www.openssl.org/
Unsolicited commercial email is subject to an archival fee of $400.
See <http://www.stacken.kth.se/~levitte/mail/> for more info.