Hacker News Reader

Comment by polarix | Hacker News Reader

Have people talked about using sensor device input as prng seeds? onboard microphone, fan speed jitter, etc?

Yes. People have even experimented with using CPU specific instabilities in certain operations to extract entropy.

http://www.irisa.fr/caps/projects/hipsor/misc.php#exectime

The problem with such systems is that is generally quite difficult to have confidence that they are not subject to attacks that may starve the system of entropy or trick the entropy estimator into thinking it has any when it has none.

Low-level hardware RNGs can be constructed in ways that make them quite difficult to attack externally, but are also basically impossible for us to verify.

Really it seems that the best approach is to take a wide range of flexible entropy sources and to learn to trust our mixing pools and trapdoor functions.

> The problem with such systems is that is generally quite difficult to have confidence that they are not subject to attacks that may starve the system of entropy or trick the entropy estimator into thinking it has any when it has none.

That's why you give up on estimating entropy. It's just not possible in the general case.

Mix multiple sources of potential entropy in a secure fashion (e.g. with a crypographically-secure hashing function). Recover over time from a compromise.

> Really it seems that the best approach is to take a wide range of flexible entropy sources and to learn to trust our mixing pools and trapdoor functions.

Yup, you're exactly right. Now we just need to convince Ted T'so to replace Linux's hacky /dev/random with a Fortuna-based one.

You need some degree of entropy estimation at initialisation time or early boot numbers are predictable.

That seems to me the right kind of solution.

Hardware devices from big companies are categorically untrustworthy, because of these companies' history of cooperating with surveillance, their incentives to sell out users, and the inability of users to verify what's going on in the devices.

The answer is something that's verifiable - and that means precisely a no-code, low-tech source of entropy, plus a means of translating fluctuations into bits, the latter being "open" enough to enable users to confirm exactly what it does.

And thanks, it's funny to think of putting a microphone in a colo server and using the roar of all the nearby fans and occasional voices as a source of random bits.

Yes, Linux already does it iirc.

You have to install a utility to do it, but yeah. The problem is ambient noise isn't that random in say, a data centre - it works better in a noisy environment like an office where you have people doing fairly random things rather then a whole bunch of oscillating fans.

I'd wager machine room fan noise has at last as much entropy, since office sounds are pretty structured and usually mostly quiet. In any case there's a significant amount of noise from the a/d conversion even when recording a predictable sound.

What utility is it?

On Ubuntu you can install the 'randomsound' package. There used to be a different one I used but I can't remember the name.

White noise is an enormous source of entropy, by definition. For example, take a stream of samples and record whether the least significant bit is 0 or 1. That'd be almost impossible to predict or influence from outside the system.

I don't want Linux sampling my microphone randomly. Other things are fair game.

I don't recall who did it, but someone once pointed a webcam at a row of several lava lamps as a source of entropy. As long as at least 75% of them were on at any given time, the image-hashing function produced unpredictably random numbers. The low quality of the camera produced some random noise all by itself.

I imagine you could do something similar with a feed of traffic on a nearby highway or blobs of cornstarch suspension on a subwoofer.

unexpectedly amused by the fact that in this case, worse hardware is better due to extra noise.

Yes, but I suspect the NSA has had the foresight to backdoor most major brands of lava lamp. Same problem as before, you can't easily verify the hardware.

That was SGI.

SGI's Lavarand [1].

[1] http://en.wikipedia.org/wiki/Lavarand

I wonder if it's practical considering bandwidth. Is it enough for most practical purposes?

Reply on news.ycombinator.com