10 ms·

Is there something I am overlooking here? Randomness is used for many other things than cryptographic usages. Eg. for randomised algorithms you need a fast sou

Is there something I am overlooking here? Randomness is used for many other things than cryptographic usages. Eg. for randomised algorithms you need a fast source of randomness.

duckerude 6y ago
It is. The question was how often that's the case. If 50% of the uses of random() are bad, then getting those fixed may be worth the cost of annoying the authors of the legitimate 50%. It turned out to be much less useful than that. So they got rid of it.
otabdeveloper4 6y ago
No, you are not. Cryptographic random() is an extremely niche use case that you shouldn't be using unless you're writing your own crypto libraries. (Don't do that.)
- stickfigure 6y ago
  Server-side folks generate random identifiers and shared secrets all the time. Yes, it's niche, but not "extremely" and you don't use a crypto library for this (you use secure random!)
  - mreome 6y ago
    There is a difference between generating these kind of IDs and writing the generator for these kinds of IDs. You shouldn't be rolling your own UUID generator if you don't fully understand the concerns/requirements in regards to your source of randomness. Generally speaking, I'd agree the need for a cryptographicly secure random is niche in that it is limited to the implementation of specific libraries/functions that despite being widely used, should NOT be frequently re-implemented.
    - josephg 6y ago
      I do this in nodejs all the time for IDs: require(‘crypto’).randomBytes(15).toString(‘base64’) Is this bad practice? Can you say more about why?
      - cperciva 6y ago
        That's only 120 bits of entropy, which means that you'll get a collision after generating ~ 2^60 IDs. Ok, maybe you're not worried about that scale; but I normally recommend 256-bit IDs in order to make sure that you don't need to worry about that possibility.
- tedunangst 6y ago
  What bad things will happen if I use cryptographic random for a non niche use case?
  - madsbuch 6y ago
    It is expensive to increase entropy of a random source. So for randomised algorithms you might not get the performance that merited the algorithms in the first place.
- mreome 6y ago
  It's not that you shouldn't be using it necessarily, it's just that for many cases (games, procedural generation, graphics, many kind of simulations) it's unnecessary and slow. In my experience if someone doesn't know if they need a cryptographicly secure random(), or if a given random() implementation is secure then they (a) don't need it or (b) are trying to implement something they shouldn't be.
- jcranmer 6y ago
  That's not true. To answer the question as to when you should use cryptographic random(), ask yourself "What is the worst that could happen if someone guesses the result of random()?" If the answer is "I don't know," go cryptrographic. You'll save your butt if you didn't know it was important. If the answer is along the lines of "someone could impersonate a user, or leak information they shouldn't see," for the love of all that is holy, use cryptographic. This is basically every scenario where you are using random to generate an ID of some kind, and while it's only truly critical if that ID is all you need for validation, it does provide another layer of security even if you also require other information to match before giving out elevated access. If the answer is "it defeats the algorithm I'm trying to do" (think something like ASLR, where you're randomizing the offsets of addresses so that attackers don't know where things are located), well, the reason why you need to use cryptographic should be blindingly obvious. If the answer is instead "they can reproduce my results," well, you shouldn't use cryptographic in this case. And that's not a lot of cases: Monte Carlo simulations, testing, fuzzing are the obvious poster children for this category, and indeed reproducibility in these cases tends to be a highly valuable feature rather than an anti-feature. Cryptographic random is almost never harmful to your application, and almost always provides some benefit in reducing guessability of your system. You should err on the side of using cryptographic random(), and only not use it when you are sure that guessability will not harm security in any way and you know that the cryptographic nature actively harms your application.
  - mreome 6y ago
    I would argue that if you're asking yourself "What is the worst that could happen if someone guesses the result of random()?" and your answer is "I don't know," then you're doing something you shouldn't be doing. There are a lot of domains where security is a non-issue and performance is a huge concern (graphics, game logic, many kind of simulations, etc), and the default is the reverse... always just use the installed non-secure random() and if that's too slow consider other options. Having a flag you can enable to warn about a non-secure random() usage, when it makes sense for your company/usage, sure. But banning it outright makes no sense, and the default behavior you want is very situational.
    - 6y ago
- creata 6y ago
  Say you're making an online game, and you need an RNG on your server. Above all, this RNG needs to be unpredictable, or someone will easily game it. Most non-cryptographic PRNGs are very predictable, so it's dangerous to use them. I think this is a scenario that (a) isn't "extremely niche," and (b) warrants CSPRNGs.
analog31 6y ago
Indeed, I use something like it from a vendor supplied C math library for a noise generator on an embedded app, where I really just care about its crude statistical behavior. But short of saying "banned," any review of security critical code should include an explanation of where the random numbers are coming from and why they're trusted. Or in general for any code review: Why do you believe your numbers?
hannob 6y ago
The cryptographic randomness has practically no downside if you use it for non-cryptogrpahic purposes. Not true the other way round. And I'm inclined to say given how many misconceptions around randomness there are around, I don't think people are good at knowing whether they need secure randomness. The only possible justification for insecure randomness would be performance, but you'd need to generate a lot of random numbers to even be able to measure that.
- gwbas1c 6y ago
  > The cryptographic randomness has practically no downside if you use it for non-cryptogrpahic purposes Cryptographic randomness is typically slower than other forms of randomness. In all of the programming I've done in my career, I've only needed cryptographic randomness a few times. For the rest, a fast pseudorandom number generator seeded by the clock was the correct choice.
  - pdpi 6y ago
    Inversely, in my career there's only been a handful of times where cryptographic randomness was too slow. I'd argue it's better to do the safe thing by default and switching to the faster alternative when you have proof you need it. Doing the fast thing by default and fixing security later is how we got Meltdown/Spectre.
    - mreome 6y ago
      It's going to depend on your experience, for me I have often run into the exact opposite extreme... where the non-secure random is to slow for my uses-cases (games, graphics, procedural texture gen, etc) and a much faster but less statistically random generator better suited my needs. I would argue that the default behavior should favor the novice and non-domain-expert. Should game programmers, graphic programmers, etc, be expected to know that they need to tune the performance of random() or should the domain-experts writing cryptographic algorithms be expected to understand the limitations of random() as it applies to their use-case?
magicalhippo 6y ago
As much as it's overkill for most people, I'm a fan of safe defaults so I say let random() be slow and good. It's better to find out your code is slow due to a slow random() than to find out it's broken because you didn't know and thought random() was really random. If you need a fast source of randomness, for some Monte Carlo algorithm for example, then you know this and can pick a deliberate pseudo-random generator that fits your needs. I worked on a Monte Carlo path tracer. Early on we swapped out the random number generator from the standard random(). Initially not for speed, but due to the poor distribution. After optimizing other areas it became a bottleneck and we swapped it out again for a faster one.
nullc 6y ago
> Eg. for randomised algorithms you need a fast source of randomness. Though normal random() implementations are LCGs which have poor distributions when you either only look at the least significant bits or project them into multiple dimensions. As a result they may make some randomized algorithms perform poorly!

Is there something I am overlooking here? Randomness is used for many other things than cryptographic usages. Eg. for randomised algorithms you need a fast source of randomness.

duckerude 6y ago

It is. The question was how often that's the case. If 50% of the uses of random() are bad, then getting those fixed may be worth the cost of annoying the authors of the legitimate 50%. It turned out to be much less useful than that. So they got rid of it.

otabdeveloper4 6y ago

No, you are not. Cryptographic random() is an extremely niche use case that you shouldn't be using unless you're writing your own crypto libraries. (Don't do that.)

stickfigure 6y ago
Server-side folks generate random identifiers and shared secrets all the time. Yes, it's niche, but not "extremely" and you don't use a crypto library for this (you use secure random!)
- mreome 6y ago
  There is a difference between generating these kind of IDs and writing the generator for these kinds of IDs. You shouldn't be rolling your own UUID generator if you don't fully understand the concerns/requirements in regards to your source of randomness. Generally speaking, I'd agree the need for a cryptographicly secure random is niche in that it is limited to the implementation of specific libraries/functions that despite being widely used, should NOT be frequently re-implemented.
  - josephg 6y ago
    I do this in nodejs all the time for IDs: require(‘crypto’).randomBytes(15).toString(‘base64’) Is this bad practice? Can you say more about why?
    - cperciva 6y ago
      That's only 120 bits of entropy, which means that you'll get a collision after generating ~ 2^60 IDs. Ok, maybe you're not worried about that scale; but I normally recommend 256-bit IDs in order to make sure that you don't need to worry about that possibility.
tedunangst 6y ago
What bad things will happen if I use cryptographic random for a non niche use case?
- madsbuch 6y ago
  It is expensive to increase entropy of a random source. So for randomised algorithms you might not get the performance that merited the algorithms in the first place.
mreome 6y ago
It's not that you shouldn't be using it necessarily, it's just that for many cases (games, procedural generation, graphics, many kind of simulations) it's unnecessary and slow. In my experience if someone doesn't know if they need a cryptographicly secure random(), or if a given random() implementation is secure then they (a) don't need it or (b) are trying to implement something they shouldn't be.
jcranmer 6y ago
That's not true. To answer the question as to when you should use cryptographic random(), ask yourself "What is the worst that could happen if someone guesses the result of random()?" If the answer is "I don't know," go cryptrographic. You'll save your butt if you didn't know it was important. If the answer is along the lines of "someone could impersonate a user, or leak information they shouldn't see," for the love of all that is holy, use cryptographic. This is basically every scenario where you are using random to generate an ID of some kind, and while it's only truly critical if that ID is all you need for validation, it does provide another layer of security even if you also require other information to match before giving out elevated access. If the answer is "it defeats the algorithm I'm trying to do" (think something like ASLR, where you're randomizing the offsets of addresses so that attackers don't know where things are located), well, the reason why you need to use cryptographic should be blindingly obvious. If the answer is instead "they can reproduce my results," well, you shouldn't use cryptographic in this case. And that's not a lot of cases: Monte Carlo simulations, testing, fuzzing are the obvious poster children for this category, and indeed reproducibility in these cases tends to be a highly valuable feature rather than an anti-feature. Cryptographic random is almost never harmful to your application, and almost always provides some benefit in reducing guessability of your system. You should err on the side of using cryptographic random(), and only not use it when you are sure that guessability will not harm security in any way and you know that the cryptographic nature actively harms your application.
- mreome 6y ago
  I would argue that if you're asking yourself "What is the worst that could happen if someone guesses the result of random()?" and your answer is "I don't know," then you're doing something you shouldn't be doing. There are a lot of domains where security is a non-issue and performance is a huge concern (graphics, game logic, many kind of simulations, etc), and the default is the reverse... always just use the installed non-secure random() and if that's too slow consider other options. Having a flag you can enable to warn about a non-secure random() usage, when it makes sense for your company/usage, sure. But banning it outright makes no sense, and the default behavior you want is very situational.
  - 6y ago
creata 6y ago
Say you're making an online game, and you need an RNG on your server. Above all, this RNG needs to be unpredictable, or someone will easily game it. Most non-cryptographic PRNGs are very predictable, so it's dangerous to use them. I think this is a scenario that (a) isn't "extremely niche," and (b) warrants CSPRNGs.

analog31 6y ago

Indeed, I use something like it from a vendor supplied C math library for a noise generator on an embedded app, where I really just care about its crude statistical behavior. But short of saying "banned," any review of security critical code should include an explanation of where the random numbers are coming from and why they're trusted. Or in general for any code review: Why do you believe your numbers?

hannob 6y ago

The cryptographic randomness has practically no downside if you use it for non-cryptogrpahic purposes. Not true the other way round. And I'm inclined to say given how many misconceptions around randomness there are around, I don't think people are good at knowing whether they need secure randomness. The only possible justification for insecure randomness would be performance, but you'd need to generate a lot of random numbers to even be able to measure that.

gwbas1c 6y ago
> The cryptographic randomness has practically no downside if you use it for non-cryptogrpahic purposes Cryptographic randomness is typically slower than other forms of randomness. In all of the programming I've done in my career, I've only needed cryptographic randomness a few times. For the rest, a fast pseudorandom number generator seeded by the clock was the correct choice.
- pdpi 6y ago
  Inversely, in my career there's only been a handful of times where cryptographic randomness was too slow. I'd argue it's better to do the safe thing by default and switching to the faster alternative when you have proof you need it. Doing the fast thing by default and fixing security later is how we got Meltdown/Spectre.
  - mreome 6y ago
    It's going to depend on your experience, for me I have often run into the exact opposite extreme... where the non-secure random is to slow for my uses-cases (games, graphics, procedural texture gen, etc) and a much faster but less statistically random generator better suited my needs. I would argue that the default behavior should favor the novice and non-domain-expert. Should game programmers, graphic programmers, etc, be expected to know that they need to tune the performance of random() or should the domain-experts writing cryptographic algorithms be expected to understand the limitations of random() as it applies to their use-case?

magicalhippo 6y ago

As much as it's overkill for most people, I'm a fan of safe defaults so I say let random() be slow and good. It's better to find out your code is slow due to a slow random() than to find out it's broken because you didn't know and thought random() was really random. If you need a fast source of randomness, for some Monte Carlo algorithm for example, then you know this and can pick a deliberate pseudo-random generator that fits your needs. I worked on a Monte Carlo path tracer. Early on we swapped out the random number generator from the standard random(). Initially not for speed, but due to the poor distribution. After optimizing other areas it became a bottleneck and we swapped it out again for a faster one.

nullc 6y ago

> Eg. for randomised algorithms you need a fast source of randomness. Though normal random() implementations are LCGs which have poor distributions when you either only look at the least significant bits or project them into multiple dimensions. As a result they may make some randomized algorithms perform poorly!