let Net Devices feed Entropy, updated (1/2)
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 9 lines · Richard Gooch
Quoted 8 lines · Theodore Tso
Quoted 6 lines · Martin Dalecki
The primary reson of invention of
/dev/randomwas the need for a bit of salt to the initial packet sequence number inside the networking code in linux. And for this purspose the whole/dev/*randomstuff is INDEED a gratitious overdesign. For anything else crypto related it just doesn't cut the corner.
Quoted 8 lines
Quoted 4 lines
A number of other people helped me with the design and development of the
/dev/randomdriver, including one of the primary authors of the random number generation routines in PGP 2.x and 5.0. Most folks feel that it does a good job.Indeed. If Martin has some deep insight as to why the
/dev/randomimplementation is insufficient for strong crypto, I'd like to hear it.
The only flaw I see in the random device is that its enviromental constraints are not sufficiently documented.
It is rather unreliable on boxes with no hard disk IO or
non supported hard disk IO (i.e. until recently a lot of RAID controllers didn't feed entropy) and no keyboard/mouse -- that is on a lot of appliances and servers. The box has some random pool still left over from installation, which gets smaller and smaller over runtime until urandom quickly degenerates to a not-so-great-and-slow pseudo random generator and /dev/random turns into a DoS.
It is not that they are hard to fix; e.g. a $10 sound card with a noise generating circuit on input and a small daemon to feed /dev/audio to /dev/random can do it; but few people seem to know about these problems and still trust the session key generation of their sshd (which uses /dev/urandom BTW I guess because of these problems) on their headless servers. The both SSL libraries I checked (mozilla and openssl) do not even seem to use it at all.
-Andi
Quoted 3 lines · Andi Kleen
It is not that they are hard to fix; e.g. a $10 sound card with a noise generating circuit on input and a small daemon to feed
/dev/audioto/dev/randomcan do it; but few people seem to know about
does this update the entropy count though? from previous discussions, i believe not, which iiuc means /dev/random will block just as frequently/infrequently irrespective of whether you feed stuff into /dev/random.
related: the i810 RNG has a driver, but it feeds data to /dev/random via a userspace daemon (rngd), so again entropy count is not changed.
kind of shame on the only mass-market RNG hardware out there.
regards,
Signature · 3 lines
Paul Jakma [email protected] [email protected] Key ID: 64A2FF6A Fortune: Many people are unenthusiastic about their work.
Quoted 5 lines
related: the i810 RNG has a driver, but it feeds data to
/dev/randomvia a userspace daemon (rngd), so again entropy count is not changed.kind of shame on the only mass-market RNG hardware out there.
Just tweak the daemon to update the entropy count correctly using the
appropriate ioctl function (RND_ADD_ENTROPY). Search drivers/chars/random.c for random_ioctl. I've written several programs that acquire entropy from various sources and exchange them with the kernel entropy pool. It's not difficult at all.
DS
Quoted 1 line · David Schwartz
appropriate ioctl function (
RND_ADD_ENTROPY). Searchdrivers/chars/random.c
shame on me.
it appears the i810 RNG daemon does update the entropy count.
--paulj
Quoted 10 lines · Paul Jakma
Quoted 3 lines · Andi Kleen
It is not that they are hard to fix; e.g. a $10 sound card with a noise generating circuit on input and a small daemon to feed
/dev/audioto/dev/randomcan do it; but few people seem to know aboutdoes this update the entropy count though? from previous discussions, i believe not, which iiuc means
/dev/randomwill block just as frequently/infrequently irrespective of whether you feed stuff into/dev/random.
Just writing into /dev/random feeds it, but only credits a very small amount of entropy into the store, so you need to feed a lot of data. To feed it with full accounting you need to use a special ioctl on /dev/random; e.g. using the rndfeed tool (see ftp.firstfloor.org:/pub/ak/smallsrc/rndfeed.c)
-Andi
Quoted 3 lines · Andi Kleen
It is not that they are hard to fix; e.g. a $10 sound card with a noise generating circuit on input and a small daemon to feed
/dev/audioto/dev/randomcan do it; [...]
This is a good idea, but do note that you have to be a little careful:
there are lots of ways that the result can look random enough to fool /dev/random's entropy count but be non-random enough to provide much less entropy than you'd otherwise expect (e.g., 60Hz effects, etc.).
I think it's a workable approach, and I warmly recommend using a broad diversity of entropy sources (including, e.g., soundcards), but you just have to be careful to avoid some of the pitfalls.