6 ms·

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

by polarix 13y ago

Keyframe 13y ago
I wonder if it's practical considering bandwidth. Is it enough for most practical purposes?
BCM43 13y ago
Yes, Linux already does it iirc.
- XorNot 13y ago
  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.
  - zurn 13y ago
    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.
  - ingenium 13y ago
    What utility is it?
    - XorNot 13y ago
      On Ubuntu you can install the 'randomsound' package. There used to be a different one I used but I can't remember the name.
  - kstrauser 13y ago
    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.
ds9 13y ago
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.
drzaiusapelord 13y ago
I don't want Linux sampling my microphone randomly. Other things are fair game.
- logfromblammo 13y ago
  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.
  - MAGZine 13y ago
    unexpectedly amused by the fact that in this case, worse hardware is better due to extra noise.
  - cobbal 13y ago
    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.
  - gaius 13y ago
    That was SGI.
  - jfb 13y ago
    SGI's Lavarand [1]. [1] http://en.wikipedia.org/wiki/Lavarand http://en.wikipedia.org/wiki/Lavarand
__alexs 13y ago
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 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.
- wtbob 13y ago
  > 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.
  - __alexs 13y ago
    You need some degree of entropy estimation at initialisation time or early boot numbers are predictable.

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

by polarix 13y ago

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

Keyframe 13y ago

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

BCM43 13y ago

Yes, Linux already does it iirc.

XorNot 13y ago
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.
- zurn 13y ago
  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.
- ingenium 13y ago
  What utility is it?
  - XorNot 13y ago
    On Ubuntu you can install the 'randomsound' package. There used to be a different one I used but I can't remember the name.
- kstrauser 13y ago
  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.

ds9 13y ago

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.

drzaiusapelord 13y ago

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

logfromblammo 13y ago
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.
- MAGZine 13y ago
  unexpectedly amused by the fact that in this case, worse hardware is better due to extra noise.
- cobbal 13y ago
  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.
- gaius 13y ago
  That was SGI.
- jfb 13y ago
  SGI's Lavarand [1]. [1] http://en.wikipedia.org/wiki/Lavarand http://en.wikipedia.org/wiki/Lavarand

__alexs 13y ago

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 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.

wtbob 13y ago
> 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.
- __alexs 13y ago
  You need some degree of entropy estimation at initialisation time or early boot numbers are predictable.