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 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...
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.
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.)
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
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).
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]
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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).
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.
A perfect shuffle is called a "riffle". Sometimes "perfect riffle" or "perfect shuffle" or "perfect riffle shuffle". :)
A perfect riffle performed several times in a row will return a deck to its original state, it cycles. Its obviously hard to perform, but apparently possible with practice.
I don't know if imperfect riffling can decrease randomness, and I'm open-minded but skeptical. I think it just takes a long time to achieve uniform randomness if the shuffling is bad. Good shuffles can randomize a deck after just a few shuffles. Bad shuffles can take a very long time.
OP asked about shuffling multiple times and having the deck become less random intentionally. AFAIK, the only way to do this deliberately is with the riffle, and it only works from a sorted deck.
A deck can indeed end up more ordered after one or more shuffles than it was before. But if the shuffle has any randomness to it, this is coincidence, and it will only happen as often as it is likely, which is not much. The same way you do have a probability of flipping 10 heads in a row, you can accidentally organize a deck. But the chance of flipping 10 heads in a row is (you know already) slightly lower than one in a thousand. The chance of just happening to organize a randomized deck after one or multiple shuffles is "a lot" lower than that.
If you want to be precise, it doesn't make sense to talk about _one_ shuffled or randomized deck.
Randomness strictly speaking only makes sense for distributions, not for particular instances.
If you have any probability distribution of permutations, then shuffling doesn't make it less random (ie doesn't decrease entropy), no matter how bad your shuffle is. As long as your shuffle does not depend on the state of the cards.
A random shuffle might, by chance, return a specific deck into a fully sorted state.
OP was deleted because it was getting downvoted. Apparently the state is a normal, expected outcome from randomization, and it was a dumb question to ask.
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'.