Hacker News Reader

Comment by sethhochberg | Hacker News Reader

Under the hood it’s just making calls to Math.random(), so the white noise generated is exactly as reliable a source of randomness as the system as the system could give you directly.

View on HN

Math.random() is a pragmatic PRNG with no strong guarantees and implementations vary. Focus on speed. OS can give more entropy if that's what matters

https://v8.dev/blog/math-random

I've seen visual demonstrations of PRNG bias before, but are the biases of typical implementations of Math.random "above the noise threshold" (pun intended) where humans could distinguish them from truly random streams of audio?

I don't think so, no. The way I understood op was to use the generated audio itself as a source of entropy, which would be a bad idea if not using a CSPRNG perfectly tuned to the sampling rate and lossless audio I think :) but I'm just guessing there regarding the effects of quality.

It’s at at most as good of a source but almost certainly worse. Lots of entropy dropped and biases introduced.

Very fair point. Transforming the randomness to fit it into the audible spectrum would certainly have side effects

>as reliable a source of randomness as the system as the system could give you directly

Not sure what you mean by this. Which system?

I thought that was the point GP’s comment is making, but a reply to a parallel comment to yours suggests otherwise.

The combination of the operating system (Linux/MacOS/Windows) and the particular hardware it has access to. With different hardware, /dev/(u)random has different qualities of entropy.

JS’s Math.random is not a system (or CS) RNG, and a few years back it was barely an RNG at all: https://medium.com/@betable/tifu-by-using-math-random-f1c308...

So no, Math.random is very much not

> as reliable a source of randomness as the system

that's horrifying. I do slightly disagree with the final thoughts and works say that one of the xoshiro 256 generators is probably better than the 1024 ones. 256 bits of state is plenty to give you a longer cycle length than you will ever need (even considering birthday paradox) and the reduced state means it fits in a single cache line

After the linked article as well as https://jandemooij.nl/blog/math-random-and-32-bit-precision/ which follows from it, the main three browsers (Chrome[0], Firefox[1], Safari[2]) actually switched to Xorshift128+. So these days Math.random is nowhere near as horrifying as it was back then, however it's still not a system or a userland CSPRNG, for that you need `crypto.getRandomValues()` (https://developer.mozilla.org/en-US/docs/Web/API/Crypto/getR...).

[0] https://v8.dev/blog/math-random

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=322529#c99

[2] https://bugs.webkit.org/show_bug.cgi?id=151641

Reply on news.ycombinator.com