Comment by A_D_E_P_T | Hacker News Reader

Comment by A_D_E_P_T | Hacker News Reader

I'm reminded of a funny story from Edward Friedkin:

"Just a funny story about random numbers: in the early days of computers people wanted to have random numbers for Monte Carlo simulations and stuff like that and so a great big wonderful computer was being designed at MIT’s Lincoln laboratory. It was the largest fastest computer in the world called TX2 and was to have every bell and whistle possible. a display screen that was very fancy and stuff like that. And they decided they were going to solve the random number problem, so they included a register that always yielded a random number; this was really done carefully with radioactive material and Geiger counters, and so on. And so whenever you read this register you got a truly random number, and they thought: “This is a great advance in random numbers for computers!” But the experience was contrary to their expectations! Which was that it turned into a great disaster and everyone ended up hating it: no one writing a program could debug it, because it never ran the same way twice, so ... This was a bit of an exaggeration, but as a result everybody decided that the random number generators of the traditional kind, i.e., shift register sequence generated type and so on, were much better. So that idea got abandoned, and I don’t think it has ever reappeared."

physical entropy sources are crucial to cryptographic security; failing to use them properly has been a major source of insecurity in applied cryptography, most notably the debian openssl bug but also in some other cases. linux has had /dev/random and /dev/urandom for this for decades and has more recently added a getrandom() call

also, there are other intentional sources of nondeterminism in current programming environments, such as aslr and the random hash salt python and perl apply to thwart hash-collision dos attacks

I seem to recall early Windows using mouse movement, to the point where lack thereof would block if entropy was exhausted. Then other things like network rx timing was added to the mix. But what's a system to do in the absence of all such physical inputs?

Desktop / server / mobile chips typically have hardware support for collecting entropy which can be used.

I half remember a case where the program(some sort of install or copy I think) would complete faster while shaking your mouse around.

I will look for the article.

This was different from the old gpg prompts that instructed to move the mouse around when generating keys.

update: it was probably this effect. https://retrocomputing.stackexchange.com/a/11535

PuTTYgen waits for you to move the mouse across a portion of the screen enough times when generating keys[1], sampling the mouse position for entropy.

[1]: https://the.earth.li/~sgtatham/putty/0.80/htmldoc/Chapter8.h...

Here’s the particular explanation I remember reading a few years back: https://retrocomputing.stackexchange.com/a/11535

I was recently waiting on a linux machine to finish a big encrypted file transfer. As soon as I ssh'd in it drastically sped up. My best guess is that it was starved for entropy and logging in gave some.

I'm an embedded systems programmer. We use LFSRs like everyone else. But I always make a point to feed true sources of entropy into the RNG.

Stuff like this

   if (any input changed)
      RNG_seed ^= sysclk;

It's helped on numerous occasions where two or more identical systems co-exist (share a bus for example). Without entropy the systems RNGs are always in sync, which causes all sorts of problems.

For example, on a CAN network bus collision you're supposed to back off a random amount of time. If the colliding systems RNGs are in sync, they keep colliding over and over endlessly.

Entropy will kick you in the ass if you don't think about it. Which is why I always make sure to include it.

You can always turn this off in DEBUG builds.

That makes sense. I could be wrong but I just have this sneaking suspicion that some systems literally have no inputs, though. Nothing received from the outside world... no HCI or sensors of any kind. But maybe such a simple system isn't likely to need much randomness? In your CAN bus example, pretty much anything transmitting onto the bus is doing so because it knows something interesting, as opposed to expressing something deterministic from its own little stored routine?

not necessarily, it might be transmitting a heartbeat so you can detect that that part of the wiring harness is still turned on. i've seen embedded systems with literally no inputs, like the minipov2, but never one that transmits on a network

So if you wanted a bunch of those to transmit onto the same bus/network, and use exponential backoff to resolve collisions, they would just keep colliding forever, right? Because even if they tried to seed their delay with randomness, they'd all do so the same way every time!

i think so, if they didn't have any other sources of randomness; even the traffic on the can bus would give them all the same 'random' bits if they started at the same time

“ physical entropy sources are crucial to cryptographic security”

Of this would be true, then no one would use VMs and cloud instances.

It's my understanding that most clouds (AWS/GCP/Azure) have hardware RNGs available to the VM through something like virtio-rng for exactly this reason. Even if it's not universal (I have no idea), it's certainly something that's available.

as another commenter has pointed out, physical entropy sources can be provided to vms, but sadly the other implied premise of your syllogism is also false: use of insecure cryptography is in fact widespread

There is the wall of lava lamps approach too: https://blog.cloudflare.com/lavarand-in-production-the-nitty...

You're of course unlikely to get the same read, but I find it crazy that their source of cryptographic entropy is on public display from the street!

agreed, it means the fluid-dynamics chaos in the lava lamps is useless for their cryptographic purposes

Not really. You can combine the public random source with a secret key. Since you assume they can keep secret a random source, they can equally keep this key secret. In fact, it's sometimes preferable to get rid of hardware source completely and only rely on a secret key and a state, and obtain a design that is more resistant to fault.

> I don’t think it has ever reappeared.

It resurfaced, much later.

https://en.wikipedia.org/wiki/RDRAND

The main application is cryptography. I am not aware of Monte Carlo simulations that use real random numbers. Plus, true RNGs are often biased, so in the end, you still have a PRNG, the true RNG only being used to inject some entropy.

> I am not aware of Monte Carlo simulations that use real random numbers.

Ray tracing? Any sampling bias can be incredibly obvious there.

RT should use low discrepancy sequences

Yeah. Sampling bias is fixed with Cranley Patterson rotation. For real time rendering, blue noise is the thing to use though. At low sample counts you can't converge so you should hide the error perceptually instead.

> So that idea got abandoned, and I don’t think it has ever reappeared.

I have no idea how old your story is... but in any case, there has been an update: Cloudflare is now using lava lamps as "random numbers as a service", and the idea isn't new either, SGI ran it in the late 90s [2].

[1] https://blog.cloudflare.com/randomness-101-lavarand-in-produ...

[2] https://en.wikipedia.org/wiki/Lavarand

"HotBits: Genuine random numbers, generated by radioactive decay", since 1996.

https://www.fourmilab.ch/hotbits/

Sadly:

    Consequently, the radioactively-generated HotBits server has been retired as of the end of 2022 (more precisely, at 00:00 UTC on 2023-01-01).

https://www.fourmilab.ch/hotbits/retired.html

The OG John Walker merch is still available though ...

https://www.fourmilab.ch/evilempire/

D'oh! Missed that when I was looking for the page. Thanks!

Still, it shows the idea did reappear. :)

It depends. For numerical simulations, you’ll want to generate true random numbers to check the robustness of your results. So using a CSPRNG/true random to obtain the seed is very useful. For debugging, you pick an injected seed to start with (+ print the production seed if a specific run had a problem and you want to debug). For cryptographic applications you want as secure a random seed into your CSPRNG as possible.

Reply on news.ycombinator.com