OneRNG -USB connected entropy generator with open source hardware+software

[d4rkcat]

OneRNG is a small USB device that generates high quality entropy from two sources, an avalanche diode and an RF receiver.

The device cannot be flashed through the USB port, which means a compromised machine cannot flash it.
There is a dedicated programming port on the board, the equipment needed to re flash it with your own software is available from the same people that make it at cost.

Everything is open source, the hardware and software.
Even the schematics for the circuit boards are available, so if you want you can physically inspect the device to make sure it hasn't been messed with at any point.

I think this looks great, I already have a Yubikey, but this is much better because it cannot be flashed from the USB.

Website
Kickstarter Page
The Register Article
/r/netsec comments

[MainStream]

This looks very interesting. I'm going to go ahead and do some more research on it. Thanks for the share.

[Kulverstukas]

So.... it generates random numbers. What use is that?

[proxx]

So.... it generates random numbers. What use is that?

Since computed encryption mech. rely on entropy and this is not perse a trusted source the concept of 'external' entropy was introduced. (correct me if I'm wrong)

[d4rkcat]

So.... it generates random numbers. What use is that?

Wut?
All encryption rely on random numbers, if you can predict the some of the random, you can compromise the encryption.
Encryption is more often broken by bypassing it, not penetrating it.
This is an essential device it produces a vast amount more random per second than /dev/random.

[kenjoe41]

So we should make /dev/random generate faster and drain it just as much.

[d4rkcat]

So we should make /dev/random generate faster and drain it just as much.

I'm sorry I don't understand the comment/question.
But /dev/random cannot generate faster as far as I understand.
From the website:

OS Random Number Sources

Sticking with the example of Linux, /dev/random provides random numbers by directly hashing the internal entropy pool. Each use of /dev/random depletes the data available, and if the entropy sources cannot deliver sufficient data, your request to read /dev/random will block - it will wait until more entropy is available.

For almost every normal task, you are supposed to instead use /dev/urandom. This interface internally does exactly the same as /dev/random, except that when the entropy pool is close to exhaustion it will instead start to deliver data from a software device, a PRNG that has been seeded from 'good' random data.

If you use the OneRNG to populate Linux's entropy pool data directly, both systems are "improved" - high-quality reads from /dev/random will not block (unless you are exceptionally greedy), and /dev/urandom will not need to fall back to PRNGs.

Also the whole issue hear is trusting that the entropy from your internal components has not been backdoored in any way. With this device you don't have to.

[kenjoe41]

Good thing is that the whole project is open source otherwise i would still not trust a HW RNG to be precise and not be tampered with.
Talking about randomness, i loved this article: hackaday.com/2014/12/19/nist-randomness-beacon/

[d4rkcat]

Good thing is that the whole project is open source otherwise i would still not trust a HW RNG to be precise and not be tampered with.
Talking about randomness, i loved this article: hackaday.com/2014/12/19/nist-randomness-beacon/

Interesting article, Thanks for the share.