Live data from Hacker News

Predicting the next Math.random() in Java

franklinta.com

11–20 of 58 posts

Re: Predicting the next Math.random() in Java

#11
post #7
post #3

How dangerous this prediction can be? I can't stop thinking of java-backended real money, poorly written, gaming websites.

Real random numbers are useless because everything follow some distribution. Actually random generators in programming languages should be called pseudorandom to avoid confusions.

By that logic nothing should ever be called random (in any context). There are things we can measure but don't understand the source of the entropy, but they aren't random we just haven't figured out the source yet. Most things we consider random are quantifiable and predictable with enough data (be it nature or computers).

Plus there are several definitions of the term "random" (English) which are in-line with the programming usage such as "random: a haphazard course."

Re: Predicting the next Math.random() in Java

#12
post #7
post #3

How dangerous this prediction can be? I can't stop thinking of java-backended real money, poorly written, gaming websites.

Real random numbers are useless because everything follow some distribution. Actually random generators in programming languages should be called pseudorandom to avoid confusions.

> Real random numbers are useless because everything follow some distribution.

First, real random numbers are quite valuable. Second, yes, all numerical sequences follow a distribution, but one of those distributions is called the "normal distribution", and I think you may be able to guess what that refers to.

> Actually random generators in programming languages should be called pseudorandom to avoid confusions.

It would have been useful to explain the difference between the terms random and pseudorandom. "Pseudorandom" doesn't necessarily mean easily predictable or flawed, it means the sequence results from a deterministic algorithm and can be recreated exactly by restarting the generator with the same seed value.

Re: Predicting the next Math.random() in Java

#13

If you want cryptographic-quality random numbers, both Java and Javascript have them. Math.random() is simply a super-fast decent RNG. Example: var buf = new Uint32Array(10); window.crypto.getRandomValues(buf); console.log(buf); Outputs things like: [4027145128, 258543382, 1205615760, 2665675208, 4033127244, 2280027866, 3983484449, 510932333, 1911490534, 2609399642] This works in Chrome and FF. IE11 has Crypto.getRan…

Devil's advocate, but why not rename "Random" to "AlmostRandom" instead, and call "SecureRandom" just "Random"? It's not unreasonable for a lay programmer to expect "random" to be exactly that; though, obviously, non-experts shouldn't be implementing crypto regardless. But since they will, despite everyone's best advice otherwise, why not reduce their chances of introducing bugs?

Re: Predicting the next Math.random() in Java

#14
post #13

If you want cryptographic-quality random numbers, both Java and Javascript have them. Math.random() is simply a super-fast decent RNG. Example: var buf = new Uint32Array(10); window.crypto.getRandomValues(buf); console.log(buf); Outputs things like: [4027145128, 258543382, 1205615760, 2665675208, 4033127244, 2280027866, 3983484449, 510932333, 1911490534, 2609399642] This works in Chrome and FF. IE11 has Crypto.getRan…

Devil's advocate, but why not rename "Random" to "AlmostRandom" instead, and call "SecureRandom" just "Random"? It's not unreasonable for a lay programmer to expect "random" to be exactly that; though, obviously, non-experts shouldn't be implementing crypto regardless. But since they will, despite everyone's best advice otherwise, why not reduce their chances of introducing bugs?

How far do you want to go? The Javadocs state it plain and clear that this is not cryptographically secure. Is AlmostRandom enough? Maybe we should force people to set an enum? new AlmostRandom(AlmostRandomCertification.YES_I_M_NOT_AN_IDIOT_AND_WONT_USE_THIS_FOR_CRYPTOGRAPHIC_PURPOSES)? You have to draw the line somewhere.

Re: Predicting the next Math.random() in Java

#15
post #14
post #13

Earlier quoted context omitted.

Devil's advocate, but why not rename "Random" to "AlmostRandom" instead, and call "SecureRandom" just "Random"? It's not unreasonable for a lay programmer to expect "random" to be exactly that; though, obviously, non-experts shouldn't be implementing crypto regardless. But since they will, despite everyone's best advice otherwise, why not reduce their chances of introducing bugs?

How far do you want to go? The Javadocs state it plain and clear that this is not cryptographically secure. Is AlmostRandom enough? Maybe we should force people to set an enum? new AlmostRandom(AlmostRandomCertification.YES_I_M_NOT_AN_IDIOT_AND_WONT_USE_THIS_FOR_CRYPTOGRAPHIC_PURPOSES)? You have to draw the line somewhere.

True, although honestly your tongue-in-cheek enum example is probably closer to where the line should be.

Re: Predicting the next Math.random() in Java

#16
post #6
post #3

How dangerous this prediction can be? I can't stop thinking of java-backended real money, poorly written, gaming websites.

It's well known. If someone is doing anything with real money, and isn't doing something more secure than this, they've already been hacked, are already out of business, and are already not allowed to write code that deals with real money.

This is a convenient but flawed argument that assumes an equilibrium. Hacking is often (mostly?) about vulnerabilities that change over time.

Re: Predicting the next Math.random() in Java

#18
post #3

How dangerous this prediction can be? I can't stop thinking of java-backended real money, poorly written, gaming websites.

It has happened before!

See http://www.cigital.com/papers/download/developer_gambling.ph... for a very detailed explanation of how one figured out all the cards in Texas hold-em.

Re: Predicting the next Math.random() in Java

#20
post #15
post #14

Earlier quoted context omitted.

How far do you want to go? The Javadocs state it plain and clear that this is not cryptographically secure. Is AlmostRandom enough? Maybe we should force people to set an enum? new AlmostRandom(AlmostRandomCertification.YES_I_M_NOT_AN_IDIOT_AND_WONT_USE_THIS_FOR_CRYPTOGRAPHIC_PURPOSES)? You have to draw the line somewhere.

True, although honestly your tongue-in-cheek enum example is probably closer to where the line should be.

Also a nice reminder: "Never write your own crypto"
Post reply on HN