3 ms·

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 giv

by 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?
    - Nullabillity 6y ago
      Which has the worse consequences for misuse? The game programmer who needed better performance can "just" switch to a faster algorithm when the profiling calls for it (and if you don't notice it, well, no harm anyway). The guy who just needed to generate some cryptographic keys? Rotate everything, and you had some pretty horrible hidden vulnerabilities in the meantime.
  - nullc 6y ago
    > Inversely, in my career there's only been a handful of times where cryptographic randomness was too slow. Yeah, that's the opposite of my experience. Often the libc random is too slow and limiting performance and I need to substitute something even faster. But I agree that using something that is securely random by default is a good idea. People can substitute faster thing fit for their purpose if needed.
mreome 6y ago
My counter would be that if someone "doesn't know whether they need secure randomness" then the problem is not that random() is not secure, it's the fact that someone is doing something they really should not be doing in the first place.
stefan_ 6y ago
Obligatory mention here for the fine folks of systemd, who have made a properly seeded CSPRNG a requirement for merely booting a system and then kept bricking peoples systems when it turns out finding that seed at boot time is a non-trivial problem. All for what, avoiding collisions in some hash table implementation? I don't really care for the browser application, if you made a TLS connection in the first place obviously you better have the randomness and might as well make random() use that, but someone explicitly using a CSPRNG in a native application is a huge code smell on the level of implementing your own crypto.

by hannob 6y ago

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?
  - Nullabillity 6y ago
    Which has the worse consequences for misuse? The game programmer who needed better performance can "just" switch to a faster algorithm when the profiling calls for it (and if you don't notice it, well, no harm anyway). The guy who just needed to generate some cryptographic keys? Rotate everything, and you had some pretty horrible hidden vulnerabilities in the meantime.
- nullc 6y ago
  > Inversely, in my career there's only been a handful of times where cryptographic randomness was too slow. Yeah, that's the opposite of my experience. Often the libc random is too slow and limiting performance and I need to substitute something even faster. But I agree that using something that is securely random by default is a good idea. People can substitute faster thing fit for their purpose if needed.

mreome 6y ago

My counter would be that if someone "doesn't know whether they need secure randomness" then the problem is not that random() is not secure, it's the fact that someone is doing something they really should not be doing in the first place.

stefan_ 6y ago

Obligatory mention here for the fine folks of systemd, who have made a properly seeded CSPRNG a requirement for merely booting a system and then kept bricking peoples systems when it turns out finding that seed at boot time is a non-trivial problem. All for what, avoiding collisions in some hash table implementation? I don't really care for the browser application, if you made a TLS connection in the first place obviously you better have the randomness and might as well make random() use that, but someone explicitly using a CSPRNG in a native application is a huge code smell on the level of implementing your own crypto.