OneRNG – Open Hardware Random Number Generator

https://onerng.info

by Zababa • 4 years ago

80 50 4 years ago

onerng.info

Zababa2• 4 years ago

A 2015 article from LWN about it: https://lwn.net/Articles/629714/

Previous discussion, with the designer in the thread (2014): https://news.ycombinator.com/item?id=8519801

teddyh2• 4 years ago

We are not aware of any other equivalent device that promotes this essential feature of security for you, the user.

Really? What about the ChaosKey? https://altusmetrum.org/ChaosKey/

humanistbot• 4 years ago

From your link: "ChaosKey is now out of production. They work great, but it took several years to sell our first production run, and shipping them from the US to other countries one at a time ended up dominating the net cost to most users. We might make more some day, but no promises!"

teddyh2• 4 years ago

Too bad; I have a bunch and they work fine.

hannob• 4 years ago

Usual caveat: Hardware RNGs don't really solve any practical problem, and are mostly based on urban legends about cryptography, e.g. the idea that you have to constantly refeed "lost" entropy in an RNG.

The issues with RNGs usually come down to lack of use of a secure RNG, bugs within the RNG or early boot time entropy. Only the third may benefit in theory from a hardware RNG, but the devices that potentially have this problem usually don't come with an USB port, so it doesn't help either.

dale_glass• 4 years ago

I remember Linux running into a bunch of issues with boot time entropy. Some things were sometimes getting stuck on boot due to that.

Also this "lost entropy" thing has long been a bane of VM servers, which could consume vast amounts of it. I think this changed fairly recently.

And lots of things have USB ports these days, including things like commercial wifi access points, routers, switches, etc. Some of those have internal ones.

dragontamer3• 4 years ago

All Intel and AMD chips come with a hardware RNG today: the RDRAND and RDSEED instructions.

RDRAND is kinda-sorta like /dev/urandom, while RDSEED is /dev/random with stronger entropy guarantees.

Linux didn't want to "trust" this hardware, for whatever reason. I guess there was that one time an AMD bug in the instruction returned all-zeros (or something similar). But as "long as the instruction is properly working", it is... well... working, lol.

But its not like its really possible to test if its working correctly.

--------

From that perspective, a hardware RNG needs to be "large" and "discrete" enough for humans to easily test and prove that its working, to create trust. Otherwise, hardware and/or firmware bugs could lead to a security problem.

EDIT: if you are at a mass produced but don't verify kinda person, then you might as well use RDSEED instructions to get her entropy. Intel/AMD probably are good enough to prevent firmware / hardware bugs. I know that VMs also have an issue here: whether or not to make RDSEED deterministic/predictable or not. Should the future RDSEED instructions be saved in a VM snapshot?

jnwatson3• 4 years ago

You can (and are required to in certain environments) test for basic failures in your hardware RNG. The AMD bug was bad not because of the bug, but because it was obvious they had no built-in-test functionality.

garaetjjte• 4 years ago

RDRAND is kinda-sorta like /dev/urandom, while RDSEED is /dev/random with stronger entropy guarantees.

/dev/urandom and /dev/random is almost the same nowadays, the only difference is that random will block after boot until enough entropy is collected, but it never "runs out" of entropy anymore.

adrian_b4• 4 years ago

Any hardware RNG that is included in a CPU or any other complex integrated circuit cannot be trusted, because it is impossible to verify that it is truly a RNG and not a pseudo-RNG that implements backdoors.

The only hardware RNGs that can be trusted are those that use an analog-digital converter (e.g. one of the ADCs included in any microcontroller, or the audio microphone input of a computer) and a discrete analog noise source, e.g. a diode or a resistor, because their components can be tested separately, to verify that they do what they claim to do.

Nevertheless, the output of the hardware RNGs provided by the Intel or AMD CPUs can be used in a reasonably secure way if the supposedly random values are never used directly, but they are passed through a cryptographic hash, e.g. SHA-256. Even SHA-1 is completely adequate for this special purpose, where collision-resistance does not matter (and it is faster than any other secure hashes in the ARM, AMD or Intel CPUs with SHA-1 instructions).

Even better, the supposedly random value could be hashed together with the timestamp read from the TSC, or just with the value of a counter incremented after generating a random number, for additional unpredictability. One can add to the hash a unique computer identifier, e.g. the MAC address of the first Ethernet interface. In this case, distinct sequences of uniformly-distributed pseudo-random numbers will continue to be produced even in computers where the hardware RNG remains stuck to a constant value, as it happened in some buggy AMD Zen models.

The hashing (with a secure hash algorithm) of the RNG output destroys any hidden structure that might have been exploitable by the designers of the hardware RNG, while preserving the uniform distribution of the random numbers.

ur-whale4• 4 years ago

for whatever reason.

For very good reasons. The circuit is opaque and vendor specific.

The OneRNG presented in the article is claimed to be verifiable, at the very least.

Intel and other chip vendors don't even bother making the claim.

JoachimS5• 4 years ago

It wasn't that RDAND wasn't trusted as source of randomness in Linux. It wasn't trusted enough to replace the whole RNG chain - with entropy collection, seed extraction and DRBG/CSPRNG. Which to me was and is perfectly reasonable.

Replacing an open source chain that can be fed with entropy from several sources and mixed together, with a black box that is hard to inspect and trust.

jnwatson3• 4 years ago

The device itself isn't useful, but the design could be incorporated into systems that need a better source of early boot time entropy. Lots of embedded systems don't such a source, though it is getting better as more SoC vendors incorporate HW RNG.

Zababa2• 4 years ago

For the full story, I was trying to reduce the boot time on my Linux system. One of the things that takes the most time is systemd-random-seed. From what I understand, it takes this long because my computer is not generating entropy fast enough, so it has to wait for a while.

The solution to fix this is to find a way to generate more entropy. The system doc on random seeds has lots of information about what you can use: https://systemd.io/RANDOM_SEEDS/.

One of the options is RDRAND, which my CPU can do. But after reading a bit about it, it seems that some people are supicious of RDRAND. I have no idea if I should too, and since it was disabled by default on my distribution, I decided to keep it of for now, as I don't really understand this subject.

At this point I wondered if any hardware RNG existed, and found the OneRNG, that seems like a cool project, so I posted it here.

This is not a recommandation to use OneRNG instead of RDRAND, I don't know enough about this domain to suggest one or another.

riedel• 4 years ago

Most applications actually IMHO come from statistics and simulation. It seems PRNGs are sometimes problematic if you need true white noise...

Genbox• 4 years ago

You are correct. However, history teaches us important lessons.

Back in the old days when cryptography was a weird concept nobody understood, we had the Linear Congruential Generator (LCG)[1] to generate pseudo random numbers. It looked random, so we used it.

Then some egghead said "give me a few outputs of your LCG and I can reverse it back to a seed"[2]. Oh damn! What do we do? The obvious solution: Reseed the RNG before you use it.

Then another egghead said "I've invented Mersenne Twister (MT). It is faster and more secure"[3]. So we switched to that. No need to reseed the RNG anymore!

But then someone said "We have broken MT. Take some numbers. Give it to this app, and it will give you the seed"[4]. And so we started to reseed the RNG again.

Today it is hash-chaining, XOR-shift and improved linear-feedback shift register algorithms.

Do you want to put your money on that we have now reached bug-free well-enough PRNGs that we no longer have fiddle with reseeding? It is a dangerous gamble. More than anything I wish we were clever enough to create robust, correctness proven and high-performance PRNGs so we could stop all this nonsense - but alas, here we are.

[1] https://academic.oup.com/comjnl/article/1/2/83/425243

[2] https://en.wikipedia.org/wiki/Marsaglia%27s_theorem

[3] http://www.math.sci.hiroshima-u.ac.jp/m-mat/MT/ARTICLES/mt.p...

[4] https://github.com/altf4/untwister

eternityforest3• 4 years ago

Xorshift, lfsr, Mersenne, and LCG were never intended to be secure as far as I know, and were never cryptographically broken because they were never secure to begin with. They discovered flaws that could bias some large scientific simulations and such in some of them.

But nobody is going to be directly using USB numbers to make billions a second for simulations, these dongles are mostly meant for cryptographically secure stuff.

Their competition is whatever algorithms Linux urandom snd OpenSSL are using at the moment, and the builtin RNGs most chips have had for a decade.

CSPRNGs are occasional broken, but it seems to happen about as often as other crypto primitives. They are based on hashes and ciphers usually, and these days those can go for decades without much progress on a break.

Unless P==NP or something happens and ruins all the fun, I'm fine with current crypto prngs. I don't think I've ever handled data that was so critical that anything else was needed.

kevin_thibedeau• 4 years ago

They have applications beyond cryptography. One use case is to generate a unique random ID at startup. You can't do that without some sort of entropy source.

JoachimS5• 4 years ago

In many embedded systems and constrained devices, there is a lack of proper randomness. And often the system environment is too stable to use as source of entropy (by connecting a sensor). This makes it hard to set up secure sessions.

If fairness, more and more MCUs (esp based on ARM Cortex) that contain some sort of TRNG / entropy source. Some of them have fairly good quality too. But there are still tons of 8051-based MCUs that lack any source of randomness. Having a cheap, physically compact, low power source of entropy that can be attached is in these cases quite useful. Esp for securing systems already in use.

anfractuosity2• 4 years ago

Has anyone seen any open hardware optical RNGs out of interest, for high bandwidth generation?

jnwatson3• 4 years ago

There isn't a good reason for high bandwidth hardware RNG. You seed a PRNG with a slow HW RNG and you're good to go.

genewitch3• 4 years ago

this is one school of thought, for sure.

nullc• 4 years ago

A reason is if you're using a scheme that has information theoretic security, rather than computational, when instantiated with a TRNG.

Hopefully adequately built computational security is sufficient for any purpose, but this is a certificational difference-- hopefully not one in practice but potentially one in the kind of guarantees that you can give. (E.g. you can't prove that someone doesn't secretly know how to invert a HMAC-DRBG to get its state given a large chunk of its output)

It would be pretty foolish to use a IT security scheme just to destroy the property by using a DRBG to source its random numbers.

That said, since TRNGs are mostly interesting to snake oil drinkers there is good reason to expect most TRNG to be poorly constructed. (E.g. it's really common to see then dropping output based on a NIST SP 800-22, thus technically resulting in a biased output).

anfractuosity2• 4 years ago

I'm mostly interested in optical HWRNGs from a curiosity about the single photon emitter, was just skimming a paper which seemed to indicate you can make one from a std. LED, which seemed very cool to me.

tonetheman2• 4 years ago

This was mentioned somewhere on the site and it is abandoned but it seems like a great way to get some entropy also. From a software radio dongle.

https://github.com/pwarren/rtl-entropy

genewitch3• 4 years ago

I've used randio and rtl-entropy, and they work okay, but there's some - possibly legitimate - concerns that even a shielded device can be made to output arbitrary [enough] bits from a concentrated attack, should an adversary know you're using that for entropy.

As far as generation, old webcams sealed inside of coffee cans painted as dark as possible on the inside, and then sealed to ensure no light gets in, can be used to generate bits pretty quickly.

I haven't had time or inclination to mess with avalanching diodes/transistors/resistors to verify the randomness and immunity to environment, but i have used the above methods to test their entropy, and used it to generate One Time Pads. As per my HN profile, i used to be very into entropy research and methods; but lately my home - and homestead - life take up most of my time.

and RDRAND et al use thermals from the dark silicon to generate ~1mhz of entropy (as of 2018,) which should be sufficient for practically any normal usage of entropy. A hardware entropy / RNG should only be needed if you are running something like a "lottery", you still need a verifiable "whitener", and you never touch "CSRNG" or "PRNG" anywhere.

tonetheman2• 4 years ago

Your comment is super interesting. I did not know you could get entropy from a dark web cam. Super cool stuff!

m463• 4 years ago

There's also the infinite noise rng:

https://www.crowdsupply.com/leetronics/infinite-noise-trng

magicalhippo• 4 years ago

One key difference (at least for some) is that the Infinite Noise project uses a completely hardware-defined USB chip[1], which has been decapped. Thus you could in theory buy a batch, decap a random selection and visually inspect to verify that it matches the reference.

The OneRNG uses a more regular SoC, which is theoretically susceptible to supply chain issues like fakes or deliberate tampering. To their credit, they do mention this:

There is one complex chip on the OneRNG which cannot be verified by eye. The CC2531 SoC (from Texas Instruments) is small, and it is theoretically possible that the chip fitted to your device has been tampered with or even been outright substituted for an alternative before you received your device.

[1] https://www.crowdsupply.com/13-37/infinite-noise-trng/update...

sbf501• 4 years ago

I don't see a FIPS certification for it? I mean, at least show us some NIST 800-22 results. We already have a DRBG RFC to account for poor-entropy systems that has considerable research behind it. This seems pointless.

Forbo• 4 years ago

I've got an FST-01 that I've been meaning to set up with NeuG as a hobby project. Not sure if it would be worthwhile or if I would be better served spending my time on something else.

ur-whale4• 4 years ago

primarily from an avalanche diode circuit,

Unfortunately, these diodes in avalanche mode degrade over time and it is unclear how stable the quality of the entropy derived from this analog circuit is over long periods of time.

ur-whale4• 4 years ago

One of my favorite technique for building a hardware RNG uses a cheapo FPGA circuit (something like this: https://www.aliexpress.com/item/32241350256.html?spm=a2g0o.p...) with a bunch of free-running high-frequency oscillators called ring oscillators (basically loops of NOT gates, which have a lot of phase noise, especially if they run hot) that are sampled at constant frequency.

The entropy isn't very "clean" (lots of auto-correlation), but it's unpredictable enough to seed a crypto hard RNG which can also be built into the FPGA and operate at very high speed.

It's also an increasing PITA to convince synthesis tools to actually emit ring oscillators, which they consider to be a design bug (which they almost always are, except in this specific case), but it's still possible.

[EDIT]: a quick search on github yields:

https://github.com/stnolting/neoTRNG

https://github.com/Netnod/rosc_entropy

JoachimS5• 4 years ago

I was going to say that this is what we used as one of two entropy sources [0] in the Cryptech HSM. But the second link there is the fork of the Cryptech rosc entropy source we did for the FPGA based NTS server. ;-)

The TRNG in the Tillitis Key 1 (TK1) we released a couple of weeks ago contain a version of the rosc entropy source. But I have now included a VN-decorrelator. And the actual oscillators are much simpler, cleaner.

[0] The other entropy source in cryptech is an avalanche noise source outside of the FPGA. Both sources can be found here:

https://git.cryptech.is/core/rng/avalanche_entropy/ https://git.cryptech.is/core/rng/rosc_entropy/

The complete TRNG samples both sources (round robin) and creates a seed using SHA-512, with previous seed a part of the input. The seed is then used to initialize ChaCha20 as CSPRNG:

https://git.cryptech.is/core/rng/trng/

ur-whale4• 4 years ago

But I have now included a VN-decorrelator

Yeah, but Von-Neuman decorrelators have one major drawback: their throughput is unpredictable.

nimbius• 4 years ago

for those interested, you can do the same thing with a $20 usb dtv receiver and rngd using the rtl-sdr entropy project

http://blog.cros13.net/2014/08/cheap-entropy-using-your-rtl-...

Geee• 4 years ago

The chip itself isn't verifiable, like the document says. It's possible that there's a backdoor. It's not likely, but it's not verifiable and you'll have to trust it.

JoachimS5• 4 years ago

Given a suitable app, the Tillitis Key 1 works as a RNG. I have written a first version, and will release one in the public app repository in a week or so.

https://github.com/tillitis/tillitis-key1

https://github.com/tillitis/tillitis-key1-apps

OneRNG – Open Hardware Random Number Generator

Related Stories