Really Random Number Generator | Hacker News Reader

Really Random Number Generator

makezine.com

104 pointsaburan2867 comments

Way cool, saved for later so I can build my own!

The one reaction I have to share is neither here nor there, but there's a sentence suggesting this is great for games. The two problems you'll have applying something like this to games are 1- the bandwidth of this RNG is much slower than your laptop CPU. It'd pair very well with a game running on the Arduino you build the RNG with though. :) 2- I've done a lot of game programming, and came to the conclusion that I almost never wanted a random number stream. They cause repeats way too frequently. Every time I want "random" behavior in a game nowadays, I generally either pre-generate a set of behaviors randomly and then shuffle them (guaranteeing you see each behavior once before any repeats) or use an even uniform sampling in a cycle. It was a little surprising at first, but I definitely have a better appreciation now for why game mechanics with some repetition (or maybe "predictability" is a better word) are more fun than true technically 'random'.

I tend to believe "them" when "they" say that a modern CSPRNG can generate essentially infinite, random-looking noise from like a 256-bit seed-o-randomness. This device would be a great seed, on boot for example. It's also highly reliable because it simply cannot be hacked (although a truly paranoid person would also want to connect an analog oscilloscope and compare the output to what you see on your computer.)

Yes, true! Using this project for seeding a software generator is a great use, and that eliminates the point I made above about bandwidth. (As would pre-computing high-quality random number tables.)

I was confused by the "great for games" comment as well, but following the link shows that the author was thinking of simple hardware "games" such as this fortune teller consisting of LEDs and fairly simple circuitry. So I think the clock speed is more than fine for the application he had in mind...

http://makezine.com/projects/electronics-fun-and-fundamental...

Ah, in that case, my comment's nearly rude! Sorry, I had software video games in my head. :P I'm still gonna build it.

There's a whole set of issues in UX where events are perceived in ways that are not entirely mathematically accurate, but cause the user to feel strongly about an application. One of my favorite is that a series of pauses that happen too close together are experienced as one giant pause for the whole duration.

So you know how you hate it when your music player is on 'shuffle' and it plays the same song twice in a row? OP is saying people experience that it games too, and I think that's perfectly plausible.

If I have a 10% chance of missing, there's a 1% chance of missing twice in a row.

If I have a 25% chance of missing, there's a 1.5% chance of me missing 3 times in a row, and if I sit there for an hour with my finger on the trigger this is going to happen rather a lot. What I'm going to remember is that 'all the time' I just miss the same dude and he nearly kills me and I don't like this game.

Maybe also try taking your random number [0, 1] to a certain power. E.g., square the number. Or randomly choose a max and then iteratively choose a random value between [0, max] and optionally keep repeating.

There's probably an elegant way to do that in hardware (but I'd have no idea).

What bothers me about the game thing is that the author seems to be implying that they can tell that a game is using a PRNG. At worst, a game is going to be using something like Mersenne Twister. While distinguishable from random noise through careful analysis, it's extremely unlikely that there are readily perceptible patterns in the output.

And if you really do need unpredictable numbers for your game (e.g. online gambling, where good randomness is a security requirement), it's far more practical to use a CSPRNG, especially since one is built into your OS. The practical difference is negligible. If an attacker can predict /dev/urandom, we've all got much bigger problems.

I'm with you on 'shuffle is what people expect when they say random' but how do you keep the player from picking up on the patterns?

One of my favorite bits of statistical math is the 2d6 phenomenon. That you can get a normal distribution simply by summing two random numbers together. If you want 1-10 but most of the numbers in the middle, do (random(1-10) + random(1-10))/2

The problem with noise-based random number generators is that you have to be sure your noise source isn't picking up interference. Interference may have structure, from power line hum to radio carriers to noise from other digital components.

Here's an alternative which is slightly more paranoid.[1]

[1] https://www.tindie.com/products/WaywardGeek/infinite-noise/

Reminds me of the Lavarand, the random number generator by SGI, built out of lava lamps:

https://en.wikipedia.org/wiki/Lavarand

And its site in all its Web1.0 glory: http://web.archive.org/web/20010926221159/http://lavarand.sg...

OK but where's the statistical testing to verify it?

For microelectronics there are better ways for true digital random number generators, e.g. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.99....

No need. If that sequence is not random, quantum mechanics is in big trouble.

You're not sampling the signal directly on the transistor. There are lots of places where the randomness could be biased.

Random does not mean uniform and unbiased. A coin that lands heads up 99.99% of the time is still random, but not terribly useful without some postprocessing.

just because binary data is "random" doesn't mean it yields independent, identically-distributed random variables --- whatever the source.

Here's my favorite random number generator for use in games :)

http://gamesbyemail.com/news/diceomatic

how about this one :)

https://github.com/id-Software/DOOM/blob/77735c3ff0772609e9c...

This is how it's really done. :-)

An RTL-SDR [0] commodity hardware device paired with rtl-entropy [1] seems to have great potential for filling this need. It has some nice write-ups [2][3][4] and ongoing development.

0: http://www.rtl-sdr.com

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

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

3: https://pthree.org/2015/06/16/hardware-rng-through-an-rtl-sd...

4: http://blog.krisk.org/2013/12/high-quality-entropy.html

Until the NSA parks outside your house with a transmitter :-) How do you know it's really random?

I bet if you wave your antenna around, pointing at some bright stars, while doing a few of your favorite dances, that ought to make that gathered data stream pretty hard to replicate.. As far as I understand, in terms of practicality, "randomness" isn't important, only obscurity and/or unpredictability.

You could use a directional antenna, and point it straight up. I mean, sure, you could put a geostationary satellite or something above you, but that's just getting silly at that point.

You probably shouldn't trust this unless you can validate the randomness of the output with tests like Diehard or others http://csrc.nist.gov/groups/ST/toolkit/rng/batteries_stats_t...

While it's definitely a good idea to run it through something like Diehard, it's interesting to note that [this principle has already been the subject of a lot of research](https://www.kernel.org/doc/ols/2014/ols2014-mueller.pdf) (granted, the CPU time jitter uses time noise as an entropy source where the post uses electrical signal noise, but it's a fairly similar principle all the same).

This is informative, and looks like a fun project! But if you're simply looking for random bits on the Raspberry Pi, don't overlook that it already comes with a HW RNG built in.

Why would I want to use this over chacha20 seeded properly?

It's more fun this way.

Other than that you wouldn't.

I guess you could argue governments all over the world are looking at chacha20, where as this has security through obscurity, which has value.

But on the other side being handmade hardware it'd be much more likely to have flaws which analysis of the data might find rather quickly.

Well, since you need true randomness to seed ChaCha20 properly you could use this gadget to add more entropy to your pool.

Of course if you really cared you'd just buy a real TRNG.

> you'd just buy a real TRNG

But then you have a blackbox and are forced to trust the manufacturer.

(And as the Snowden revelations show, you have to care about man-in-the-middle attacks over the postal system, while that blackbox is on the way to you.)

To add some tinfoil-hat mentality on top of that: I believe it is easier to manipulate a blackbox TRNG than it is to manipulate individual components (transistors, etc.).

So although the DIY approach has the downside that you may get things wrong, it has the upside that it is very hard to manipulate.

The Cryptech TRNG uses ChaCha as CSPRNG. ChaCha is seeded using two separate noise sources of which one is based on the same principle as the one described in the article.

The output from the entropy sources are mixed using SHA-512 before being used to seed ChaCha.

The Cryptech TRNG has been and is continiously tested. The current development will add test functionality to provide online monitoring of the entropy sources as well as the final output from ChaCha.

There will also be a specific test mode to allow user applications to insert its own "entropy" and extract generated seed as well as providing test vectors for ChaCha. In this way it will be possible to verify that the TRNG works during production, but also verify that the digital chain is in fact working as specified.

For more see: http://wiki.cryptech.is/wiki

(Disclaimer: I am the main author of the Cryptech TRNG.)

Is gathering 256 bits of entropy a problem that justifies a dedicated piece of hardware?

Optocoupler to step 5v logic down to 3.3v for the raspberry pi is madness. Just use a voltage divider!

Still, very cool project though!

Paranoia? Wouldn't things get rather ugly if you accidentally fed a voltage divider the 18V in that circuit?

Yes, but the attitude just rubs me the wrong way. If they suggested the voltage divider, it would have been a good opportunity to instill careful engineering and testing practices. They could have said something like "this will fry your GPIO if you accidentally send 18v, so make sure to test the circuit with a multimeter or scope!" Instead, they suggest throwing an expensive part at the problem, supporting the attitude that you can't trust your own engineering. At least they mention that there are other ways to do it.

I dunno, maybe it's two different, equally valid attitudes. I guess I dislike it for the same reason I prefer C++ over Java.

Speaking as a developer, I think the attitude that you can't trust your own engineering can be a healthy one :-) Defensive coding and all that.

First and foremost, voltage divider outputs voltage proportional to input: prior circuitry fails, outputs 18V instead of 5V and you fry at least GPIO port with ~12V. That is expected behaviour. Furthermore, you cannot add resistive load to a voltage divider without affecting division ratio. Optocouplers, Linear regulators (including commonly known LDOs) do not have this property. You can call it paranoia, but that's just sensible design

Why is it madness? It works and like the author said, it's an extremely safe way to do it.

Also, if we're going to be pedantic, I'd recommend a FET over a voltage divider.

If you want something cool without building yourself,

NeuG is an implementation of a true random number generator, a tiny USB 32-bit computer based on a free (as in freedom) hardware design.

http://shop.fsf.org/product/usb/

Here's Alea 2 USB TRNG: http://www.araneus.fi/products/alea2/en/

This kind of post is why I love electronics... and why I clearly need to learn more about it.

Good lord, who taught these guys to draw schematics?

As someone new to schematics, my question is -- how would you improve it? Genuinely curious...

Rearrange components to group functional blocks, and minimize the number of wire crossings. Replace explicit power busses with supply arrows (more (+9) and (-) like they have for external connections). Splitting monolithic chips into individual gates can help too, but probably isn't needed for this.

In addition to what mindslight's saying, a schematic should be drawn to make the signal flow as evident as possible, usually from left to right and top to bottom. Sometimes this isn't practical or reasonable, such as when everything's hooked up to an 80-pin IC or something like that, but for a project this simple it wouldn't have been a problem.

This diagram is a dog's breakfast. The draftsperson apparently thought this style would make the circuit easier to construct, and perhaps it does, but their real job was to make the circuit easier to understand, and that definitely didn't happen.

I think it's just the same placement as the breadboard layout. But yeah, it doesn't really help understanding.

BTW for anyone copying this onto a breadboard, I've never seen one where the busses are split like the picture. Make sure your 5v and 18v aren't actually connected! Perhaps by building in the middle of the board if the bus is split there.

Really? I've seen plenty of breadboards with split busses like that, but that could just be the fact that it's one of the longer breadboards. There's been a handful of times where I'm wondering why a circuit isn't working only to realize I hadn't bridged the power/ground rails.

Yes, most breadboards are split in the middle. But that picture shows a split only three groups from the end.

FWIW I generally just leave those bridged and a healthy supply of decoupling and supply caps as things that just stay on the board. Circuits that want more than 2 rails + ground get built on a larger board consisting of multiple basic boards, so there's never a need to pack things in.

That guy, Charles Platt (https://en.wikipedia.org/wiki/Charles_Platt_%28author%29) probably taught more people about electronics than most. I believe the schematic is in his breadboard-friendly style, which takes a bit getting used to but is optimized for easy implementation on a breadboard.

So, I guess CamperBob2 is right that it's optimized for building rahter than theoretical analysis. Usually the text does a pretty good job of explaining his circuits.

2 Gbps of true random numbers:

https://qrng.anu.edu.au/

the video output of a moving camera mounted on a quadcopter pointing at a crowd might also be a pretty good source for a random number generator

this seems like a lot of work compared to an LCG, which is blindingly fast and more than good enough for game purposes.

LCG is a pseudo-random number generator.

The electronic design described in the article is a _true_ random number generator.

For gaming purposes, a standard pseudo-random number generator is faster, more reliable and has better statistical properties (!) than this hardware random number generator. It is also cheaper (cheap as in free software).

> has better statistical properties

http://www.cryogenius.com/hardware/isarng/diehard.txt

The hardware generator passes more diehard tests than the LCG. In any case, a true-RNG scheme is supposed to feed into a PRNG. True RNGs feed into sources of entropy, and then you use entropy sources as part of PRNGs to extract more randomness out of them (if you need speed).

Or not... if you need "security". (Stay slow, so you get tons of entropy)

> a standard pseudo-random number generator is faster

This hardware RNG doesn't require a CPU at all. Its an electronics project that can feed into anything.

It makes almost no sense to compare a hardware solution against a software one.

you don't seem to understand the very low requirements for all of the practical use cases in games. having dedicated hardware for that is going to require more work for games developers for no detectable benefit.

yeah, thats kind of my point. you just don't need that level of strength in a random number generator for anything realistic in games at all...

Is it a quantum random number generator ?

Reply on news.ycombinator.com