[ostensible]

This being raspberry pi absolves you from needing to buy a separate hardware noise generator: it has plenty of GPIO. For example, one can obtain entropy by sampling random noise generated by reverse-biasing a junction in a cheap pn transistor. Here is an example: http://holdenc.altervista.org/avalanche/. Bonus — maybe it will get you hooked on electrical engineering!

Btw, some versions of raspberry pi already have hardware random number number generator accessible at /dev/hwrng.

[myself248]

How does the disconnected audio input of any random PC or thinclient compare?

I continue to find it a bit silly to see "with a raspberry pi" when people just mean "with any random linux box that doesn't need to be very powerful".

It's like listening to NPR, where every smartphone is an iPhone even if it's an Android, you know?

[juliangoldsmith]

>How does the disconnected audio input of any random PC or thinclient compare?

That will give you RF noise, which isn't really random.

[theamk]

Electrical noise (including RF noise) is really random, as in it is impossible to predict exact value.

It does have non-flat spectrum, meaning some values are more probable than others, but that only means you need to whiten it. (A rough analogy might be a 6-sided die labeled with 1,1,1,2,3,4 - yes, number 1 is much more likely to come out. No, this does not make it "not really random", and some trivial math can produce ideal random stream out of it)

The only problem with audio input is that you may end up with non-random value - like all-zero output. But properly implemented whitener should detect this and stop outputting any value at all.

[Keyframe]

it's an often-made mistake where random generation / randomness is confused with probability distribution. Having said that, I don't know (as is in really don't know) if RF noise is unbiased; doesn't sound like it?

[theamk]

If you are talking about DC bias (as in, long term average of raw readings), then "unconnected audio input" is pretty likely to have it - it's easy to introduce via component tolerances, and there is no real reason to keep it exactly zero for audio purposes. But it's also pretty trivial to fix in software.

If you are talking bias in more general sense, then audio input noise is non-uniform in the frequency space, for example there is low-pass filter which filters out high input frequency, and it will affect noise values too. Good whitening algorithm is essential.

The good news however is there are many noise sources which are actually caused by quantum effects in electronic parts, and therefore completely unpredictable. Even if NSA recorded all RF noise, they still could not predict what the ADC will capture. (But they might be able to capture digital bits as they travel over the bus...)

[juliangoldsmith]

If we were dealing with pure cosmic background radiation, or inside a Faraday cage, sure.

What I'm referring to are things like radio broadcasts, 60 Hz hum from power lines, noise put out by switching power supplies, and that sort of thing.

Just having a bias, as in your example, would be still truly random. If you knew that every tenth roll you'd get a 3, it would no longer be random. When your random number generator can be influenced by the outside world, it's no longer suitable for cryptographic use.

[evil-olive]

> That will give you RF noise, which isn't really random.

what does "really" random even mean in this context? does it actually matter?

given 3 hypothetical devices in a homelab:

a) does no specialized hardware entropy collection, and instead relies entirely on the standard Linux kernel mechanisms

b) does entropy collection based on the RF noise that you're saying isn't "really" random

c) does entropy collection based on whatever mechanism you have in mind that generates "real" randomness (hand-carving bits of entropy out of quantum foam, or whatever)

even if your threat model includes "the NSA tries to break into my homelab"...device A will almost certainly be fine, they'll have ways of getting access that are much simpler than compromising the entropy pool.

I suppose device B has a theoretical vulnerability that if the NSA had physical access to your homelab, they could monitor the RF environment, and then use that to predict what its inputs to the entropy pool were. but...that's assuming they have physical access, and can plant arbitrary equipment of their own design. at that point, they don't need to care about your entropy pool, you're already compromised.

[XorNot]

Suitably similar RSA keys well compromise each other.

https://www.infoq.com/news/2019/12/rsa-iot-vulnerability/

So bad randomness can let a remote attacker break them much more easily.

[theamk]

No one puts raw bit source directly into private key, they always whiten it via some method (often entropy pool setup using strong hash/encryption functions).

That means that even if you "random inputs" are totally predictable, the random values which come out of whitener are completely distinct, and generated RSA keys have virtually zero chances of being similar.

[XorNot]

That's arguing that you can just seen an RNG with the current time and use a PRNG as your randomness source - a whitener can't give you randomness out which isn't there to start with.

In the above, fairly extreme case, the risk should be obvious: if someone has a decent guess on what the uptime of your system is, and knows you're doing this, then the search space to crack certificates can be made accessibly small.

Like if you know see a certificate with a Valid From date of say, January 1, 2025 but you know the service definitely wasn't running on January 1, 2024, then by guessing what the PRNG is you've constrained your search space to 1704027600 through 1735650000. So the issue isn't whether the numbers you emit are distinct - it's that an adversary can make it suitably likely that they can produce colliding RSA keys themselves anyway (and remember, they get unlimited attempts at this - they only have to succeed once).

EDIT: And while you can certainly argue that they couldn't predict the exact noise environment of say, your server room, it's also not impossible to model which also might constrain the search space enough to accessible. It's not "haha! we know your every move" it's just making the problem space small enough to brute force.

[jcims]

I'd do this then three years later realize that something broke and it's just been feeding zeroes for the last 18 months.

[kevindamm]

good point, the project immediately after building the CA is to build a decent monitoring/alerting setup.

[FredPret]

Could still have been random

https://xkcd.com/221/

https://web.archive.org/web/20011027002011/http://dilbert.co...

[8xeh]

I was not aware of this! That's kinda fun.

I did an entropy test on my Pi5 (according to https://rob-turner.net/post/raspberrypi-hwrng), and it (7.999832 bits per byte) has about the same entropy as /dev/urandom (7.999831 bits per byte).

However, when using it directly, it's pretty slow. /dev/hwrng is 200 KB/s, /dev/urandom is 40 MB/s.

Though, maybe that doesn't matter if it's just intended to be used to add entropy to the system entropy pool.

[kurikuri]

The Raspberry Pi 4 model B can also implement a FIPS-compliant entropy source in the form of CPU Jitter Random Number Generator (JEnt)! It is listed under certificate E21 within NIST’s Entropy Source Validation Program (ESV), so it could even be used in a cryptographic module.

ESV testing for JEnt uses an oversampling rate of 3, so even if you don’t want to use the precise setup described in the certificate (maybe a different version of OS, etc), the entropy rate from this will be more than adequate.

[tashian]

I love this idea!