Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Predicting the next Math.random() in Java

franklinta.com

Post reply on HN
Print view View original

41–50 of 58 posts

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

#41

Post by TheLoneWolfling »

SeanLuke wrote: post #37
TheLoneWolfling wrote: post #27

Earlier quoted context omitted.

> There are other serious bugs in java.util.Random which Sun, er, Oracle, has steadfastly refused to fix or revise for a decade now due to concerns about "backward compatibility" (in an RNG!) Backward compatibility in a RNG is actually rather important, weirdly enough. For example, anything that uses deterministic seeds for repeatability of procedural generation or optimization. (Read: Minecraft, among other more imp…

> Backward compatibility in a RNG is actually rather important, weirdly enough. For example, anything that uses deterministic seeds for repeatability of procedural generation or optimization. (Read: Minecraft, among other more important things). This seems like a very, very bad thing to rely on. Other than Java, how many other languages have guarantees in generator determinism from version to version as part of the l…

If it's specified, I don't mind people relying on it. That being said, Java is over-specified in many ways, this potentially being one of them.

I know Python does not have this guarantee.

Personally? There should really be a couple different RNGs in Java's standard library - all combinations that make sense of [insecure/secure, can set seed / can't set seed, thread-local/global] (local/global being without distinction if one cannot set the seed). The default being secure / can't set seed.

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

#42

Post by xxs »

banthar wrote: post #21
UnoriginalGuy wrote: post #9

Earlier quoted context omitted.

Those likely won't be vulnerable even if they implemented their site using the insecure random function. The reason why this works is that you're the only consumer of Java-randomness, as you add additional consumers it becomes infinitely more difficult. Consumers also don't need to be users, AI players and cards dealt will also consume randomness. You would also need to know the mapping from the random output into th…

This more probable than you think. Java code is likely to use Collections.shuffle(). That method uses internal Random which is used only for shuffling. Shuffling is unlikely to be used for other purposes than shuffling cards. There isn't that many ways to shuffle them either.

shuffle does allow specifying a j.u.Random as second parameter. If you don't use SecureRandom when you have to, it's your own fall.

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

#43

Post by michaelt »

SeanLuke wrote: post #37
TheLoneWolfling wrote: post #27

Earlier quoted context omitted.

> There are other serious bugs in java.util.Random which Sun, er, Oracle, has steadfastly refused to fix or revise for a decade now due to concerns about "backward compatibility" (in an RNG!) Backward compatibility in a RNG is actually rather important, weirdly enough. For example, anything that uses deterministic seeds for repeatability of procedural generation or optimization. (Read: Minecraft, among other more imp…

> Backward compatibility in a RNG is actually rather important, weirdly enough. For example, anything that uses deterministic seeds for repeatability of procedural generation or optimization. (Read: Minecraft, among other more important things). This seems like a very, very bad thing to rely on. Other than Java, how many other languages have guarantees in generator determinism from version to version as part of the l…

Any language that allows the PRNG to be manually seeded, presumably?

I mean, if manually seeding the PRNG doesn't produce a deterministic result, you wouldn't make it part of the API.

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

#44

Post by pkolaczk »

imaginenore wrote: post #23
Osmium wrote: 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?

Because 1) Even SecureRandom is likely not completely random. Unless they seed with physical/unpredictable randomness. 2) It's much slower

> 1) Unless they seed with physical/unpredictable randomness.

They do.

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

#45

Post by gleenn »

MichaelGG wrote: post #30
SeanLuke wrote: post #24

Earlier quoted context omitted.

> Math.random() is simply a super-fast decent RNG Actually, java.util.Random is a horrible, horrible RNG. Its least significant bit (for example) is grotesquely nonrandom. See http://www.alife.co.uk/nonrandom/ for a wonderful demonstration of its awfulness. There are other serious bugs in java.util.Random which Sun, er, Oracle, has steadfastly refused to fix or revise for a decade now due to concerns about "backward…

How did Java and up with such a poor implementation? Certainly these things were known when writing that library?

I remember reading they pulled the implementation almost straight out of TAOCP, from good old Donald Knuth (if that's enough of a name drop). It might not be great, but at least it was from a reasonably respectable, academic source and not copy-pasta'd out of stackoverflow.

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

#46

Post by MrBuddyCasino »

jonahx wrote: post #17
drinchev wrote: post #3

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

This has happened in the past. Interesting read: http://www.cigital.com/papers/download/developer_gambling.ph...

If one were to use such tactics to make money - would that be considered "hacking" and be illegal?

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

#47

Post by SeanLuke »

michaelt wrote: post #43
SeanLuke wrote: post #37

Earlier quoted context omitted.

> Backward compatibility in a RNG is actually rather important, weirdly enough. For example, anything that uses deterministic seeds for repeatability of procedural generation or optimization. (Read: Minecraft, among other more important things). This seems like a very, very bad thing to rely on. Other than Java, how many other languages have guarantees in generator determinism from version to version as part of the l…

Any language that allows the PRNG to be manually seeded, presumably? I mean, if manually seeding the PRNG doesn't produce a deterministic result, you wouldn't make it part of the API.

Nope.

Essentially all languages allow manual seeding: almost none specify guarantees with regard to RNG behavior. I'm pretty sure this is because determinism of a given process important (everyone who does simulation needs that), but locking into potentially bad RNGs for the language or library itself, in fact specifying them, is a really bad idea.

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

#48

Post by ivanche »

banthar wrote: post #21
UnoriginalGuy wrote: post #9

Earlier quoted context omitted.

Those likely won't be vulnerable even if they implemented their site using the insecure random function. The reason why this works is that you're the only consumer of Java-randomness, as you add additional consumers it becomes infinitely more difficult. Consumers also don't need to be users, AI players and cards dealt will also consume randomness. You would also need to know the mapping from the random output into th…

This more probable than you think. Java code is likely to use Collections.shuffle(). That method uses internal Random which is used only for shuffling. Shuffling is unlikely to be used for other purposes than shuffling cards. There isn't that many ways to shuffle them either.

I worked for 6 years in a company which makes online (gambling) games. I can tell you that anyone who even thinks of using Collections.shuffle() for shuffling cards in production code is an amateur.

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

#49

Post by prawks »

cdwhite wrote: post #40
TheLoneWolfling wrote: post #27

Earlier quoted context omitted.

> There are other serious bugs in java.util.Random which Sun, er, Oracle, has steadfastly refused to fix or revise for a decade now due to concerns about "backward compatibility" (in an RNG!) Backward compatibility in a RNG is actually rather important, weirdly enough. For example, anything that uses deterministic seeds for repeatability of procedural generation or optimization. (Read: Minecraft, among other more imp…

Also, when you're writing scientific code (Monte Carlo simulations, for example, or disordered systems), the folk wisdom is that you must to keep track of what seed you used. I've never had to use these records myself, but I can image wanting to go back and reproduce exactly the same calculation, for (e.g.) debugging or verifying new code. Now you think about resurrecting some previous grad student's code that only w…

Couldn't you solve this by tracking the version of Java (for example) used initially to develop the simulation?

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

#50

Post by lmm »

prawks wrote: post #49
cdwhite wrote: post #40

Earlier quoted context omitted.

Also, when you're writing scientific code (Monte Carlo simulations, for example, or disordered systems), the folk wisdom is that you must to keep track of what seed you used. I've never had to use these records myself, but I can image wanting to go back and reproduce exactly the same calculation, for (e.g.) debugging or verifying new code. Now you think about resurrecting some previous grad student's code that only w…

Couldn't you solve this by tracking the version of Java (for example) used initially to develop the simulation?

Sure, but it kind of sucks if your whole program has to remain on Java 1.3 forever because you need a particular RNG.
Post reply on HN