5 ms·

Interesting. In Java, there’s random.nextInt(max). Curious if that takes this into account.

brazzy 4y ago
I have zero doubt that it does. This is extremely high visibility code that has been around for decades. And I also have zero doubts that there are a bunch of reimplementations that don't, from assclowns who don't trust libraries on general principle.
- deleted 4y ago
  [deleted]
- anomalroil 4y ago
  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-...
- deleted 4y ago
  [deleted]

I have zero doubt that it does. This is extremely high visibility code that has been around for decades. And I also have zero doubts that there are a bunch of reimplementations that don't, from assclowns who don't trust libraries on general principle.

deleted 4y ago
[deleted]
anomalroil 4y ago
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-...
deleted 4y ago
[deleted]