undefined | Better HN

0 pointspclmulqdq1y ago0 comments

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.

0 comments

kbolino1y ago

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.

Retr0id1y ago

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.

kibwen1y ago

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

kbolino1y ago

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.

1 more reply

pclmulqdqOP1y ago

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.

j / k navigate · click thread line to collapse

0 comments

kbolino1y ago

Retr0id1y ago

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.

kibwen1y ago

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

kbolino1y ago

1 more reply

pclmulqdqOP1y ago

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

j / k navigate · click thread line to collapse