Bad source of random and bugs

[Sc00bz]

I found these problems with the code:

• Math.random is a bad source of random.
• rawprng() can return NaN.
• random.done() can cause use after free type bugs.
• In random.random(), Number.MAX_VALUE is not what you think it is.
• random(), random.range(), random.intBetween(), and random.random() are not evenly distributed.
• This is clearly not a CSPRNG. You should remove the "UHEPRNG" code and replace it with Node's crypto.randomBytes and if a seed is given just do something like key = H(seed); counter = 0; for seeding, key = H(key + "-" + entropy) for adding entropy, and key = H(key + counter++); return H(key); for random data. H() being a cryptographic hash function like SHA256 or a KDF like HKDF. This will be vastly superior.

[Sc00bz]

I decided to write this (https://github.com/Sc00bz/break-uheprng) to show how broken UHEPRNG is.

[skratchdot]

Thanks for taking the time to provide all this information! I hope I didn't suggest this was a CSPRNG (as I wouldn't know enough to prove or disprove it). The repo you pointed to looks very informative. It's concerning that I could receive a NaN at times.

I published this module years ago b/c I needed a seeded random generator in node, and I found https://www.grc.com/otg/uheprng.htm which wasn't yet published on npm (so figured I'd give people a way to easily install it).

I've only used this lib for mocking Math.random() in unit tests, and for generative art type projects.

Hopefully other people will find your link informative as well.

It might be useful someday to update the README of this project w/ a list of other seeded random number generators.

[Sc00bz]

In the original UHEPRNG code it is stated as a "cryptographically strong PRNG".

Fixing the NaN problem is easy. Move the return line in mash() to the end of the function:

-			return (n >>> 0) * 2.3283064365386963e-10; // 2^-32
		} else n = 0xefc8249d;
+		return (n >>> 0) * 2.3283064365386963e-10; // 2^-32

[skratchdot]

Interesting. I did read the license when I originally published it (but had forgotten that line). Now my concern is making changes that might break things for people who are solely relying on this for unit tests and the like. I guess that's what semver is for though.

Again, I appreciate your time and info.

At the very least I need to update the readme with alternatives and more info about your findings.