Potential source of randomness on the systems that do not have one built in.

["Stanislav N. Vardomskiy" <stany () pet notbsd org>]

I was trying to get GNU Privacy Guard to compile on a Solaris box today.
As you might know, Solaris doesn't have /dev/random or /dev/urandom that
would be capable to provide a source of strong entropy, and consequently
random number generation or "seeding" or an encryption algorithm is
potentiall flawed due to that OS weakness.   I was surprized to find out
that GPG people have already attempted to solve that problem with EGD -
Entropy Gathering Daemon, a daemon that runs in userspace and gathers
kernel statistics  (number of packets travelling through the interface,
output of `w`, `vmstat`, etc),  using them as a source of entropy.

For a short while, when run on non-Linux/*BSD* OS, nmap was complaining
about not being able to find /dev/random or /dev/urandom, consequently the
order in which the ports were scanned was not truly random (I think I am
getting this right.  Please forgive me if I am wrong here ;-).  In a
revision or two that warning was removed due to complaints from the users,
me included. 

Now, I am wondering it it would be possible and a good idea to make `nmap`
detect the presence of EGD, and, in event that it is running, make use of
it as a source of cryptographically strong random numbers on OSes that
lack a kernel level /dev/random. 

BTW, URL for EGD is <http://www.lothar.com/tech/crypto/>


Signed:
//Stany,
System Administrator working for HIM. 
-- 
+-------+ Stanislav N Vardomskiy - Procurator Odiosus Ex Infernis[TM] +-------+
| "Backups we have; it's restores that we find tricky." Richard Letts at ASR  |
| This message is powered by JOLT!  For all the sugar and twice the caffeine. | 
+--------+ My words are my own.  LARTs are provided free of charge. +---------+