3 ms·

It does but it does not! java.util.Random is not a CSPRNG at all and is terrible, so even tho the nextInt() method is using rejection sampling, it's still produ

It does but it does not! java.util.Random is not a CSPRNG at all and is terrible, so even tho the nextInt() method is using rejection sampling, it's still producing biased values and also completely fails to be "unpredictable" because java.util.Random is weak and predictable.

deleted 4y ago
[deleted]
brazzy 4y ago
That's why we have public class SecureRandom extends Random
the_af 4y ago
Interesting! How come this wasn't fixed? Nobody noticed, or is it that java.util.Random is not meant for serious cryptographic use? I know there are other parts of the Java standard lib that are so terrible [1] that people for years have recommended not using them, like anything with dates and timezones... --- [1] or used to, haven't kept up with the latest Java versions. Maybe they fixed it.
- anomalroil 4y ago
  As you said: Java's Random is not meant for serious cryptographic usage, it's meant to be super fast. You have SecureRandom instead for cryptographic usage, and it's noticeably slower. Interestingly, using fast, but bad random generators such as Java's Random was shown to be an issue multiple times in the past already for things such as Monte Carlo, and so on, not just for things related to security.
- edflsafoiewq 4y ago
  The contract of Random requires determinism, so the algorithm can never be changed. > If two instances of Random are created with the same seed, and the same sequence of method calls is made for each, they will generate and return identical sequences of numbers. In order to guarantee this property, particular algorithms are specified for the class Random. Java implementations must use all the algorithms shown here for the class Random, for the sake of absolute portability of Java code
- brazzy 4y ago
  > is it that java.util.Random is not meant for serious cryptographic use? Indeed it never was. SecureRandom (a subclass of Random in a different package, grouped with other cryptography related functionality) was introduced in Java 1.1 in 1997. > I know there are other parts of the Java standard lib that are so terrible [1] that people for years have recommended not using them, like anything with dates and timezones... The original Java date classes (also from the 1.1 era) were functional and correct, but badly designed. A modern time API was introduced in Java 8 in 2014.
  - the_af 4y ago
    > The original Java date classes (also from the 1.1 era) were functional and correct, but badly designed. A modern time API was introduced in Java 8 in 2014. I'm pretty sure they were neither correct nor functional. I've read pretty detailed examples of everything they got fundamentally wrong, which was a lot. Wrong, not as "this is cumbersome to use" but as in "this fundamentally misunderstands what dates are at a conceptual level, and produces wrong results". Unfortunately, I would have to google it now. All I can find right now is Jon Skeet's summary [1], which leans more to the "avoid using java.util.Date because it's one giant pitfall" side of the argument. Though it does mention some fundamental problems with it. However, this is not the article I found back in the day, which was both more comprehensive and more critical. > A modern time API was introduced in Java 8 in 2014. I seem to remember even at that time people were still not recommending Java standard date classes and functions, but I may be misremembering. Or were all the replacements like joda time from a previous era? --- [1] https://codeblog.jonskeet.uk/2017/04/23/all-about-java-util-date/ https://codeblog.jonskeet.uk/2017/04/23/all-about-java-util-...
    - kelnos 4y ago
      > Or were all the replacements like joda time from a previous era? Joda time essentially is the new standard Java date/time implementation. Joda was used as an out-of-stdlib proving ground to try out ideas and get feedback. The new Java date/time API is based on the learnings from Joda time. My understanding from use of the new (I shouldn't say "new"; it's been there since Java 8) date/time classes are that they're pretty good at representing dates, times, calendars, etc., but I wouldn't claim to be an expert on such matters.
- dwheeler 4y ago
  Historically one of the first uses for computers was Monte Carlo simulations. In such simulations it's often important to be able to deterministically recreate sequences of "random" numbers. Thus, in almost all computer programming languages, "Random" means deterministic random values. This is a wide convention followed by practically every programming language. If you want cryptographically secure random numbers, you typically call a function with a different name, one that has "secure" or "crypto" in a name somewhere (e.g., in the function or containing module/package). This is a convention from the 1950s and has been consistent ever since. That naming-convention ship sailed before many of us were born.
  - the_af 4y ago
    > Thus, in almost all computer programming languages, "Random" means deterministic random values. Yes, I know how pseudo RNG works. I just didn't realize this ran counter to doing secure crypto, so thanks for the explanation anyway :)
  - anomalroil 4y ago
    Speaking of Monte Carlo, here's a paper about how using bad randomness can lead to wrong simulation: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2992609/ https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2992609/ (or should I call them _biased_ ones?)
    - turtledragonfly 4y ago
      And as a counterpoint, if you use a well-chosen deterministic sequence, it can make some Monte Carlo methods produce better results faster than true randomness would (quasirandom sequences and all that). So, interestingly, "bad randomness" =/= deterministic. (not that you were claiming that, just adding this subtlety to the mix)
- googlryas 4y ago
  It isn't terrible, it is just not suitable for cryptographic applications. I suspect most of the time that people want a random number up to some value, it is not for cryptographic purposes.
  - the_af 4y ago
    > It isn't terrible Mind you, I didn't call it terrible. However, the comment I was replying to -- coincidentally the author of TFA on modulo bias we are discussing -- did: > java.util.Random is not a CSPRNG at all and is terrible, so even tho the nextInt() method is using rejection sampling, it's still producing biased values and also completely fails to be "unpredictable" because java.util.Random is weak and predictable. and > [...] using fast, but bad random generators such as Java's Random was shown to be an issue multiple times in the past already for things such as Monte Carlo, and so on, not just for things related to security. Of course, "CSPRNG" means "cryptographically secure", but his comment made me think he considers it a terrible implementation regardless.
    - brazzy 4y ago
      >his comment made me think he considers it a terrible implementation regardless. Different people have different standards for what is "terrible". There are much better PRNGs that are just as fast. You should probably avoid java.util.Random if you care about the quality of the randomness it produces. It's good enough for games that don't involve real money.
      - the_af 4y ago
        Well, the person who claims it's terrible is the author of the very thorough article we are discussing. > You should probably avoid java.util.Random if you care about the quality of the randomness it produces. That's pretty much the definition of "bad" ;) If you don't care about quality, I assume you could use a string of numbers without any randomness at all. As for games, it depends. I'm sure one could make a guess it's bad for some kinds of non-betting games and simulations as well.

deleted 4y ago

[deleted]

brazzy 4y ago

That's why we have public class SecureRandom extends Random

the_af 4y ago

Interesting! How come this wasn't fixed? Nobody noticed, or is it that java.util.Random is not meant for serious cryptographic use? I know there are other parts of the Java standard lib that are so terrible [1] that people for years have recommended not using them, like anything with dates and timezones... --- [1] or used to, haven't kept up with the latest Java versions. Maybe they fixed it.

anomalroil 4y ago
As you said: Java's Random is not meant for serious cryptographic usage, it's meant to be super fast. You have SecureRandom instead for cryptographic usage, and it's noticeably slower. Interestingly, using fast, but bad random generators such as Java's Random was shown to be an issue multiple times in the past already for things such as Monte Carlo, and so on, not just for things related to security.
edflsafoiewq 4y ago
The contract of Random requires determinism, so the algorithm can never be changed. > If two instances of Random are created with the same seed, and the same sequence of method calls is made for each, they will generate and return identical sequences of numbers. In order to guarantee this property, particular algorithms are specified for the class Random. Java implementations must use all the algorithms shown here for the class Random, for the sake of absolute portability of Java code
brazzy 4y ago
> is it that java.util.Random is not meant for serious cryptographic use? Indeed it never was. SecureRandom (a subclass of Random in a different package, grouped with other cryptography related functionality) was introduced in Java 1.1 in 1997. > I know there are other parts of the Java standard lib that are so terrible [1] that people for years have recommended not using them, like anything with dates and timezones... The original Java date classes (also from the 1.1 era) were functional and correct, but badly designed. A modern time API was introduced in Java 8 in 2014.
- the_af 4y ago
  > The original Java date classes (also from the 1.1 era) were functional and correct, but badly designed. A modern time API was introduced in Java 8 in 2014. I'm pretty sure they were neither correct nor functional. I've read pretty detailed examples of everything they got fundamentally wrong, which was a lot. Wrong, not as "this is cumbersome to use" but as in "this fundamentally misunderstands what dates are at a conceptual level, and produces wrong results". Unfortunately, I would have to google it now. All I can find right now is Jon Skeet's summary [1], which leans more to the "avoid using java.util.Date because it's one giant pitfall" side of the argument. Though it does mention some fundamental problems with it. However, this is not the article I found back in the day, which was both more comprehensive and more critical. > A modern time API was introduced in Java 8 in 2014. I seem to remember even at that time people were still not recommending Java standard date classes and functions, but I may be misremembering. Or were all the replacements like joda time from a previous era? --- [1] https://codeblog.jonskeet.uk/2017/04/23/all-about-java-util-date/ https://codeblog.jonskeet.uk/2017/04/23/all-about-java-util-...
  - kelnos 4y ago
    > Or were all the replacements like joda time from a previous era? Joda time essentially is the new standard Java date/time implementation. Joda was used as an out-of-stdlib proving ground to try out ideas and get feedback. The new Java date/time API is based on the learnings from Joda time. My understanding from use of the new (I shouldn't say "new"; it's been there since Java 8) date/time classes are that they're pretty good at representing dates, times, calendars, etc., but I wouldn't claim to be an expert on such matters.
dwheeler 4y ago
Historically one of the first uses for computers was Monte Carlo simulations. In such simulations it's often important to be able to deterministically recreate sequences of "random" numbers. Thus, in almost all computer programming languages, "Random" means deterministic random values. This is a wide convention followed by practically every programming language. If you want cryptographically secure random numbers, you typically call a function with a different name, one that has "secure" or "crypto" in a name somewhere (e.g., in the function or containing module/package). This is a convention from the 1950s and has been consistent ever since. That naming-convention ship sailed before many of us were born.
- the_af 4y ago
  > Thus, in almost all computer programming languages, "Random" means deterministic random values. Yes, I know how pseudo RNG works. I just didn't realize this ran counter to doing secure crypto, so thanks for the explanation anyway :)
- anomalroil 4y ago
  Speaking of Monte Carlo, here's a paper about how using bad randomness can lead to wrong simulation: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2992609/ https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2992609/ (or should I call them _biased_ ones?)
  - turtledragonfly 4y ago
    And as a counterpoint, if you use a well-chosen deterministic sequence, it can make some Monte Carlo methods produce better results faster than true randomness would (quasirandom sequences and all that). So, interestingly, "bad randomness" =/= deterministic. (not that you were claiming that, just adding this subtlety to the mix)
googlryas 4y ago
It isn't terrible, it is just not suitable for cryptographic applications. I suspect most of the time that people want a random number up to some value, it is not for cryptographic purposes.
- the_af 4y ago
  > It isn't terrible Mind you, I didn't call it terrible. However, the comment I was replying to -- coincidentally the author of TFA on modulo bias we are discussing -- did: > java.util.Random is not a CSPRNG at all and is terrible, so even tho the nextInt() method is using rejection sampling, it's still producing biased values and also completely fails to be "unpredictable" because java.util.Random is weak and predictable. and > [...] using fast, but bad random generators such as Java's Random was shown to be an issue multiple times in the past already for things such as Monte Carlo, and so on, not just for things related to security. Of course, "CSPRNG" means "cryptographically secure", but his comment made me think he considers it a terrible implementation regardless.
  - brazzy 4y ago
    >his comment made me think he considers it a terrible implementation regardless. Different people have different standards for what is "terrible". There are much better PRNGs that are just as fast. You should probably avoid java.util.Random if you care about the quality of the randomness it produces. It's good enough for games that don't involve real money.
    - the_af 4y ago
      Well, the person who claims it's terrible is the author of the very thorough article we are discussing. > You should probably avoid java.util.Random if you care about the quality of the randomness it produces. That's pretty much the definition of "bad" ;) If you don't care about quality, I assume you could use a string of numbers without any randomness at all. As for games, it depends. I'm sure one could make a guess it's bad for some kinds of non-betting games and simulations as well.