[HN Gopher] OneRNG - Open Hardware Random Number Generator
___________________________________________________________________
OneRNG - Open Hardware Random Number Generator
Author : Zababa
Score : 57 points
Date : 2022-10-16 12:54 UTC (10 hours ago)
(HTM) web link (onerng.info)
(TXT) w3m dump (onerng.info)
| m463 wrote:
| There's also the infinite noise rng:
|
| https://www.crowdsupply.com/leetronics/infinite-noise-trng
| magicalhippo wrote:
| 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...
| anfractuosity wrote:
| Has anyone seen any open hardware optical RNGs out of interest,
| for high bandwidth generation?
| jnwatson wrote:
| 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.
| nullc wrote:
| 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).
| genewitch wrote:
| this is one school of thought, for sure.
| anfractuosity wrote:
| 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.
| nimbius wrote:
| 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-...
| Zababa wrote:
| 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
| hannob wrote:
| 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.
| jnwatson wrote:
| 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.
| riedel wrote:
| Most applications actually IMHO come from statistics and
| simulation. It seems PRNGs are sometimes problematic if you
| need true white noise...
| Zababa wrote:
| 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.
| Genbox wrote:
| 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
| eternityforest wrote:
| 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.
| dale_glass wrote:
| 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.
| dragontamer wrote:
| 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?
| garaetjjte wrote:
| >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.
| ur-whale wrote:
| > 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.
| adrian_b wrote:
| 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.
| jnwatson wrote:
| 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.
| kevin_thibedeau wrote:
| 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.
| Forbo wrote:
| 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.
| tonetheman wrote:
| 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
| genewitch wrote:
| 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.
| tonetheman wrote:
| Your comment is super interesting. I did not know you could
| get entropy from a dark web cam. Super cool stuff!
| ur-whale wrote:
| > 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-whale wrote:
| 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
| sbf501 wrote:
| 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.
| teddyh wrote:
| > _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 wrote:
| 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!"
| teddyh wrote:
| Too bad; I have a bunch and they work fine.
___________________________________________________________________
(page generated 2022-10-16 23:01 UTC)