3 ms·

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 so

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.

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.