151–160 of 214 posts
The root problem here is the notion that you need to choose between "strong and slow" randomness vs. "weak and fast" randomness. If every language's random() was strong and fast, most developers would never have to think about it. "Strong" randomness is often too slow because every time you ask for new entropy, you make a syscall. The solution is to use 32 bytes of strong randomness to seed a userspace CSPRNG. You ca…
Earlier quoted context omitted.
Most simulations, games, everything that isn't generating cryptography does not need security in it's random. For most domains secure random is a niche, not universally applicable.
Actually, in my experience using the default random implementation in games: * It's not fast enough. * It has patterns that can be seen if you are using it to, for instance, generate 2d noise. So for games you'd typically use, say, the Mersenne Twister [1], which is faster (amortized) and is distributed evenly across 623 dimensions. [2] It's not cryptographic, but it's far better for games. If you're not going to hav…
I used to be able to play about a dozen Pac-Man levels knowing exactly where every ghost was going to go and every bonus that was going to appear. And I wasn’t a very good player.
Pac-Man would have been a less fun game for many people if it used crypto grade random.
Earlier quoted context omitted.
And one would hope secure devs know which random to use, whereas gaming devs have no reason to know.
Look up “password generator” or similar terms on npm and take a look at how the packages you find generate random numbers. I did this ~5 years ago and it took until the second page of results before I found any packages that used a crypto-secure rng.
:facepalm:
Seriously.
Earlier quoted context omitted.
Most simulations, games, everything that isn't generating cryptography does not need security in it's random. For most domains secure random is a niche, not universally applicable.
So a simple linear generator is fine for an online poker game?
Is there something I am overlooking here? Randomness is used for many other things than cryptographic usages. Eg. for randomised algorithms you need a fast source of randomness.
Though normal random() implementations are LCGs which have poor distributions when you either only look at the least significant bits or project them into multiple dimensions.
As a result they may make some randomized algorithms perform poorly!
Earlier quoted context omitted.
> The cryptographic randomness has practically no downside if you use it for non-cryptogrpahic purposes Cryptographic randomness is typically slower than other forms of randomness. In all of the programming I've done in my career, I've only needed cryptographic randomness a few times. For the rest, a fast pseudorandom number generator seeded by the clock was the correct choice.
Inversely, in my career there's only been a handful of times where cryptographic randomness was too slow. I'd argue it's better to do the safe thing by default and switching to the faster alternative when you have proof you need it. Doing the fast thing by default and fixing security later is how we got Meltdown/Spectre.
Yeah, that's the opposite of my experience. Often the libc random is too slow and limiting performance and I need to substitute something even faster.
But I agree that using something that is securely random by default is a good idea. People can substitute faster thing fit for their purpose if needed.
Earlier quoted context omitted.
I genuinely don't see the reason why non-cryptographic random number generators exist outside of niche applications. The main arguments I've seen are speed and determinism. However, a cryptographically secure, deterministic PRNG can be built from hash or block cipher primitives that have hardware acceleration, making them quite fast. Seed (and potentially periodically re-seed) it from a strong source of randomness, a…
> I genuinely don't see the reason why non-cryptographic random number generators exist outside of niche applications. Because for well over 99.99% of developers, cryptography is a “niche application”. I’ve never written crypto code I’ve deployed anywhere. If I need crypto, I use the highest level crypto library I can find that people I trust who _do_ know about crypto recommend. The only time I ever recall non crypt…
Very few people set out to roll their own crypto. The issue in my experience is less about someone writing their own hand-optimized password hash function and more about people having overly-narrow views of what counts as security critical code.
Earlier quoted context omitted.
When it comes to optimization, there's a useful adage: make it work, then make it fast. Secure should really be seen as a necessary component of correct (and that it often isn't is a testament to the failure of our profession). In that vein, the default random should be cryptographically-secure, with all the logic necessary to actually effect that security (e.g., not reusing seeds after a call to fork). You can also…
>When it comes to optimization, there's a useful adage: make it work, then make it fast. When you need something to be fast, you better design it from the start to be fast. This is terrible advice for everything but some UI/web cases. Speed is a feature. Not every feature can be just 'added' to existing code without changing most of it. All of that is especially true for running simulations and the like. Whether thes…
I completely agree that things which need to be fast should be designed structurally to be fast.
But which RNG function you use in a given function is about as far you can get from an architectural decision. You shouldn't need to refactor large swathes of your codebase to accommodate a substitution of one random number generator for a faster one.
Earlier quoted context omitted.
This is exactly what I mean about being stuck in the C mindset. You're looking at the problem though the lens of what this giant pile of ancient C software does. Why should newer languages take the same approach to APIs that these old code bases did? It's not like we're porting all those programs to JS. Those C APIs were written long before hardware could provide fast good randomness, heck even before cryptography wa…
> If you want predictable "random" numbers, you should have to jump through additional hoops Why? > By default random numbers should be cryptographically secure. Why not both?
Because you're doing something that often causes major security bugs.
> Why not both?
It's not possible for random numbers to be both predictable and secure at the same time.