5 ms·

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 =

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.getRandomValues(...) Java has SecureRandom: http://docs.oracle.com/javase/6/docs/api/java/security/SecureRandom.html http://docs.oracle.com/javase/6/docs/api/java/security/Secur...

Osmium 12y ago
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?
- sgift 12y ago
  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.
  - jonahx 12y ago
    True, although honestly your tongue-in-cheek enum example is probably closer to where the line should be.
    - cornewut 12y ago
      Also a nice reminder: "Never write your own crypto"
      - eru 12y ago
        (Outside of education.)
- imaginenore 12y ago
  Because 1) Even SecureRandom is likely not completely random. Unless they seed with physical/unpredictable randomness. 2) It's much slower
  - pkolaczk 12y ago
    > 1) Unless they seed with physical/unpredictable randomness. They do.
- MichaelGG 12y ago
  Why not rename comparison functions, too, since they often aren't constant time? And all sorts of other primitives someone might accidentally use?
SeanLuke 12y ago
> 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/ 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 compatibility" (in an RNG!) > If you want cryptographic-quality random numbers I think you're confusing "crytographic-quality" with "high quality". RNGs tend to break down into two different camps. First, there are RNGs meant for simulation of stochastic processes. These RNGs need to be fast, have good periods, and have a very high degree of statistical randomness in their output. Second, there are RNGs meant for crypto. Speed is less important. Rather it's important that these RNGs provide good statistical randomness, but also it's crucial that, given some M previous output numbers of the RNG, you cannot predict or make any statistical claims about the next number even if you know how the algorithm works. This isn't important for non-crypto RNGs. For example, Mersenne Twister is a pretty high quality, widely used RNG. But it is not cryptographically secure: if you have about 1500 of the previous output numbers, you can perfectly predict the next number if you know it's MT producing them. While there are many applications for crypto RNGs, for a great many tasks, a non-crypto RNG would be a better fit. java.util.Random was meant for non-crypto tasks. And it completely fails at even those tasks. But SecureRandom is really bad for those tasks too: it is slow. For example, my MersenneTwister implementation is about 9 times faster than SecureRandom; and my non-threadsafe MT implementation is about 36 times faster. That's a big deal if you're pulling down millions and millions of numbers.
- TheLoneWolfling 12y ago
  > 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 important things). That being said, things like this are why I wish more programming languages had proper (read: fine-grained) versioning of libraries. "I need to link to a function with this signature, that is one of these versions or any version that has been declared to be compatible with them, preferably the latest version that is so". That sort of thing. > For example, Mersenne Twister is a pretty high quality, widely used RNG. But it is not cryptographically secure... But SecureRandom is really bad for those tasks too: it is slow. For example, my MersenneTwister implementation is about 9 times faster than SecureRandom By your own words, you're comparing apples to oranges here...

Osmium 12y ago

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?

sgift 12y ago
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.
- jonahx 12y ago
  True, although honestly your tongue-in-cheek enum example is probably closer to where the line should be.
  - cornewut 12y ago
    Also a nice reminder: "Never write your own crypto"
    - eru 12y ago
      (Outside of education.)
imaginenore 12y ago
Because 1) Even SecureRandom is likely not completely random. Unless they seed with physical/unpredictable randomness. 2) It's much slower
- pkolaczk 12y ago
  > 1) Unless they seed with physical/unpredictable randomness. They do.
MichaelGG 12y ago
Why not rename comparison functions, too, since they often aren't constant time? And all sorts of other primitives someone might accidentally use?

SeanLuke 12y ago

> 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/ 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 compatibility" (in an RNG!) > If you want cryptographic-quality random numbers I think you're confusing "crytographic-quality" with "high quality". RNGs tend to break down into two different camps. First, there are RNGs meant for simulation of stochastic processes. These RNGs need to be fast, have good periods, and have a very high degree of statistical randomness in their output. Second, there are RNGs meant for crypto. Speed is less important. Rather it's important that these RNGs provide good statistical randomness, but also it's crucial that, given some M previous output numbers of the RNG, you cannot predict or make any statistical claims about the next number even if you know how the algorithm works. This isn't important for non-crypto RNGs. For example, Mersenne Twister is a pretty high quality, widely used RNG. But it is not cryptographically secure: if you have about 1500 of the previous output numbers, you can perfectly predict the next number if you know it's MT producing them. While there are many applications for crypto RNGs, for a great many tasks, a non-crypto RNG would be a better fit. java.util.Random was meant for non-crypto tasks. And it completely fails at even those tasks. But SecureRandom is really bad for those tasks too: it is slow. For example, my MersenneTwister implementation is about 9 times faster than SecureRandom; and my non-threadsafe MT implementation is about 36 times faster. That's a big deal if you're pulling down millions and millions of numbers.

TheLoneWolfling 12y ago
> 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 important things). That being said, things like this are why I wish more programming languages had proper (read: fine-grained) versioning of libraries. "I need to link to a function with this signature, that is one of these versions or any version that has been declared to be compatible with them, preferably the latest version that is so". That sort of thing. > For example, Mersenne Twister is a pretty high quality, widely used RNG. But it is not cryptographically secure... But SecureRandom is really bad for those tasks too: it is slow. For example, my MersenneTwister implementation is about 9 times faster than SecureRandom By your own words, you're comparing apples to oranges here...