Feeding /dev/random
Author
Hi. I have a program which tries to read from /dev/random much more quickly than the machine can generate entropy. Until I invest in a hardware RNG, I want to harness the entropy pools from multiple machines.
I want to run a daemon which will read /dev/random from other machines, what Linux API call should I use to add this data to the kernel's entropy pool?
Anyway, if you have high grade entropy and want to inject it into the pool, just write to /dev/random. Note that you can only write 'cat /proc/sys/kernel/random/poolsize' bytes.
Seconding the suggestion to use /dev/urandom. If your program eats that much high quality entropy, you're doing something wrong.
If you really need that much entropy, EDG might be work better than your kernel's built-in support (or if you need to port to other platforms).
Quote:Original post by Valderman
Seconding the suggestion to use /dev/urandom. If your program eats that much high quality entropy, you're doing something wrong.
Urandom provides only pseudorandom numbers, those are not suitable for "secure" encryption. Sometimes you simply need to use raw.
Quote:Original post by tori
Urandom provides only pseudorandom numbers, those are not suitable for "secure" encryption. Sometimes you simply need to use raw.
There exist cryptographically secure PRNGs.
And /dev/urandom is only pseudorandom if an entropy source is not available. It's supposed to be the interface to "real" random numbers when the system is capable of providing them. (/dev/random is always just a PRNG.)
Quote:Original post by ZahlmanMy understanding is that on linux, /dev/random is the true random number generator, and /dev/urandom uses /dev/random to feed a PRNG, which allows it to generate even while /dev/random buffers (at the expense of some entropy).
And /dev/urandom is only pseudorandom if an entropy source is not available. It's supposed to be the interface to "real" random numbers when the system is capable of providing them. (/dev/random is always just a PRNG.)
On BSD and the like, /dev/random is always a PRNG, and you must use EDG instead for entropy.
Also worth noting is that if your entropy is low, a well-designed PRNG can produce better randomness than /dev/random.
Weird.
But then, Linux likes to give you incredibly good timing accuracy with the one timing function intended to tell humans what time it is (gettimeofday()) and incredibly bad timing accuracy with all the others (including the ones that are explicitly documented as being intended for performance benchmarking), so I guess I shouldn't be surprised. (Or at least, it was like that back in '03 when I was doing my undergrad thesis.)
But then, Linux likes to give you incredibly good timing accuracy with the one timing function intended to tell humans what time it is (gettimeofday()) and incredibly bad timing accuracy with all the others (including the ones that are explicitly documented as being intended for performance benchmarking), so I guess I shouldn't be surprised. (Or at least, it was like that back in '03 when I was doing my undergrad thesis.)
Quote:Original post by toriAs someone pointed out, there are several PRNGs that are secure enough for cryptographic purposes. The case where you actually need a massive amount of high quality entropy is rare, even when you think you do. Far better in most cases to just seed a cryptographically secure PRNG with some high quality entropy.Quote:Original post by Valderman
Seconding the suggestion to use /dev/urandom. If your program eats that much high quality entropy, you're doing something wrong.
Urandom provides only pseudorandom numbers, those are not suitable for "secure" encryption. Sometimes you simply need to use raw.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement