On Tue, Sep 12, 2000 at 11:26:51AM -0400, Jeffrey Altman wrote:
[Detailed description of Windows HEAP properties deleted]
> > I understand that the problem seems to be caused mostly by the behaviour
> > of RAND_status(), as it implicitly calls RAND_poll(), when used for the
> > first time. The same will happen also when first calling RAND_bytes().
> > While on UNIX this is cheap (it does cost an access to /dev/urandom, if
> > available), it is very expensive on Windows.
>
> What you are saying is that RAND_status() is going to call RAND_poll()
> regardless of whether or not the PRNG has been seeded. In other
> words, you are saying that you do not trust (and I don't really blame
> you) the application author to know how to see the PRNG.
That is my analysis of how the internals work. See below.
> > If I didn't misunderstand the source, there is no way to work around
> > this problem as of 0.9.6. As the "initialized" flag will only be set
> > in ssleay_rand_bytes() and ssleay_rand_status() after RAND_poll()
> > has been called, even _after_ feeding the PRNG explicitly with
> > RAND_add(). So even correct seeding does not help, the delay will
> > always be there. My recommondation would be at least that
> > RAND_poll() is only called when there has not yet been enough
> > entropy added via RAND_add().
>
> I agree 100% with this. RAND_poll() should only be called if proper
> seeding has not been done. Perhaps you can add a function that allows
> the knowledgeable application designer to set the "initialized" flag
> when the work has been done. That way you can still perform proper
> seeding when the programmer simply called RAND_add() with a fixed
> string in order to work around the error.
We are facing a design decision here:
1 There are people using the OpenSSL library who don't care about the correct
seeding of the PRNG. They see that the data on the wire is encrypted and
cannot be read by them. An encryption based on these weak key is probably
good enough for the average student/colleague/sysadmin who can sniff your
packets but does not have the knowledge or time on how to break this keys.
And to be fair, this should cover 99% of all cases.
2 Assumption 1 holds as long as there is no "automated tool" available for
script kiddies which could perform the break for them.
3 For a good cryptographic software on which people can rely, this is not good
enough, so the status of the PRNG seeding is checked an RAND_bytes() will
fail if not seeded correctly (as of 0.9.5).
4 Since a lot of people falling into category 1 proposed "snake oil" seeding,
calling RAND_poll() in any case is a consequent decision. Unfortunately,
on Windows it does have a nasty side effect of consuming time (on UNIX it
is a no-cost option, so nobody is hurt).
5 It is not important if people seed with a fixed string or if you allow
access to the "initialized" flag (which would also have side effects).
The result is the same. People can and will work around the PRNG-needs-seed
problem and use bad seeding.
Now, we can discuss whether the design decision is a good one, and with the
side effect given on windows (a startup time of a client of 1 minute as you
described is not acceptable) I think that it will be reconsidered.
Best regards,
Lutz
--
Lutz Jaenicke [EMAIL PROTECTED]
BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
