Hacker News Reader

Comment by malandrew | Hacker News Reader

Out of curiosity, why can't we just use a series of sensors on the computer to generate random numbers? Between mouse movements, touch inputs, video camera input, microphone movements, the behavior of applications in your system and how they use resources like RAM, CPU, hard-disk, listening to all the wifi + bluetooth signals around you and munging them, etc. I would imagine that there is enough entropy coming in through input and being generated by whatever the computer is doing to be able to have lots of unpredictable random numbers.

I don't know much at all about cryptography, but why aren't all the natural sources of entropy an adequate source of random numbers?

View on HN

Every time you do a Diffie-Hellman key exchange you need to generate a random number. Which includes any time you open an https connection.

A busy webserver does this much more often than it can easily generate entropy for. So you have to take shortcuts. That's where a pseudo-random number generator comes in.

This sort of thing is used, e.g. [0]. It collects entropy at a limited rate, though, so for demanding applications (SSL servers, say) you want dedicated hardware: [1], [2].

[0]: https://en.wikipedia.org/wiki/Hardware_random_number_generat...

[1]: https://en.wikipedia.org/wiki/RdRand

[2]: http://www.entropykey.co.uk/

How do those Entropy Keys work? What sort of environmental random data does it rely on for creating random bits?

Thermal noise of various kinds, usually.

(Edit: that is, the noise introduced in a circuit by the fact that it's not at absolute zero, e.g. Johnson noise. Not just gathering entropy from a temperature sensor reading or something like that.)

I'm not sure if its still that way but I know PGP used to do that on Windows 95/98. You would have to move your mouse around in a window until it generated enough entropy to generate your key. I'm pretty sure I've seen it in either ssh keygen or openssl stuff also but that might have been in a virtual machine/jail with a poor or missing /dev/random.

Also I believe that is where /dev/random might get some of its information from, but I'm not too sure.

I'm pretty much 100% sure that's how /dev/random works. Not only have I heard that multiple times, but once when I was installing arch linux or something, my computer ran out of random bits and told me I had to wait for it to get some more from the hardware. I don't think it actually asked me to play with the keyboard, but IIRC that's what it took. Letting it just sit there didn't seem to do the trick.

you're right, my friend. look up entropy. it's used in linux and windows kernels, and some processors have it implemented at a hardware level.

If you've got time for a network call, there's http://www.fourmilab.ch/hotbits/ (There's another lab somewhere measuring quantum fluctuations in a vacuum that I think also provides access to random numbers. Edit: Here it is: http://qrng.anu.edu.au/index.php)

I don't think that application behavior would be a good source of entropy, since it is, at least in theory, predictable. The others are probably good, although you need to be sure to only use the least significant bits, and make sure that the sensor doesn't have some weird behavior which makes the least significant bits predictable somehow.

If I had to hazard a guess, I'd say that this isn't often done simply because computers didn't typically have a lot of sensors until recently, and now you're likely to have a good-quality dedicated hardware random number generator built in, e.g. Intel's RDRAND instruction.

> I'd say that this isn't often done simply because computers didn't typically have a lot of sensors until recently

I thought it was done a lot, for example, in the Linux kernel: "The random number generator gathers environmental noise from device drivers and other sources into an entropy pool." [1]

[1] http://man7.org/linux/man-pages/man4/random.4.html

Indeed, although as the man page describes, /dev/random is too slow for most practical purposes. The entropy pool drains rather quickly and then the device will block while the pool refills.

I believe that, at least in Linux, ACPI thermal sensor readings are used for this purpose.

It has probably been done, but there is not much entropy in those low-precision temp readings. Linux support for ACPI is not great anyway.

Lava Lamp and camera?

Reply on news.ycombinator.com