On Tue, May 16, 2000 at 02:30:51PM +0200, Bodo Moeller wrote:
> On Tue, May 16, 2000 at 09:05:16AM +0200, Lutz Jaenicke wrote:
>
> > The absolut minimum amount of seed is 16 bytes. If EGD is not drained, one
> > call to RAND_egd() will give you 255 bytes.
> > So depending on your environment you can use RAND_egd() as a replacement
> > for RAND_seed() or you can use both to collect even more entropy.
>
> > [The PRNG has 8192 state bits (1024 bytes), all calls to RAND_seed/egd()
> > or whatever functions will increase the entropy in the pool, so adding to
> > much never harms :-)]
>
> After the initial minimum seeding, one should always add at least 1024
> seed bytes (possibly of worse quality) so that the randomness pool
> gets completele 'stirred'. Use RAND_add with zero entropy count if
> your randomness source is particularly suspicious (e.g. a fixed
> 'randomness' file created at program installation).
My preferred technique of doing this is saving 1024 bytes from the old
process and read it (back) into the PRNG upon restart; then add more
entropy from EGD.
This is especially helpful when EGD is drained, because too many processes
tried to obtain entropy at the same time...
You just have to be really careful when applying this technique, e.g.
when using RAND_write(). In the case of stunnel and other wrappers,
the seed-file is opened and written with root privileges.
Just while we are at the topic: I am using EGD now for some time and
from my point of view IT SUCKS.
- I suppose EGD produces entropy of high quality.
- EGD will only deliver as much entropy as it thinks it has in its pool.
If the pool is drained, you won't get any entropy back.
It hence behaves similar to /dev/random (note the missing 'u').
- That is pretty bad if you have just one EGD running. You cannot effectively
use it when starting daemons from inetd (like stunnel or sslwrap), since
when a lot of connections come in, the pool is drained.
- The amount of computer time EGD (written in perl) cumulates is quite high.
I had a (power) user on a HP-C200 (200MHz PA-8200 CPU, 768MB main memory)
that complained that there was another process running, eating up precious
CPU time (not continously, he probably would not have noted, but in peaks).
- What we would need would be a daemon that maintains its own pool
e.g. the OpenSSL PRNG, and produces random bytes as demanded using
RAND_bytes(), hence imitating /dev/urandom (with 'u' :-).
- This daemon could either call entropy gathering subprocesses (and avoid
having the perl-overhead) or even call EGD to make things easier...
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]
