> Date: Sat, 6 Jan 2001 17:09:16 +0100
> From: Lutz Jaenicke <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: Random seed and possible blocking of /dev/random
>
> On Fri, Jan 05, 2001 at 09:49:56PM +0100, Richard Levitte - VMS Whacker wrote:
> > 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.
>
> I don't know how select() would act on a regular file. /dev/random
> (and/or /dev/urandom) are no regular files, so we could first call
> stat() and only continue when S_ISCHR() is true (character device).
In the environments where I'm intimately familiar with this behavior,
to wit SunOS 4.x, and a couple of BSD 4.x derivations -- nn a regular
file, select() gets immediate/continuous "data ready to be read", until
such time as EOF is reached. Whereupon it gets EOF indication -once-.
Something else appending to the file (*after* EOF has been detected)
does *NOT* result in a subsequent 'data ready' response.
> > 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
> > :-).
> Hmm, I would consider using non-blocking reads. Select() does not know
> how many bytes you intend to read, so it will return "available" if
> just one byte is there and the second byte will block. Of course we could
> read byte-per-byte...
> So we can stay with non-blocking reads, try to take the minimum defined
> (20bytes as of now) and just take what's there.
A far superior approach. With the caveat that if you don't get all that
you want the first time, you _do_ need to loop, until you get a 'would block'
indication. I've seen some _awfully_ dumb 'virtual device' implememntations
>
> > An extension to this could also be to check for more than one random
> > device...
>
> This brings me to related point. Would it make sense to define a "default"
> place to look for an egd-socket? I had several contacts with people using
> my prngd (egd replacement) that installed prngd and did expect openssl to
> magically find it. This location would need to be in a "safe" place, so
> that no normal user can fake one just handing back prepared information
> (ruling out /tmp as proposed in the egd-documentation). The only place
> would probably in /etc. I know that /var would be better (I have my sockets
> /under /var/run), but the directory structure is not portable enough.
> -> /etc/egd-socket?
> (I would not use /dev as this is for device files only (and might lead
> to trouble on Linux-2.4 not even having a real /dev directory).)
At a minimum, I'd request an 'environment variable' over-ride. Yeah, this
is in direct contrast to your 'need to be in a "safe" place' comment.
I run some systems where /etc is on (hardware-level) Read-Only media. Can't
create sockets there, obviously. The only writable space is under /home,
/var, and /tmp. Sockets and named pipes end up under /var, mostly -- a few
are in sub-directories under /tmp.
Whatever the 'place' is, it's going to need to be major OS-type specific.
What is meaningful for UNIX isn't likely to be so for VMS, the MS world
is a whole 'nother kettle of fish. Without mention of some of the weirder
environments.
Suggest maybe a 'list' of 'typical places to look', followed by a series
of 'sanity checks' (ownership, etc.) on anything that's found. Including
checking/following symlinks. Comment: if owner is a "system" account,
-or- matches either the real or effective UID of the running code, one
probably wants to let it pass. This allows for the possibility that a
user, for their own purposes, might deliberately _want_ to have *their*own*
instance of the program using a 'predictable' random number sequence.
While preventing anybody from suberting "somebody else's" use of the
random device.
The real "wish-list" approach would be to have a _configuration-time_
utility that sniffs out the random device(s), and passes appropriate
info to the compilation process.
"list of places", plus the sanity checks, should not be much of a load --
this is one-time-use code, executed at the time the random device is first
accessed. One just keeps the file-handle open, and never have to worry
about the issue again.
>
> > Comments? Booohs? Hoorays?
> Hooray, that may reduce the unnecessary traffic on openssl-* :-)
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
