I got to wonder a little about our seeding mechanism and the
possibility of /dev/random blocking when getting overwhelmed.
The thought trailed on to reads with a timeout, and the question if
and how a select() with a file descriptor pointing at a file or a
random device does actually react.

If select() is useable before read() for a standard file, then it
would perhaps be possible to use possibly blocking devices like
/dev/random and still not get impatient developpers on our throats
:-).

Of course, that does also mean we need to change other things in
RAND_poll() as well, like using a file descriptor instead of a
FILE stream...  and will also lead to platform-specific code.
However, unless it is unsafe to use /dev/random for other reasons,
perhaps this is something to consider.

An extension to this could also be to check for more than one random
device...

Comments?  Booohs?  Hoorays?

BTW, while looking around a little, I saw a reference to
/dev/srandom.  Anyone know what's special with that device?

-- 
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