Hacker News new | ask | show | jobs
by pclmulqdq 796 days ago
RNG vulnerabilities are usually really bad in terms of the systems they compromise. It often means exposure of keys, huge numbers of jailbroken devices, or something similar. Making at most tens of thousands of dollars in Minecraft with one is sort of cute and fun in comparison.

Of course, I could be underestimating this by a lot.

1 comments

This is a bug in how Minecraft does things, not a bug in the generator itself (which has long been known to be vulnerable to such things).
If "random" implies "contains no information", then it is indeed a bug in anything calling itself a "random number generator".

But that's just my opinion. The world is free to use the word however it wants.

“Random” means something closer to “contains maximal information”…
One way of thinking about it is that each bit has maximal information because knowing the entire previous history should give you no information about what the next bit will be ahead of it being revealed.
Yeah, there is a big class of "RNG bugs" where someone uses a non-cryptographic RNG for secure things, not realizing that those things are supposed to be secure.

The classic example of these is a password manager that gave out recovery codes using a PRNG. This is in that class.

While a CSPRNG would have solved this problem, it also would've created a new one: much slower chunk loading and random item placement, which would have greatly slowed down the game simulation, and thus tanked framerate and playability. As it turns out, the right solution is to use multiple, isolated non-cryptographic random number generators with distinct state. That way, even though you can guess the state of one of them, it doesn't give you any insight into the others.
Modern CSPRNGs can generate numbers at GB/s, I find it hard to believe it would slow the game down in a measurable way.

The "right" solution you describe sounds overcomplicated and error-prone (now you need to think carefully about which domains are separated) compared to just using a CSPRNG.

> The "right" solution you describe sounds overcomplicated and error-prone

It's not particularly. At program start-up, you seed the original PRNG. Then, you generate N numbers from the original PRNG and use those to seed N other PRNGs, then throw away the original PRNG. You don't need to think carefully about domains, you just create a new PRNG for everything you need a random number for. This makes your game easier to debug in a deterministic way, because now reproducing the behavior of one specific action that involves randomness no longer depends on every other action that involves randomness.

We may be at the point where CSPRNGs are viable for video game randomness, but that wasn't the case 10+ years ago especially when factoring in compatibility with 20-year-old hardware (high-end PCs from ca 2004 could play Minecraft).

Even so, a non-crypto PRNG can generally compute a new random number in 2-4 ALU ops. With SIMD optimization, that can amortize to under 1 cycle per byte, which means it takes under a nanosecond to generate a new 32-bit number. I'm not sure even the best hardware-accelerated CSPRNG on modern hardware can quite say the same just yet.

chacha12, a construction that's been around in one form or another since the '00s, runs at well under 1 cycle per byte on good hardware and still plenty fast on "bad" hardware https://bench.cr.yp.to/results-stream.html (iiuc just using SIMD, no special acceleration)

But it doesn't really matter what things were like when the code was first written, it's about how it could be fixed in the present.

The problem of dealing with randomness is about figuring out how to use CSPRNGs (and TRNGs) as little as possible, but not too little. CSPRNGs can get to a couple of GB/sec on a core, so they're not all that bad, but non-secure PRNGs are over an order of magnitude faster. I would assume that most of those things (eg chunk generation/loading) don't need secure RNG at all.

Sharding your RNGs by player is also an option for some games, and can be easier.