Bitcoin Forum

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 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.

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.

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?

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.

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.

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).

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.

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

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.



That's quite interesting too.


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

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%)

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.

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.

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.

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.


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

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...

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.

You sound confused. More noise is more entropy. Less noise is less. You want as much noise as possible. You are trying to use "radio noise (https://en.wikipedia.org/wiki/Radio_noise)", but for somehow want less noise?

Let me clarify then; I said if only gets white noise, means if the receiver is so bad that isn't able to receive any broadcast at all. White noise is obviously welcome for entropy.

Update on the first attempt:

As I said this week I'll start trying around (time permitting), and for this first attempt I used a cheap analogical AM receiver. But the results were a disaster. I started to get a pattern, and it turns out the only thing the receiver was receiving was interference from the electronics around.
Will retry next week changing some stuff.

Hi,

Have you considered using turbulent air flow as a source of randomness? It would be quite localized if you use a home fan to generate the turbulent air flow. My opinion is that if an attacker copies your hardware exactly and is listening to the same frequencies as you in a close enough location, he/she would be able to copy your signal. On the other hand, even if the attacker has the same hardware as you, he can't possibly read the same turbulent air signal as you. To do that, he would have to place the pressure sensor really, really close to yours.

turbulence is not completely random so it may be somewhat predictable in its output of the pressure sensor. and exhibit patterns.

Technically it is not random as there is a mathematical description of it in the Navier-Stokes equations, but since these are unsolvable in all but highly idealized situations, in practice it is a random phenomena.

Also let me mention that there is no perfectly random physical source as they all can be modeled by some sort of mathematical equation, so your target should be to use a source with properties for which it would be very laborious and difficult for someone to create a controlled interference in. Hence the turbulence idea.

Just attach a standing miniature fan next to your box and then place a sensor in front of it to measure its turbulence and feed that as entropy into the system (perhaps even regular pressure/velocity measurements may be suitable if an attacker can't find a way to control these props).

Exactly the setup I was thinking would work.

The input from this could be replicated by "just attach a standing miniature fan next to your box and then place a sensor in front of it to measure its turbulence".

When generating private keys of any sort, you should not try to reinvent the wheel. If you are using something as a means to generate entropy in addition to using entropy from a known secure way of generating entropy, at best, you are going to have the same amount of entropy, but you may end up with less entropy.

You either trust your computer to generate a random number or you don't. Using additional input is not going to change this trust. If you don't trust your computer to generate a random number, you should use something that you know will produce a random output, such as a coin toss or a dice roll.