4 ms·

> If you want predictable "random" numbers, you should have to jump through additional hoops Why? > By default random numbers should be cryptographically secu

> If you want predictable "random" numbers, you should have to jump through additional hoops Why? > By default random numbers should be cryptographically secure. Why not both?

lmm 6y ago
> Why? Because you're doing something that often causes major security bugs. > Why not both? It's not possible for random numbers to be both predictable and secure at the same time.
- bscphil 6y ago
  If by "predictable" all that's meant is "you can deterministically recreate every output bit generated by the function, forever, using a single value that represents the starting state of the function", then you can certainly have that and a secure RNG function. Just use ChaCha20's function with the key representing your seed.
  - lmm 6y ago
    That might be a good default, but where would the seed come from? You also need to make sure that the order in which random bits are read is deterministic, which is a lot harder than it sounds.
- h_anna_h 6y ago
  In addition to what bscphil said > Because you're doing something that often causes major security bugs. Okay, sure, but I might be running a simulation or something, why should I be punished because some idiot decided to srand(time(0))?
  - admax88q 6y ago
    Because your in the minority. Why should rand() be reserved for your use case and people with other use cases need to use a more obtuse SecureRandom() API? Defaults should be secure. The simple case should be secure.
    - h_anna_h 6y ago
      > Why should rand() be reserved for your use case Because rand has a specific and well defined meaning. In addition I see no evidence that this use-case is any less popular. Anyway, this subthread is about having to go through extra hoops to have deterministic random numbers, your post is irrelevant to that. I do not think that anyone would be against defining random() to return a secure random number in your language. > Defaults should be secure Are you supporting that new computers should come preinstalled with Qubes OS, have a constant time memcmp, constant time font rendering, etc? > Because your in the minority Fuck people with allergies, right? Let's only provide food with nuts and have them go through "additional hoops" to get food that won't kill them. I do not think that this is a sound argument.
  - lmm 6y ago
    > Okay, sure, but I might be running a simulation or something, why should I be punished because some idiot decided to srand(time(0))? It's about cost/benefit. As far as the compiler/framework knows, there's a 20% (say) chance that you've just introduced a major security bug into your program. Doesn't the benefit of requiring some explicit acknowledgement of that case outweigh the cost? You contrast "I" with "some idiot", but the evidence of the last 20+ years is that most programmers who think they can write secure code can't; if you make those kind of warnings only to people who opt-in to them, the very people who most need them will not get them.

> If you want predictable "random" numbers, you should have to jump through additional hoops Why? > By default random numbers should be cryptographically secure. Why not both?

lmm 6y ago

> Why? Because you're doing something that often causes major security bugs. > Why not both? It's not possible for random numbers to be both predictable and secure at the same time.

bscphil 6y ago
If by "predictable" all that's meant is "you can deterministically recreate every output bit generated by the function, forever, using a single value that represents the starting state of the function", then you can certainly have that and a secure RNG function. Just use ChaCha20's function with the key representing your seed.
- lmm 6y ago
  That might be a good default, but where would the seed come from? You also need to make sure that the order in which random bits are read is deterministic, which is a lot harder than it sounds.
h_anna_h 6y ago
In addition to what bscphil said > Because you're doing something that often causes major security bugs. Okay, sure, but I might be running a simulation or something, why should I be punished because some idiot decided to srand(time(0))?
- admax88q 6y ago
  Because your in the minority. Why should rand() be reserved for your use case and people with other use cases need to use a more obtuse SecureRandom() API? Defaults should be secure. The simple case should be secure.
  - h_anna_h 6y ago
    > Why should rand() be reserved for your use case Because rand has a specific and well defined meaning. In addition I see no evidence that this use-case is any less popular. Anyway, this subthread is about having to go through extra hoops to have deterministic random numbers, your post is irrelevant to that. I do not think that anyone would be against defining random() to return a secure random number in your language. > Defaults should be secure Are you supporting that new computers should come preinstalled with Qubes OS, have a constant time memcmp, constant time font rendering, etc? > Because your in the minority Fuck people with allergies, right? Let's only provide food with nuts and have them go through "additional hoops" to get food that won't kill them. I do not think that this is a sound argument.
- lmm 6y ago
  > Okay, sure, but I might be running a simulation or something, why should I be punished because some idiot decided to srand(time(0))? It's about cost/benefit. As far as the compiler/framework knows, there's a 20% (say) chance that you've just introduced a major security bug into your program. Doesn't the benefit of requiring some explicit acknowledgement of that case outweigh the cost? You contrast "I" with "some idiot", but the evidence of the last 20+ years is that most programmers who think they can write secure code can't; if you make those kind of warnings only to people who opt-in to them, the very people who most need them will not get them.