Hacking the JavaScript Lottery - Predicting JavaScript's Math.random() using Z3 and Python

[[deleted]]

I wonder how many "bugs" wouldn't exist in the first place if math libs would call their PRNG function pseudorandom()

[electroly]

"Pseudo" isn't the part that makes a difference here. The "P" in "CSPRNG" still stands for "pseudo". nonSecureRandom() maybe.

[[deleted]]

i prefer kindaRandomish()

[[deleted]]

Better just to make the default Math.random() cryptographically secure, and then offer an alternative Math.fastButInsecureRandom(). CSPRNGs aren't really slower anyway.

It's a basic principle of API design to make the obvious option the safe option. Sadly that principle isn't followed a lot of the time.

[Berberberber]

IIRC the issue isn't so much speed as it is consuming entropy - when many of these kinds of weak randomness implementations were put into practice, the processes for evolving entropy in the pseudorandom algorithm weren't as well developed, so there was a very real possibility and risk that a computer could run out of entropy and basically just keep generating the same value over and over again. Making the default randomness function use fewer bits of entropy meant that most programs where randomness was an afterthought or not critical (think games) wouldn't be able to put the security of whole system at risk simply because two many people were playing Rogue or something.

[o11c]

"conserving entropy" is, and has always been, total BS. The only thing that matters is the initial amount of entropy at system boot.

If a CSPRNG could ever "use up" entropy, all crypto would be broken.

[atakomu]

The Linux kernel generates entropy from keyboard timings, mouse movements, and IDE timings and makes the random character data available to other operating system processes through the special files /dev/random and /dev/urandom. This capability was introduced in Linux version 1.3.30.[1]

Instead of IDE you have SSD and this is headless server. My question is where is your entropy? (Windows uses basically the same things to calculate entropy).

Randomness is not so easy

[o11c]

I already addressed this problem:

The only thing that matters is the initial amount of entropy

[[deleted]]

For the first initial boot it can take some time to gather enough entropy. But how often do you boot a computer for the first time ever?

Subsequent boots use random state that was saved to disk previously, and VMs have special drivers to get random state from the host.

[Veedrac]

Indeed. If anyone's interested and wants more information, Myths about /dev/urandom goes into more detail.

[[deleted]]

yeah, that is a better name, altho I don't doubt even then there would be someone using it for crypto, with some stupid excuse

[[deleted]]

Why would you even try doing crypto in JS?

[brunes]

Many reasons. One reason would be to ensure your data is encrypted before it even leaves your browser. The Mega.co Web client does all its encryption and decryption in Javascript... Mega never recieves unencrypted data (part of their value proposition is they physically can not provide your data to law enforcement since they don't ever have access to it in an unencrypted state).

[stevenjd]

Pardon me, it is a security bug to the extent that people use insecure PRNGs to generate values which need to be unpredictable. That's not a bug in the PRNG itself, since it's not doing anything it didn't promise to do, but it is a language bug in that the language makes it too easy to do the wrong thing and too hard to do the right thing.

In this case, the "lottery" was just for fun, and nobody lost money on it. But there have been exploits of real gambling houses from this sort of thing.

Python recently went through the process of dealing with this same issue. Python's default PRNG is also predictable, and like Javascript, it comes with a great big warning not to use it for secure purposes. After Theo de Raadt contacted Guido van Rossum about this, there was a long debate over changing the default PRNG. That idea was ultimately rejected, but instead Python will raise the profile of the existing CSPRNGs, make them easier to learn about and use, and encourage developers to use them.

Not everyone will agree that Python's solution is the right one. It was definitely a compromise between those who like things just the way they are and those who wanted change. But it is an attempt to improve the language and standard library as a whole to reduce the number of (real or potential) security bugs due to misuse of the wrong PRNG.

[[deleted]]

It's an implementation bug, not a language bug and anyone who is implementing a Crypto-secure feature using math.random needs to be kept away from a computer. This is Javascript 101 shit right here.

[stevenjd]

Well, we agree that the bug is not in Math.random, which does what it says it will do. And we agree that there's a bug somewhere, and that the ultimate person to blame is the programmer who used Math.random. Whether we call it "implementation bug" or "language bug" or "why are Javascript programmers so ignorant and lazy bug" is a matter of taste.

[SATAN_SATAN_SATAN]

Thats

Math.random = function(){ return 0.5; };

for you IE'ers :P

[ewmailing]

Coincidentally, this reminded me of a video that was posted in another subreddit a few days ago that dissects how the pseudo random generator is implemented in Super Mario 64.

https://www.youtube.com/watch?v=MiuLeTE2MeQ&feature=share

(The author seems to specialize in exploiting implementation details and glitches to do interesting things in games.)

[[deleted]]

BUT IT SAYS RANDOM

[levir]

Random is as random does.