Hacker News new | ask | show | jobs
by twotwotwo 960 days ago
It's fun it's exactly 1:1 and you don't need any more output than the state!

It's sort of sad it isn't all AES-CTR or ChaCha12. Fast enough not to be the bottleneck in your webpage, and if you find any hint of a pattern in the output, good news, you get to publish a paper on it!
2 comments
kevincox 960 days ago
If you need secure random values you should be using https://developer.mozilla.org/en-US/docs/Web/API/Crypto/getR.... Absolutely do not use `Math.random` for anything requiring security.
link
twotwotwo 960 days ago
Sorry, to clarify, I know CSPRNG APIs are exposed and what you use for safe randomness.

What I'm saying is that outside rare, extreme situations--maybe some HPC Monte Carlo simulation where you need gobs of randomness--you might as well use strong primitives for all your randomness, because they work well and are now plenty cheap for the use case with hardware support, etc.

The games to find a fast non-cryptographic function that passes enough statistical tests, etc., don't make as much sense to me when cryptographic randomness costs a few cycles a byte. There is not much upside to every standard library exposing a bad random generator that we have to warn people not to use. The handful of people that really need xorshift128+ can figure something out.

Maybe still a position you disagree with, but at least clearer without the sarcastic gloss.

link
azeemba 960 days ago
The intention is that web.crypto is used when reversing should be difficult.

The goal for Math.random is to have much lower memory and speed impact. You can certainly disagree with their priorities but given those priorities, it makes sense to go with a much simpler algorithm that can be reversed easily.

link
twotwotwo 960 days ago
Sorry, I know you should be using a CSPRNG API for cryptography, and probably my glib phrasing there obscured that.

I'm saying the cost of running actual cryptographic primitives has dropped a ton over time: on computers from decades ago a cheaper flavor of pseudorandomness was clearly necessary, now hardware AES is very cheap. And webpages aren't typically massive doing HPC simulations or other things that will be bound by the PRNG taking a few cycles per byte.

So the memory/CPU benefit of keeping the bad PRNG around is not obviously still worth it to me. In your words, I think I disagree with their priorities, particularly because the cost savings are not what they used to be.

link