On Tue, Sep 12, 2000 at 08:39:02AM +0200, Richard Levitte - VMS Whacker wrote:
> From: Jeffrey Altman <[EMAIL PROTECTED]>
> jaltman> Then I call RAND_status() which in turn calls RAND_poll().
> jaltman> This second time the call takes over 60 seconds. This
> jaltman> appears to be caused by the walking of the heap. Between the
> jaltman> time the RAND_screen() is called and RAND_status() is called
> jaltman> a large amount of memory is allocated (most of it
> jaltman> uninitialized at this point.)
>
> Hmm, that's quite a bit...
>
> jaltman> Do you really want to search through 14MB of data each time
> jaltman> this routine is called?
>
> Well, that actually depends on what the real issue is. I mean, this
> is likely to happen only once in the life of a program. I understand
> that if it's a client program it might start quite often. However,
> security is an issue, and in a PRNG it can be crucial. And if we're
> talking about mostly uninitialised memory, it becomes even more
> important to take a really big chunk, or all you'll get for entropy is
> a line of zeroes with perhaps a few other bits quite dispersed. Well,
> perhaps not necessarely zeroes, but the risk of getting a fairly
> well-known or easily guessable pattern can be great at that time.
>
> So, there's a choice. The trade-off seems to be between speed and
> security in this case. I'm not sure what would be the exact right
> choice here, perhaps someone else does?
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.
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().
There would be another way in simply not using implicit seeding at all and have
RAND_status() and RAND_bytes() do what it should in this case: fail.
But this of course would further increase the amount of confused people on the
mailing list asking for the PRNG not seeded problem :-(
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]
