Hackaday Editors Elliot Williams and Mike Szczys talk turkey on the latest hacks. Random numbers, art, and electronic geekery combine into an entropic masterpiece. We saw Bart Dring bring new life to a cool little multi-pen plotter from the Atari age. Researchers at UCSD built a very very very slow soft robot, and a broken retrocomputer got a good dose of the space age. A 555 is sensing earthquakes, there’s an electric motor that wants to drop into any vehicle, and did you know someone used to have to read the current time into the telephone ad nauseam?
Take a look at the links below if you want to follow along, and as always tell us what you think about this episode in the comments!
Are you waiting for something that may never happen? Maybe it’s the end of your ennui, or the release of Half Life 3. While you wait, why not build a Godot Machine? Then you can diversify your portfolio and wait for two things that could happen today, tomorrow, or at sunrise on the 12th of Never.
The Godot Machine is a functional art piece that uses a solar panel and a joule thief to charge a bank of capacitors up to 5V. Whenever that happens, the Arduino comes online and generates a 20-bit random number, which is displayed on an LED bar. If the generated number matches the super-secret number that was generated at first boot and then stashed away in EEPROM, the Machine emits a victory beep and lights a green LED. Then you can go back to complaining about whatever.
We like that [kajnjaps] made his own chaos-based random number generator instead of just calling random(). It uses a guitar string to collect ambient electronic noise and an entropy generator to amplify it. Then the four least significant digits are used to seed the logistical map, so the initial value is always different.
Twitter is kind of a crazy place. World leaders doing verbal battle, hashtags that rise and fall along with the social climate, and a never ending barrage of cat pictures all make for a tumultuous stream of consciousness that runs 24/7. What exactly we’re supposed to do with this information is still up to debate, as Twitter has yet to turn it into a profitable service after over a decade of operation. Still, it’s a grand experiment that offers a rare glimpse into the human hive-mind for anyone brave enough to dive in.
One such explorer is a security researcher who goes by the handle [x0rz]. He’s recently unveiled an experimental new piece of software that grabs Tweets and uses them as a “noise” to mix in with the Linux urandom entropy pool. The end result is a relatively unpredictable and difficult to influence source of random data. While he cautions his software is merely a proof of concept and not meant for high security applications, it’s certainly an interesting approach to introducing humanity-derived chaos into the normally orderly world of your computer’s operating system.
This hack is made possible by the fact that Twitter offers a “sample” function in their API, which effectively throws a randomized collection of Tweets at anyone who requests it. There are some caveats here, such as the fact that if multiple clients request a sample at the same time they will both receive the same Tweets. It’s also worth mentioning that some characters are unusually likely to make an appearance due to the nature of Twitter (emoticons, octothorps pound signs, etc), but generally speaking it’s not a terrible way to get some chaotic data on demand.
On its own, [x0rz] found this data to be a good but not great source of entropy. After pulling a 500KB sample, he found it had an entropy of 6.5519 bits per byte (random would be 8). While the Tweets weren’t great on their own, combining the data with the kernel’s entropy pool at /dev/urandom provided something that looked a lot less predictable.
The greatest weakness of using Twitter as a source of entropy is, of course, the nature of Twitter itself. A sufficiently popular hashtag on the rise might be just enough to sink your entropy. It’s even possible (though admittedly unlikely) that enough Twitter spam bots could ruin the sample. But if you’re at the point where you think hinging your entropy pool on a digital fire hose of memes and cat pictures is sufficient, you’re probably not securing any national secrets anyway.
(Editor’s note: The way the Linux entropy pool mixes it together, additional sources can only help, assuming they can’t see the current state of your entropy pool, which Twitter cats most certainly can’t. See article below. Also, this is hilarious.)
What do you do, when you need a random number in your programming? The chances are that you reach for your environment’s function to do the job, usually something like rand() or similar. This returns the required number, and you go happily on your way.
Except of course the reality isn’t quite that simple, and as many of you will know it all comes down to the level of randomness that you require. The simplest way to generate a random number in software is through a pseudo-random number generator, or PRNG. If you prefer to think in hardware terms, the most elementary PRNG is a shift register with a feedback loop from two of its cells through an XOR gate. While it provides a steady stream of bits it suffers from the fatal flaw that the stream is an endlessly repeating sequence rather than truly random. A PRNG is random enough to provide a level of chance in a computer game, but that predictability would make it entirely unsuitable to be used in cryptographic security for a financial transaction.
There is a handy way to deal with the PRNG predictability problem, and it lies in ensuring that its random number generation starts at a random point. Imagine the shift register in the previous paragraph being initialised with a random number rather than a string of zeros. This random point is referred to as the seed, and if a PRNG algorithm can be started with a seed derived from a truly unpredictable source, then its output becomes no longer predictable.
Selecting Unpredictable Seeds
Computer systems that use a PRNG will therefore often have some form of seed() function alongside their rand() function. Sometimes this will take a number as an argument allowing the user to provide their own random number, at other times they will take a random number from some source of their own. The Sinclair 8-bit home computers for example took their seed from a count of the number of TV frames since switch-on.
The Arduino Uno has a random() function that returns a random number from a PRNG, and as you might expect it also has a randomSeed() function to ensure that the PRNG is seeded with something that will underpin its randomness. All well and good, you might think, but sadly the Atmel processor on which it depends has no hardware entropy source from which to derive that seed. The user is left to search for a random number of their own, and sadly as we were alerted by a Twitter conversation between @scanlime and @cybergibbons, this is the point at which matters start to go awry. The documentation for randomSeed() suggests reading the random noise on an unused pin via analogRead(), and using that figure does not return anything like the required level of entropy. A very quick test using the Arduino Graph example yields a stream of readings from a pin, and aggregating several thousand of them into a spreadsheet shows an extremely narrow distribution. Clearly a better source is called for.
Noisy Hardware or a Jittery Clock
As a slightly old-school electronic engineer, my thoughts turn straight to a piece of hardware. Source a nice and noisy germanium diode, give it a couple of op-amps to amplify and filter the noise before feeding it to that Arduino pin. Maybe you were thinking about radioactive decay and Geiger counters at that point, or even bouncing balls. Unfortunately though, even if they scratch the urge to make an interesting piece of engineering, these pieces of hardware run the risk of becoming overcomplex and perhaps a bit messy.
The best of the suggestions in the Twitter thread brings us to the Arduino Entropy Library, which uses jitter in the microcontroller clock to generate truly random numbers that can be used as seeds. Lifting code from the library’s random number example gave us a continuous stream of numbers, and taking a thousand of them for the same spreadsheet treatment shows a much more even distribution. The library performs as it should, though it should be noted that it’s not a particularly fast way to generate a random number.
So should you ever need a truly random number in your Arduino sketch rather than one that appears random enough for some purposes, you now know that you can safely disregard the documentation for a random seed and use the entropy library instead. Of course this comes at the expense of adding an extra library to the overhead of your sketch, but if space is at a premium you still have the option of some form of hardware noise generator. Meanwhile perhaps it is time for the Arduino folks to re-appraise their documentation.
Let’s start off with one of my favorite quotes from John von Neumann: “Any one who considers arithmetical methods of producing random digits is, of course, in a state of sin. For, as has been pointed out several times, there is no such thing as a random number — there are only methods to produce random numbers, and a strict arithmetic procedure of course is not such a method.”
What von Neumann is getting at is that the “pseudo” in pseudorandom number generator (PRNG) is really a synonym for “not at all”. Granted, if you come in the middle of a good PRNG sequence, guessing the next number is nearly impossible. But if you know, or can guess, the seed that started the PRNG off, you know all past and future values nearly instantly; it’s a purely deterministic mathematical function. This shouldn’t be taken as a rant against PRNGs, but merely as a reminder that when you use one, the un-guessability of the numbers that it spits out is only as un-guessable as the seed. And while “un-guessability” isn’t a well-defined mathematical concept, or even a real word, entropy is.
That’s why entropy matters to you. Almost anything that your computer wants to keep secret will require the generation of a secret random number at some point, and any series of “random” numbers that a computer generates will have only as much entropy, and thus un-guessability, as the seed used. So how does a computer, a deterministic machine, harvest entropy for that seed in the first place? And how can you make sure you’ve got enough? And did you know that your Raspberry Pi can be turned into a heavy-duty source of entropy? Read on!
Despite the claims of “free energy” on the title of the video below, this is not yet another wacky perpetual motion story. We here at Hackaday fully support the laws of thermodynamics, and we think you should too. But you have to admit that a pump that works without any apparent energy inputs looks kind of shady at first glance.
The apparatus in question is a ram pump, a technology dating back all the way to the 18th century. The version that [Junkyard – Origin of Creativity] built uses commonly available materials like PVC pipes and fittings. About the only things on the BOM that might be hard to scratch up are the brass check valves, which should probably be flap valves rather than the easier to find spring valves. And the only custom part is an adapter to thread the plastic soda bottle that’s used as an air chamber to the PVC, which a 3D printer could take care of if you choose not to hack a bottle cap like [Junkyard] did. The video below shows the impressive lift achieved just by tapping the kinetic energy of the incoming flow.
[Paul] designed a new open-hardware RNG (random number generator) that includes two sources of entropy in a small package. The first source of entropy is a typical avalanche diode circuit, which is formed by a pair of transistors. This circuit creates high-speed random pulses which are sampled by the onboard microcontroller.
What makes this design unique is a second entropy source: a CC2531 RF receiver. The RF receiver continuously skips around channels in the 2.5Ghz band and measures the RF signal level. The least-significant bit of the signal level is captured and used as a source of entropy. The firmware can be configured to use either source of entropy individually, or to combine both. The firmware also supports optionally whitening the entropy byte stream, which evens out the number of 1’s and 0’s without reducing entropy.
The OneRNG uses the USB-CDC profile, so it shows up as a virtual serial port in most modern operating systems. With the rngd daemon and a bit of configuration, the OneRNG can feed the system entropy source in Linux. [Paul] also has a good writeup about the theory behind the entropy generator which includes images of his schematic. Firmware, drivers, and hardware design files are open-source and are available for download.