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?

-- 
Richard Levitte   \ Spannv�gen 38, II \ [EMAIL PROTECTED]
Chairman@Stacken   \ S-168 35  BROMMA  \ T: +46-8-26 52 47
Redakteur@Stacken   \      SWEDEN       \ or +46-709-50 36 10
Procurator Odiosus Ex Infernis                -- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/
Software Engineer, Celo Communications: http://www.celocom.com/

Unsolicited commercial email is subject to an archival fee of $400.
See <http://www.stacken.kth.se/~levitte/mail/> for more info.

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to