True randomness / true random numbers

Hello,

I’ve recently been interested in random number generation.
I know that the random numbers from https://www.random.org/ are generated using atmospheric noise. After thinking about that for a while, I came up with an idea to generate random numbers from noise on audio recordings.

I’ve set up a program on my computer to read raw 16 bit PCM at 48000 hz from my USB audio device, with no microphone or anything else plugged into the mic socket. I take the least significant bit of each sample and use it to make random numbers, so I have to read 32 samples to make one random 32 bit integer so it’s not very fast.

But anyway, as far as I can tell, it looks like it produces fairly good random numbers:

Does anyone know if the numbers that I’m getting from this method could be considered ‘truly random’? I’m also concerned about the possibility that there may be some kind of dithering being applied to the audio stream, but I’m not sure how likely that is as I’m recording the data directly as raw PCM using ‘arecord’, but I can’t rule it out.

Is there a more certain method of generating truly random numbers at home?

PM

I take the least significant bit of each sample and use it to make random numbers, so I have to read 32 samples to make one random 32 bit integer so it’s not very fast.

Off the top of my head:

• Define an array with 65536 word-sized entries.
• Restrict your random number generation to 16 bit values.
• When you have a random value, it will be in the range 0-65535.
• Use that integer as an array offset.
• Increment the integer at that location.

• Leave it running all night, then visualise (however you like) the results.

If it is truly random, you should see a fairly even choice of numbers, with no grouping or missing bits.
Since you are taking the low bit from each sample, you will be having a choice of 0 or 1 each time. What is the likelihood of having a zero value? In fact, the further into the number you go, the less likely it is that the bit will be a zero. Remember, you are making 16 (for this test, 32 for real) readings for one result.
With that in mind, I would imagine that your results will be skewed to favour higher numbers. How much? Well, that remains to be seen.

So restrict your test to a managable size and feed the results into an array, see what sort of numbers are actually generated.

If you’re looking for something that is truly random, the answer is “almost certainly not”.

The problem is one of external interference. You might think the stream looks random, but your equipment could have picked up a WiFi or Bluetooth carrier signal without you realising it, thus adding an element of order to the data.

I did in fact look into this many many years ago. At the time the preferred method was to use a “noise diode” inside a Faraday cage to minimise external interference. I imagine better techniques are available these days.

@Rick
I tried what you suggested – I generated 16 bit integers and used them to increase an array of 65536 counters and left it running overnight.
The lowest count was 1464, the highest 1813, and the average was 1634.6799

I also did a test where I generated 32 bit integers and counted the bits.

The column on the left counts the number of times a bit was set, and the column on the left counts the number of times a bit was not set.

@Stuart
Ah right, that’s unfortunate. I don’t expect there’s anything I can do to block out the interference. It’s interesting to know about the noise diode method.
If you don’t mind talking about it, when you were looking into this years ago, did you have any specific purpose or need for true random numbers? Or was it just for fun? (in my case it’s just for fun)

PM

The lowest count was 1464, the highest 1813, and the average was 1634.6799

So you got zero at least 1464 times?

The column on the left counts the number of times a bit was set, and the column on the left counts the number of times a bit was not set.

I was looking more for the distribution of selected numbers. If every single number showed up somewhere between the 1464-1813 range, then that seems to be a pretty impressive dispersion.

The next thing to do is to take all those samples and subtract 1464. Then divide the result by two (to push it into a range if less than 255). Then simply plot each point using the final value as amounts of R,G,B for a greyscale visualisation of the data. So any patterns stand out?

Without using special things, it’s damn near impossible to get truly random data. Depending on what you want to do, this may be “good enough”, and I think it’s a neat hack, leaving the audio input disconnected and reading samples from it.

I think noise diodes and such are used for heavy duty encryption? The more predictable something is, the more easily it can be compromised. If you think about a Cesar cypher that you might have used when you were a child, it can be broken quickly (even if you replace letters with symbols) because the frequency of symbols will match the frequency of letters in the English language, so if you take the frequencies and replace with e, t, a, o (for English text) it should be enough to permit the message to be decoded.
Multiply the complexity by a billion and that’s modern crypto. It needs to look convincingly like random noise while still actually being something eventually intelligible. I wish I understood the maths behind it.

The trouble is that the word random applied to a sequence of numbers is often used to mean that if somebody is told what the first so many are, they will not be able to deduce what the next one will be. This is as far away from a mathematical definition as that classic: a curve in the plane is continuous if you can draw it without taking the pen off the paper. If we take as a definition of IsRandom(x:sequence) something like Forall (r:rule) NotSatisfy (x,r) then we have to start deciding what we mean by a rule.

Gavin, I didn’t get much beyond your first sentence, suffice to say that my definition of “random” is “that which is not predictable by algorithm”.
Most implementations fail because of their very nature of using a known algorithm to generate “random” numbers, such that we must seed the generator with some variable value such as the ticker or RTC bytes. Proper random must by definition have some sort of input from an external non-computational source. Detecting noise in an analogue input is one such idea, though as Stuart points out, such a thing is not necessarily foolproof. It is, however, far better than RND (BASIC) or rand() (C).

If you don’t mind talking about it, when you were looking into this years ago, did you have any specific purpose or need for true random numbers? Or was it just for fun?

Oh, it was just for fun.

Back in the mid-1970s, my (then) job presented me with the chance to see some documents relating to a well-known machine that relied rather crucially on random numbers. Not detailed design specifications, but enough for me to get a good idea of how it worked. This wasn’t directly related to my job function, and my only reason for reading the documents was that I had an interest in electronics and computers.

I won’t name the machine, but those of you who have guessed its name had a 2 on the end are on the right track.

won’t name the machine, but …

drove the fastest milk-cart in the west!

I won’t name the machine,

You mention mid ‘70s, so let’s start with an easy one – did it have a microprocessor (akin to the BBC Micro) or was it still using a logic board setup (like the IBM 5100)?

Rick,

So you got zero at least 1464 times?

It seems like it. This is the result I got http://dusthillguy.ddns.net/folder/files/quickupload/usbaudiobits/20181003-123948_exportnumbers
Line 1 corresponds to array(0) and so there should be 65536 lines in that text file.

The programs I used to generate the numbers and test the results are here, if you’re interested http://dusthillguy.ddns.net/folder/files/quickupload/usbaudiobits/

PM

The Commodore 64 had a neat way of generating random numbers with the SID.

https://www.atarimagazines.com/compute/issue72/random_numbers.php

I swear there was another way by reading a pin that was connected to the heatsink on the VIC. I recall it was influenced by the heat of the VIC though. This had the side effect of being able to keep rough tabs on the temperature of the VIC when abusing the non-orthogonal nature of the hardware.

drove the fastest milk-cart in the west!

Yup, right first time.

did it have a microprocessor (akin to the BBC Micro) or was it still using a logic board setup

The design certainly predated the launch of the Intel 8008 and would in all probability have been finalised before commercial availability of the Intel 4004, so it was unlikely to have used a microprocessor. Like I said, I didn’t see the detailed design specifications, so I can’t be 100% sure on this point.

P.S. When I view this thread using Safari I can see Patrick’s inline images, but when I use Firefox the images are missing. Odd…