Skip to main content
2 of 9
small grammar fix, added link to floating point standard
forest
  • 67.3k
  • 20
  • 218
  • 280

Why is Math.random() not designed to be cryptographically secure?

The JavaScript Math.random() function is designed to return a floating point value between 0 and 1. It is widely known (or at least should be) that the output is not cryptographically secure. Most modern implementations use the XorShift128+ algorithm which can be easily broken. As it is not uncommon for people to mistakenly use it when they need better randomness, why do browsers not replace it with a CSPRNG? I know that Opera does that, at least. The only reasoning I could think of would be that XorShift128+ is faster than a CSPRNG, but on modern (and even not so modern) computers, it would be trivial to output hundreds of megabytes per second using ChaCha8 or AES-CTR. These are often fast enough that a well-optimized implementation may be bottlenecked only by the system's memory speed. Even an unoptimized implementation of ChaCha20 is extremely fast on all architectures, and ChaCha8 is more than twice as fast.

I understand that it could not be re-defined as a CSPRNG as the standard explicitly gives no guarantee of suitability for cryptographic use, but there seems to be no downside to doing it anyway. It would reduce the impact of bugs in a large number of web applications without violating the standard (it only requires that the output be round-to-nearest-even IEEE 754 floating point numbers), decreasing performance, or breaking compatibility with web applications.

forest
  • 67.3k
  • 20
  • 218
  • 280