True Random for automatic offline address generator

[SirArthur]

For a BTC related project I need to create some addresses on automatic mode; the machine is offline, the machine prints both WiF Key and matching Address, there's minimal interaction for this, so it won't be able to pick much from its own memory in order to generate a good Random seed.
So my idea came about building a small piece of hardware using RDA5807M FM radio module under follow scheme:

Arduino/ESP(32/8266) --> gets/generates pseudo random between 880 ~ 1080, then divides by 10 -> i2c frequency set -> listen 1 second -> 2x 16 bit ADC (capture stereo output) -> sets bytes accordingly ---> repeat the process
At access: return x bytes stored, where x = amount of seed bytes.
RDA5807M is meant to be equipped with a weak or no antenna, in order to get not only music or whatever is being said at that frequency, but also get noise and interference.
A secondary pseudo random may set it to shift the frequency (+0.05 Mhz) or not.

Do you think this solution would provide a good enough Random generator? If not, what/how do you think this can be improved?

[1715460293]

1715460293

[1715460293]

1715460293

[1715460293]

1715460293

[BringTheFuture]

I would fart during the listen 1 second for the sake of randomness.

[SirArthur]

I would fart during the listen 1 second for the sake of randomness.

It doesn't listen anything on 16hz to 32khz, just between 88 and 108 Mhz, so your farts wouldn't add nothing to it.

[DannyHamilton]

For a BTC related project I need to create some addresses on automatic mode; the machine is offline, the machine prints both WiF Key and matching Address, there's minimal interaction for this, so it won't be able to pick much from its own memory in order to generate a good Random seed.
So my idea came about building a small piece of hardware using RDA5807M FM radio module under follow scheme:

Arduino/ESP(32/8266) --> gets/generates pseudo random between 880 ~ 1080, then divides by 10 -> i2c frequency set -> listen 1 second -> 2x 16 bit ADC (capture stereo output) -> sets bytes accordingly ---> repeat the process
At access: return x bytes stored, where x = amount of seed bytes.
RDA5807M is meant to be equipped with a weak or no antenna, in order to get not only music or whatever is being said at that frequency, but also get noise and interference.
A secondary pseudo random may set it to shift the frequency (+0.05 Mhz) or not.

Do you think this solution would provide a good enough Random generator? If not, what/how do you think this can be improved?

I suppose it depends on what attack vectors you're trying to protect against and how vulnerable you'd be if a successful attack were performed, however, the two concerns that immediately come to mind are:

1.  If the radio stops working for some reason, you'll possibly be fed a repeating sequence that represents pure silence on all frequencies?

2. An attacker that is aware of your algorithm could potentially transmit a strong enough signal from close enough to your equipment to effectively overpower any "noise", resulting in a predictable set of input data.

[SirArthur]

I suppose it depends on what attack vectors you're trying to protect against and how vulnerable you'd be if a successful attack were performed, however, the two concerns that immediately come to mind are:

1.  If the radio stops working for some reason, you'll possibly be fed a repeating sequence that represents pure silence on all frequencies?

2. An attacker that is aware of your algorithm could potentially transmit a strong enough signal from close enough to your equipment to effectively overpower any "noise", resulting in a predictable set of input data.

First of, thank you for the valid and pertinent answer.
I hadn't think of #1, but I can add a response validation algorithm, either at the MCU or computer checking for patterns or repeated bytes.
As for #2, it has to be potent enough, has to "guess" when the print key would be pressed, as that the only time the random bytes are actually used, and it has to be a FM jammer, as the attacker has also to "guess" which frequency is being listen to and if or not shifted. Thus a jammer would probably render a pattern, throwing an error with the fix applied to #1 and having to running it in continuum, people around would start to complaint of bad radio reception.

[j2002ba2]

For a BTC related project I need to create some addresses on automatic mode; the machine is offline, the machine prints both WiF Key and matching Address, there's minimal interaction for this, so it won't be able to pick much from its own memory in order to generate a good Random seed.
...
Do you think this solution would provide a good enough Random generator? If not, what/how do you think this can be improved?

Good enough? No. You need additional entropy sources. Use the Hardware RNG included in ESP32. Add a microphone. Add a camera. Add some buttons to be pressed. Feed all the data together with timestamps into Fortuna CSPRNG. Also a second seems too short - feed it for a minute.
If this is too much just using the Hardware RNG might be better than radio module.

Will you be around the device every time it's used?
Are you sure the printer always prints what is given?
Does the printer remember the last page(s) it printed?
Is there an "echo" from previous printed pages on the current one?
ESP32 has wifi. Maybe it has a backdoor. Can you make sure no radio wave reaches the module?

[SirArthur]

1 second in loop, not 1 second only.
1 second -> change frequency -> 1 second -> change frequency... at all time the data at the pointer is being append and changed accordingly.
Microphone and camera are pretty much useless, as the place is silent, buttons are just one and spool is erased after each print. No wifi is used and ESP doesn't start wifi unless told to, also an Arduino without Wifi shield can be used.

Let's assume for the sake of the example that the seed is 100 bytes long and each 1 second capture renders 10 bytes of data, so that just after ~10 seconds (+ i2c and code loop) the system is able to return a random.
init: 00 00 00 00 00 00 //init all bytes as 0x00.
loop1: AF DE 3E 21 21 89 39 40 FF FE 00 00 00 00... //one sequence, pattern detected (00 00 00...) -> invalid
loop2: EF EA A1 00 22 11 FA 2F 1A 3B AF DE 3E 21 21 89 39 40 FF FE 00 00 00... //two sequences, pattern detected (00 00 00...) -> invalid
... and so on until the buffer is filled up at loop10.
When the buffer if full, the next loop will remove the last 10 bytes and append the new ones at the beginning of the sequence, repeating this all the time.

[Quickseller]

I suppose it depends on what attack vectors you're trying to protect against and how vulnerable you'd be if a successful attack were performed, however, the two concerns that immediately come to mind are:

1.  If the radio stops working for some reason, you'll possibly be fed a repeating sequence that represents pure silence on all frequencies?

2. An attacker that is aware of your algorithm could potentially transmit a strong enough signal from close enough to your equipment to effectively overpower any "noise", resulting in a predictable set of input data.

First of, thank you for the valid and pertinent answer.
I hadn't think of #1, but I can add a response validation algorithm, either at the MCU or computer checking for patterns or repeated bytes.
As for #2, it has to be potent enough, has to "guess" when the print key would be pressed, as that the only time the random bytes are actually used, and it has to be a FM jammer, as the attacker has also to "guess" which frequency is being listen to and if or not shifted. Thus a jammer would probably render a pattern, throwing an error with the fix applied to #1 and having to running it in continuum, people around would start to complaint of bad radio reception.

Your attacker could simply broadcast on all potential channels for an extended period of time. You could potentially counter this by personally listening to the channel to confirm there is no interference, however an attacker could counter this counter by learning which channel you are listening to, and when, and using this information to learn the input to your "randomness".

It is best to have your machine create a private key seed in a way that is not affected by any external variable. Any external variable you use is going to open up the potential that someone will observe when you generate your seed and can look for information generated around that time.

[NotATether]

Random number generator? No. But a source for random bits of entropy? Definitely.

The best part is that if you can figure how how to make a Linux kernel driver for your hardware that feeds the audio input to the entropy pool, then you don't have to worry about generating random numbers. Embedded devices have a really hard time gathering entropy since there is little to no user output, so as long as your device is continuously collecting sound signals, you can simply generate addresses using random bytes from OpenSSL (which will automatically be hooked up to the entropy pool).

[SirArthur]

Thank you for your answers.
I'm of a philosophy that in cryptography no "secure is secure enough" and no level or paranoia or far fetched attack vector is too much. So your input was highly appreciated.

I strongly disagree with your instance about "external variables"; computers are precision machines, that's why they are unsuitable for generate true randoms on their own. Much of the entropy pools are user generated, or "external variables", such as mouse movements, keys entered, pixel color swaps and so on. All of them, if we ever manage to control quantum mechanics become pretty much predictable, but taken we don't they're pretty good.
Likewise radio waves are much unpredictable out of the quantum level. Yes, if a known song is being broadcast at the frequency the radio is listening, one second of such song = one chunk of the key, but entropy here is naturally given because it's highly unlikely that the radio will have perfect reception, a "crack" and "fizzz" will make a whole difference at the end result.
Also on the "attacker", there's one thing to take to account; one thing is to be physically attacked the other remotely, there're way more kids with VPN and TOR than James Bonds around. The attack vector is very physical, the attacker will have to be in a very short range of the receiver in order to overcome bad reception entropy. And don't forget that the system will pick a random frequency each time, the MCU RNG entropy pool will be keep changing as its memory contents change from the radiowaves being processed. Given enough running time (and it is never meant to stop, regardless if the contents are being used or not) it becomes more and more unpredictable.

One of the most basic electronic random generator is the electronic dice, it's a capacitor that will feed a 555 timer to a decade counter, the timer will oscillate accordingly to the charge at the capacitor, which is set by the amount of time a user is pressing a button, where a microsecond of charge will make a whole difference to the pulses generated and input voltage adds an entropy level. You can "cheat" this by creating a machine that presses the button a very accurate amount of time, thus controlling the capacitor charge and therefore the pulses, for sure, but if you go to use this to play Monopoly with a friend, I believe he will find pretty much strange that you bring your timer device along.

[dkbit98]

Do you think this solution would provide a good enough Random generator? If not, what/how do you think this can be improved?

I saw some people creating random number generation with Geiger counters, using radioactive decay as an entropy source.
One guy Alex Waltz even went to extreme with his project and he combined Raspberry Pi, Geiger counter, Audio interface and Americium 241 from a Smoke Detector.... I think that plain old dices would be just fine  
https://twitter.com/raw_avocado/status/1433408813596545027

[SirArthur]

How about vibration sensor? Unless you push the button gently, the sensor should be able to pick small vibration.

I believe that would be interesting if you are near a road or railroad where trucks or trains may shake things around. Not the case, as the intended generator is a warehouse.

I saw some people creating random number generation with Geiger counters, using radioactive decay as an entropy source.
One guy Alex Waltz even went to extreme with his project and he combined Raspberry Pi, Geiger counter, Audio interface and Americium 241 from a Smoke Detector.... I think that plain old dices would be just fine  Smiley
https://twitter.com/raw_avocado/status/1433408813596545027

That's quite interesting too.


Updating: after checking some waves around, I'm now thinking on use AM or SW bands rather than FM.

[BlackHatCoiner]

The title of this thread touches on some important topics of cryptography.

1) What do you mean by true randomness? Don't we already have true random generators? Do you mean that our supposedly random numbers are chosen predictably?
2) Why is your way more random than ours?

I don't have much to say, but this. Human moves are generally predictable, so anything the human knows he's doing can be predicted on way or another. So, what's unpredictable? The exact opposite:  Roll a dice!

While it's a procedure in which you can calculate the final result, you don't, because it's difficult. So, for you, who's rolling it, it's unpredictable. It's a great source of randomness if the dice is properly made. (Each side is a 16.6%)

[SirArthur]

1) I mean events that either because we don't yet know or are unpredictable on nature, doesn't allow anyone to predict or replicate the result.

i.e. if you seed your computer randomness at the current microtime, it may sound like the result will be unpredictable, but if I know the second it was generated, all I have is to generate 1000 keys with the same algorithm within that second. A hard task by hand, but an easy pick for any computer.

Usually for entropy (other unpredictable events) computers uses parts of the user interaction. Now let's say we add to the previous example the current position of your mouse pointer. Well, it can be at any point in the Cartesian plane represented by your screen resolution. So let's say it's 1920x1080, so now I've 1920*1080*1000, or 2,073,600,000 keys to generate, at 2 Mh/s this would take 1037 seconds, or ~17 minutes to brute force, if I take more points from the cursor, I'll get a number so big that would take millenniums to break, this is actually how Bitcoin is kept secure, it's possibilities are a number so huge that we would be long dead before generate a significant amount of the possible keys.

2) Mine isn't "more random" than yours, the question is, for you to have mouse moves, to have the memory contents changing, to have all the entropy elements a computer being used normally has, someone has to be operating it, otherwise it's pretty much dormant, so it's pseudo-randoms will be weak due to lack of entropy elements.

[NotFuzzyWarm]

My only input is that a FM radio receiver does not produce any audio signal if there is no rf signal. They work by finding a rf signal, locking onto it then responding to the frequency deviations of the signal to create an audio signal. You'll have the baseline thermal noise from semiconductors but that's it.

On the other hand, an AM receiver will pickup and amplify anything including natural radio emissions along with a plethora of man-made signals and would be the best choice to use.

[Quickseller]

The title of this thread touches on some important topics of cryptography.

1) What do you mean by true randomness? Don't we already have true random generators? Do you mean that our supposedly random numbers are chosen predictably?
2) Why is your way more random than ours?

There is no such thing as being “more random”. An outcome is either random or it isn’t.

It is not possible to observe if an outcome is actually random or not based on observation.

In the past (in bitcoins early days) there were wallet software that (intentionally) created private keys with flawed RNG, using a small scope of private keys. Someone looking at many private keys generated this way would not have detected the flawed RNG without looking at the underlying code.

In the case of the OPs proposal, it is possible to determine the radio raves being used to influence the generated private key. This means the OPs method is flawed.

If additional random input is used in addition to the FM input, the entropy will be reduced from what it would otherwise be.

[ABCbits]

How about vibration sensor? Unless you push the button gently, the sensor should be able to pick small vibration.

I believe that would be interesting if you are near a road or railroad where trucks or trains may shake things around. Not the case, as the intended generator is a warehouse.

I would suggest using vibration sensor which is is very sensitive (e.g. could get reading when you walk or move your chair which use wheel), but i doubt it's cheap or practical.

2) Why is your way more random than ours?

This question should be "Why is your way have more entropy than ours?".

[SirArthur]

My only input is that a FM radio receiver does not produce any audio signal if there is no rf signal. They work by finding a rf signal, locking onto it then responding to the frequency deviations of the signal to create an audio signal. You'll have the baseline thermal noise from semiconductors but that's it.

On the other hand, an AM receiver will pickup and amplify anything including natural radio emissions along with a plethora of man-made signals and would be the best choice to use.

Indeed, totally agree there.

FM seams to be unsuitable for the purpose, I'm currently looking into MW/SW/LW, the more promising to be MW and SW, LW never been quite used so the band is pretty much left to static. The issue is; I don't know any module as the FM module referred to work with those frequencies, but I'm thinking on using a stepper to tune around an analogical MW/SW receiver circuit.

[NotFuzzyWarm]

My only input is that a FM radio receiver does not produce any audio signal if there is no rf signal. They work by finding a rf signal, locking onto it then responding to the frequency deviations of the signal to create an audio signal. You'll have the baseline thermal noise from semiconductors but that's it.

On the other hand, an AM receiver will pickup and amplify anything including natural radio emissions along with a plethora of man-made signals and would be the best choice to use.

Indeed, totally agree there.

FM seams to be unsuitable for the purpose, I'm currently looking into MW/SW/LW, the more promising to be MW and SW, LW never been quite used so the band is pretty much left to static. The issue is; I don't know any module as the FM module referred to work with those frequencies, but I'm thinking on using a stepper to tune around an analogical MW/SW receiver circuit.

Do a search using "software defined radio modules" One good link that pops is https://blog.bliley.com/10-popular-software-defined-radios-sdr
#7 in that lineup looks good...

[SirArthur]

Do a search using "software defined radio modules" One good link that pops is https://blog.bliley.com/10-popular-software-defined-radios-sdr
#7 in that lineup looks good...

Thank you for the suggestion, yet SDR radios are both too expensive (can range up to hundreds of USD) and too good for the desired effect. For the intent the radio mustn't have good reception, the more interference the better, as long as it isn't just white noise, I don't actually want to be listening to whatever is said over radio waves.
So one of those inexpensive soap-shaped AM receivers that old men used for listen to football matches when I was a kid seams more appropriate. Turn the varicap around can be achieved either by a small stepper or servo.
I'll start drawing and testing around this week, to see what I can achieve with that setup.