Use CSPRNG for Math.random()

[oerdnj]

What is the problem this feature will solve?

Copying from libuv/libuv#4872 (comment)

During the discussion about libuv changes, it was pointed out that Math.random() uses PRNG, and not CSPRNG. This is wrong because most people actually don't understand when they should use PRNG and when they should use CSPRNG. More on this in the above mentioned issue and also for example here: https://sortingsearching.com/2023/11/25/random.html

What is the feature you are proposing to solve the problem?

Using ChaCha20 would be a very conservative choice, but Jean-Philippe Aumasson (@veorq) argues that using ChaCha20 is actually waste of CPU cycles and using ChaCha12 would be fine both technically and socially, and using ChaCha8 would be also ok technically.

GoLang uses ChaCha8 (I would trust both Russ Cox and Filippo Valsorda on the choice), and Rust uses ChaCha12.

Since Math.random() doesn't claim it is CSPRNG, using ChaCha8 would be ok both technically and socially, and would be a great improvement over the currently used Xorshift-based PRNG.

I am offering ChaCha implementation in C licensed under MIT + whatever you need for the parts that I wrote, and I would be willing to implement this in C++. But that language is unfamiliar to me (you would have to kill me to say "C/C++"), so I am going to need some guidance here.

What alternatives have you considered?

No response

[ljharb]

Math.random in node should work the same as it does in every other engine, especially on the web. If you want a CSPRNG in the language, it'd need to be proposed to TC39. See also:

• https://github.com/tc39/proposal-seeded-random
• https://github.com/tc39/proposal-random-functions
• https://github.com/tc39/proposal-csprng

[oerdnj]

Math.random in node should work the same as it does in every other engine, especially on the web.

I honestly don't understand what you are trying to say. Are you saying that Math.random() requires the underlying algorithm in all implementations to be the same?

I am pretty much confused, because they way I understand this sentence is that someone might be relying on a characteristics of PRNG, which in fact means that PRNG is actually broken because it is not really random.

Random generator is either random or it is not, and it doesn't matter what the underlying implementation is.

If you want a CSPRNG in the language

No, that's not what I am proposing. I am only saying that the current implementation of PRNG is broken and should be replaced with something that's not broken.

[ljharb]

Not the underlying algorithm, but the overarching characteristics. There indeed might be code that relies on Math.random not being really random, which is why web browsers won't change the Math.random algorithm.

[oerdnj]

Not the underlying algorithm, but the overarching characteristics. There indeed might be code that relies on Math.random not being really random, which is why web browsers won't change the Math.random algorithm.

But Xorshift-based PRNGs are truly random. They are just not CSPRNGs because you can guess their internal state if you gather enough generated numbers.

[legendecas]

Math.random in node should work the same as it does in every other engine, especially on the web. If you want a CSPRNG in the language, it'd need to be proposed to TC39.

The algorithm of Math.random() in https://tc39.es/ecma262/#sec-math.random is said to be implementation defined. I think it is a misrepresentation to say that this needs conformance with every other engine and requires TC39 proposals.

The requirements from ECMA-262 is that Math.random() returns a uniformly distributed number in the range of [0, 1), and produce a different sequence of numbers in two realms.

However, I'm not advocating that we should provide a cryptography safe random number generator in the vein of Math.random(). It's not cryptography safe RNG on the web and changing it would encourage people to assume it is cryptography safe.

[oerdnj]

However, I'm not advocating that we should provide a cryptography safe random number generator in the vein of Math.random(). It's not cryptography safe RNG on the web and changing it would encourage people to assume it is cryptography safe.

Well, I am not proposing to change the function signature not to say it is now CSPRNG. I am simply advocating that using CSPRNG in the place of PRNG have advantages on their own.

I absolutely get your argument, but I would actually argue that it is not stopping people from using Math.random in places where CSPRNG is already required but misunderstood. Implementing CSPRNG would actually bump the security level and prevent future security issues implicitly.

[jasnell]

Strictly speaking we can back Math.random() with a CSPRNG but I do share @ljharb's concern about the consistency issue. If Node.js made Math.random() CSPRNG backed but other runtimes do not, then users can easily get tripped up when writing code that needs to be back by multiple runtimes. It's safer to use an API that is guaranteed to be CSPRNG backed (like node:crypto's randomInt(n) or Web crypto's getRandomValues().

[oerdnj]

It's safer to use an API that is guaranteed to be CSPRNG backed (like node:crypto's randomInt(n) or Web crypto's getRandomValues().

Absolutely (if these are CSPRNG).

then users can easily get tripped up when writing code that needs to be back by multiple runtimes.

How would this happen if you don’t say that?

Is there any other node.js specific documentation rather than https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Math/random because I can’t find it.

I mean do you truly believe that people will study a specific implementations of Math.random() and make decisions based on this rather than adhering to the big fat note saying:

Note: Math.random() does not provide cryptographically secure random numbers. Do not use them for anything related to security. Use the Web Crypto API instead, and more precisely the Crypto.getRandomValues() method.