Random vs. Cryptographically random are typically separate

Posted Sep 18, 2015 19:20 UTC (Fri) by david.a.wheeler (subscriber, #72896)
Parent article: Python and crypto-strength random numbers by default

In many languages, "random" and "cryptographically random" are different.

E.G., in Java, SecureRandom provides a cryptographically strong random number generator (RNG), while Random does not. See: http://docs.oracle.com/javase/7/docs/api/java/security/Se...

Random vs. Cryptographically random are typically separate

Posted Sep 18, 2015 22:36 UTC (Fri) by wahern (subscriber, #37304) [Link] (7 responses)

But many people don't think about security consequences, or if they do they arrive at the wrong conclusion. I think the point here is that by making a CSPRNG the default, you mitigate the impact of sloppy analysis. Of course, attempting to second guess programmers this way is often a bad idea. I understand the push back. But in this case, all things considered, it seems like an easy win.

Theo did his homework before arriving at his decision: "I have spent the last week researching all the uses of the srand(), srandom(), and srand48() subsystems in the ports tree." (https://lwn.net/Articles/625562/). So he had a better idea than most about the potential impact.

Random vs. Cryptographically random are typically separate

Posted Sep 19, 2015 0:14 UTC (Sat) by anselm (subscriber, #2796) [Link] (6 responses)

If people are sloppy about random numbers in their cryptographic code, why would anyone want to assume that they are not just as sloppy about the rest of their cryptographic code? Sure, we can arrange for the RNG to get “upgraded” to fix this, but this may end up being the least of our worries.

Random vs. Cryptographically random are typically separate

Posted Sep 19, 2015 2:51 UTC (Sat) by wahern (subscriber, #37304) [Link] (2 responses)

1) Sometimes people don't realize that their code requires cryptographic resilience. Just look at the examples posted above by jimparis. None of those involve obvious cases like generating cipher keys.

2) Similar to #1, sometimes even if your task doesn't require cryptographic resilience it's still a bad idea to use random, et al. The seeding functions often leak state about your process (see jimparis' first 1st). I never use non-CSPRNGs when the results will leak directly or indirectly (e.g. sorting order) over the network. But most people don't even think about this, even experienced engineers. Leaking your PID, system time, etc, is not smart, particularly when it's trivial to avoid doing so.

3) You could make this argument about anything--we can't do it perfectly, so let's do nothing. In this case it's a trivial solution with minimal costs that could offer much benefit. Reasonable people can disagree, of course. But at the end of the day opinions should give way to empirical data. Theo compiled some empirical data and made a decision. Furthermore, implementing this doesn't preclude taking other measures in other contexts.

Random vs. Cryptographically random are typically separate

Posted Sep 19, 2015 11:12 UTC (Sat) by kleptog (subscriber, #1183) [Link]

There's still the documentation question, I see that the warning about it not being cryptographically secure was added in the 2.7 docs, prior to that you had to read the wall of text to discover that. The default behaviour of random() now if you don't seed it is to read 32 bytes of urandom (if available) and use that as seed. If you're not generating lots of random numbers this should be sufficient. You wouldn't want to generate crypto keys that way, but it's not that bad.

Random vs. Cryptographically random are typically separate

Posted Sep 20, 2015 16:57 UTC (Sun) by apoelstra (subscriber, #75205) [Link]

I have a couple more:

4) Failure modes for RNGs are often undetectable by testing. You can (and should) look for really specific failure modes, like always outputting the same value, but in general if you use a bad RNG the rest of your program's performance and correctness will not be affected in the least. Just security.

5) The output of a bad RNG can stick around forever. If you've got a long-lived private key, if it turns out it was generated poorly then you are screwed, even if this was years ago. (Now that I think about it, I have no recollection of what software or version I used to generate my PGP keys. So in principle any RNG failure in the news could be affecting me.) Combine this with #4 and you have a very dangerous situation indeed.

Compare this to other crypto failure modes, like leaving secure data in memory, timing side-channels, etc., which go away once the software is fixed (or even when the software stops running).

Random vs. Cryptographically random are typically separate

Posted Sep 20, 2015 5:29 UTC (Sun) by njs (subscriber, #40338) [Link] (2 responses)

I've come around to feeling that it's unfair to call programmers "sloppy" because they thought that a function called random.random() would return random numbers. Everyone understands how dice and coin flips work, and that's how random number generators are always taught to new programmers, and if random.random() actually worked the way dice and coin flips worked then it would be safe to use for any purpose :-/.

Obviously you and I know that computer "random numbers" are this weird thing that are almost-like-random but with extremely subtle failures that only matter in certain obscure but high-stakes contexts... but it's not really newbie programmers' fault that they don't automatically know this. (Sure, there's a warning in the docs, but if you don't know to look for it...)

Random vs. Cryptographically random are typically separate

Posted Sep 23, 2015 1:35 UTC (Wed) by dvdeug (guest, #10998) [Link] (1 responses)

Computer "numbers" are these weird things that are almost-like-numbers with fairly non-subtle failure modes in many contexts.* A lot of learning computer programming is learning all these details where things don't work the way one would naively expect them to. If they don't understand that random.random uses a deterministic RNG, then they probably have a lot of other problems in programming.

* E.g. exists a, b, i, j such that (a > 0.0) && (b + a == b) or (i > 0) && (j > 0) && (i + j < 0).

Random vs. Cryptographically random are typically separate

Posted Sep 23, 2015 15:26 UTC (Wed) by apoelstra (subscriber, #75205) [Link]

> If they don't understand that random.random uses a deterministic RNG, then they probably have a lot of other problems in programming.

CSPRNGs are also deterministic. Determinism is not what burns cryptographically-inexperienced programmers.