Live data from Hacker News

OneRNG – Open Hardware Random Number Generator

onerng.info

61–70 of 89 posts

Re: OneRNG – Open Hardware Random Number Generator

#61
post #27

Earlier quoted context omitted.

actually it is a reverse biased transistor

Aha cool, is the schematic online?

Every TRNG I've seen so far that uses "zener noise" is actually using the reverse breakdown voltage across the emitter-base junction of a cheap NPN transistor. This is a zener diode! The reason this form of zener is used is simply because the fab does not bother to put in any effort to reduce the avalanche noise. Noise like that makes zeners sold as zeners unpopular.

Zener avalanche noise is unpredictable. How is an attacker supposed to guess when the next electron/hole pair is going to be created in the depletion region? Physically, what happens is the emitter-base junction is reverse biased, turning it into a diode that is blocking current from flowing from the emitter to the base. Every once in a while, due to thermal noise and likely quantum effects, an electron jumps up a valence level, creating an electron/hole pair in the middle of the reversed-biased N/P junction, where there is a strong electric field. This launches the electron in one direction and the hole in the other, where they gain speed rapidly. The electron has higher mobility and will gain enough speed to bang into other electron/hole pairs, creating an avalanche of electrons.

There is no known way for anyone to guess when the next avalanche will occur, or how large it will be, so long as there is no outside signal controlling this effect. Implemented poorly, it can just put out power supply noise, and not true unpredictable entropy. Implemented well, it is a solid, reliable, cheap, and fast entropy source. It is absolutely critical that a zener noise TRNG has an open auditable design!

As for "quantum" effects, I consider that marketing fluff. What we need is provable, reliable unpredictability, not some radioactive decay or photon emission. We don't need 100% unbiased unpredictability either, just a signal that cannot be predicted with much accuracy.

Re: OneRNG – Open Hardware Random Number Generator

#62

Or you could just use a shitty cheap webcam and take the lower bits of each pixel (or one pixel of each 8x8 block if the compression is bad). The amount of randomness per second webcams generate is pretty insane, it's more than enough to feed the seed of a crypto PRNG function like Fortuna.

There are plenty of decent sources of entropy, like webcams and sound cards. However, they all add parts we don't need, and they don't take any care to design with security in mind. Eventually, a good open hardware TRNG should be cheaper, more reliable, easier to use, and more secure than any of those solutions, IMO.

Re: OneRNG – Open Hardware Random Number Generator

#63
post #2

That's awfully complicated for a hardware RNG. A channel-hopping receiver? The classic solution is a radiation source, which quantum mechanics says is random. http://www.fourmilab.ch/hotbits/hardware3.html

The channel hoping is just a bit of software. It costs $0.00 in additional hardware. Software complexity is a big deal in a TRNG. The KISS rule applies big-time here. The more complex the software, the more likely it is a significant flaw will be found and exploited. It remains unclear to me whether there should even be a microcontroller on a USB TRNG. Without one, we can eliminate the complexity from the USB key itself, but we have to move the whitening and health monitoring to the driver. It is unclear to me if making the driver more complex opens it up to enough additional attacks that the system is less secure overall.

Re: OneRNG – Open Hardware Random Number Generator

#64

A question for the designers (Paul?) about verifiability. In the software world you can effectively choose from 2 levels of review. You can (1) review the source code of a project and convince yourself it's fine. Or (2) you can assume/hope that experts have done that, download the software, and just verify you have an identical copy of what everyone else is reviewing. (Ideally using signatures of the authors and revi…

I'm just brainstorming here ... but couldn't your software perform a test on the expected latencies and error rates of the hardware (on a very deep level) such that any additional (or subtracted) components would alter them in obvious ways ?

Re: OneRNG – Open Hardware Random Number Generator

#65

If the avalanche diode is the main/primary source of entropy why do we need the CC2531? The super paranoid part of me is worried about the 802.15.4 radio being used as a vector to taint the RNG. Shouldn't an HW RNG NOT have any secondary communication method built in? I am guessing you guys added that because that's the platform you're working with for your IOT project, but it just seems a little overkill to me. The…

Look, I hate to be a wet blanket here, but this device cannot contain a radio.

I don't care how trustworthy everyone involved is or how closely we all look at it.

"Shouldn't an HW RNG NOT have any secondary communication method built in?"

Yes, that would indeed be a best practice.

Seriously. A radio. And not just any radio, but a software programmable, general purpose 802.x radio with a published spec, etc.

Re: OneRNG – Open Hardware Random Number Generator

#66
post #49

Earlier quoted context omitted.

Aha cool, is the schematic online?

not yet, the actual RNG circuit is pretty standard - we'll put up the eagle files, along with the software sources, before we open the kickstarter

If it's faster, could you put up a .png of the schematic?

Also, the CC2531 looks like a QFN. Does it come in any hand-solderable packages?

Re: OneRNG – Open Hardware Random Number Generator

#67
post #21

> It even has a “tinfoil hat” to prevent RF interference Isn't this a problem in the US, being against the famous part 15 of the FCC rules: «Operation is subject to the following two conditions: (1) this device may not cause harmful interference, and (2) this device must accept any interference received, including interference that may cause undesired operation.»

I'm fairly sure that the "accept" does not refer to "absorb without any countermeasures". It's a bit poorly worded. I think it refers to the fact that if your device fails due to interference below the legal limit it is your problem to fix, not the device that generated the interference.

I always assumed that it refers to the fact that interference under certain limit should not permanently destroy the device even when such interference may cause the device to behave erratically.

Re: OneRNG – Open Hardware Random Number Generator

#68

A question for the designers (Paul?) about verifiability. In the software world you can effectively choose from 2 levels of review. You can (1) review the source code of a project and convince yourself it's fine. Or (2) you can assume/hope that experts have done that, download the software, and just verify you have an identical copy of what everyone else is reviewing. (Ideally using signatures of the authors and revi…

the simple answer is that we publish our schematics and layout, just like software

More generally, this is a pretty simple circuit the whole thing fits on a page (and we have a bit by bit explanation of how it works) looking it over is a 5 minute job, the firmware is far more complex.

Re: OneRNG – Open Hardware Random Number Generator

#69
post #2

That's awfully complicated for a hardware RNG. A channel-hopping receiver? The classic solution is a radiation source, which quantum mechanics says is random. http://www.fourmilab.ch/hotbits/hardware3.html

The channel hoping is just a bit of software. It costs $0.00 in additional hardware. Software complexity is a big deal in a TRNG. The KISS rule applies big-time here. The more complex the software, the more likely it is a significant flaw will be found and exploited. It remains unclear to me whether there should even be a microcontroller on a USB TRNG. Without one, we can eliminate the complexity from the USB key its…

[deleted]

Re: OneRNG – Open Hardware Random Number Generator

#70
post #46

Earlier quoted context omitted.

I think that's a fair point, I agonized over it for quite a while - the cc2531 was the USB device/ and stack I was building with at the time. This is the main reason why by default the device disables the RF source, you have to go out of your way to enable it by editing an /etc .conf file - however it actually does make a slightly better random stream

Is it possible for this device to transmit over radio, or only receive? I certainly prefer only being able to receive, as transmitting seems like an attack vector. With the assumption that it only receives, I would strongly prefer that it be left on by default. Adding a second source to the CRC mixing can only improve entropy, even if the source is controlled by an attacker. Since the noise from the zener has no simp…

It could transmit, there is no transmit code in the firmware, in fact there's no real receive code, we turn on the receiver and sample the LSB of RF noise in the sampling DACs but don't enable any demodulation or framing.

Turning both RNGs on only gets you a about half a bit/byte of extra entropy - but it is a great belt and braces sort of thing, makes it much harder to attack, especially since the sampling clock inside the device for both sources is not visible eternally

Remember we don't use the output data directly, we mix it into the kernel's entropy pool (where it's whitened)

Post reply on HN