Integrated crypto

Robert Connolly cendres at videotron.ca
Mon Mar 29 02:37:04 PST 2004


On March 28, 2004 06:10 pm, Archaic wrote:
> On Sun, Mar 28, 2004 at 08:32:17AM -0500, Robert Connolly wrote:
> > I also found this:
> > http://www.vanheusden.com/aed/
> > Based on this:
> > http://www.mindrot.org/audio-entropyd.html
>
> Due to the fact that ost servers do not have soundcards, I'm wondering
> if we should go this route. /dev/arandom sounded like a good thing,
> though.

Most servers don't have keyboards or mice either. I've also found this:
http://www.av8n.com/turbid/paper/turbid.htm

It doesn't build, I emailed the author. But it claims to have a few methods, 
including video frame sampling, and non-pool random generation, along with 
sound card support.

Servers without keyboards and mice are almost out of sources of entropy. 
Diskless servers would be in worse shape. If this server is tunneling ipsec 
its going to be starving for entropy. Using the network as a source is not 
reliable or private, but maybe a portion of it can be reduced into seeds. The 
most robust solution would be using as many options as possible at the same 
time, and let the entropy daemon sort and reduce it. Like using keyboard, 
mouse, video frames, thermal flucuations in mainboard and sound cards, kernel 
i/o, and network jitter in combination. It should be tested as a damon, but 
would preform best inside the kernel. Some of these daemons start up a second 
entropy pool, but I don't see how that helps. I think the extra sources 
should be added to the system random.




More information about the hlfs-dev mailing list