3 ms·

This is exactly what I mean about being stuck in the C mindset. You're looking at the problem though the lens of what this giant pile of ancient C software doe

This is exactly what I mean about being stuck in the C mindset. You're looking at the problem though the lens of what this giant pile of ancient C software does. Why should newer languages take the same approach to APIs that these old code bases did? It's not like we're porting all those programs to JS. Those C APIs were written long before hardware could provide fast good randomness, heck even before cryptography was standard practice instead of a special use case. Not to mention in JS you can't even seed the random number generator. If you want predictable "random" numbers, you should have to jump through additional hoops. By default random numbers should be cryptographically secure. EDIT: It's also worth mentioning that from your reported dataset, 41 of 8800 programs analyzed used srand to get a repeatable set of "random" numbers. That's 0.47%. I'm happy to break less than half a percent of software if it helps prevent the far more ubiquitous failures of software using insecure random numbers.

throw0101a 6y ago
I'm looking at the problem through the lens of changing the behaviour of an existing API. If you want to create 'secure' APIs that 'do the right' thing, I'm not against it. But leave the old stuff around, or mark it deprecated, throwing warnings and errors on compilation even, for possible future removal—don't change it.
- admax88q 6y ago
  > or possible future removal—don't change it. The future is now, insecure code has had long enough to catch up.
kevin_thibedeau 6y ago
A reproducible pseudorandom sequence is necessary for fuzz testing with randomized inputs. It isn't strictly the domain of "ancient C". Why should everyone be hobbled by security guarantees they won't need?
- repsilat 6y ago
  > fuzz testing Also reproducible builds, non-fuzz testing of very complex systems, the list goes on. Quite often CS papers describe randomized data structures and algorithms. Quite often (at least historically, not sure now) ML models were seeded from random states. If you want something to be algorithmically reproducible, you need some pretty strong guarantees from component parts. If you're using a hash table, and that hash table makes use of nondeterministic state that you can't control, you need to make sure that you're not using it in a way that lets that nondetederminism leak out -- if it doesn't provide a deterministic iteration order, you shouldn't iterate over it. Sometimes determinism can be won back (just using lookup methods on your hash table, sorting the hash elements after iterating over the hash table) but in some cases it's not really possible, and in many cases it's at least impractical. Not providing a mechanism for nondeterminism in the first place can be simpler, but it comes with different problems. (Security problems are an obvious example -- an OS that gives deterministic bits when you ask for random bits is a worry.)
- IcePic 6y ago
  Do you have a guarantee that random() will give you the same sequence on different endians, on different libcs, on different 32/64bit arches, on different OSes or even dists? The expectation of reproducability is probably lost if you switch any of the above "details", so the problem with bad-random-generation is that it's not only the people who thinks the entropy is good in it that are wrong, the ones that think rand() didn't change in the last 40(?) years are equally wrong.
- admax88q 6y ago
  Why should everyone be compromised because fuzzers want to use the simpler rand() API instead of something different? I'm not saying we shouldn't have a way to generate predictable "random" sequences. But the default, simple, API for random numbers in any given language should be secure. The vast majority of software does not need pseudorandom sequences. Developers shouldn't have to think every time "is pseudorandom good enough for this use case?" It should just be strong random every time. If you need a pseudorandom we should have a separate API for that.
h_anna_h 6y ago
> 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.
asveikau 6y ago
This was specifically a discussion of the impact of purposefully breaking a strict interpretation of a POSIX API, though. They looked at where it was used, which is appropriate.

throw0101a 6y ago

I'm looking at the problem through the lens of changing the behaviour of an existing API. If you want to create 'secure' APIs that 'do the right' thing, I'm not against it. But leave the old stuff around, or mark it deprecated, throwing warnings and errors on compilation even, for possible future removal—don't change it.

admax88q 6y ago
> or possible future removal—don't change it. The future is now, insecure code has had long enough to catch up.

kevin_thibedeau 6y ago

A reproducible pseudorandom sequence is necessary for fuzz testing with randomized inputs. It isn't strictly the domain of "ancient C". Why should everyone be hobbled by security guarantees they won't need?

repsilat 6y ago
> fuzz testing Also reproducible builds, non-fuzz testing of very complex systems, the list goes on. Quite often CS papers describe randomized data structures and algorithms. Quite often (at least historically, not sure now) ML models were seeded from random states. If you want something to be algorithmically reproducible, you need some pretty strong guarantees from component parts. If you're using a hash table, and that hash table makes use of nondeterministic state that you can't control, you need to make sure that you're not using it in a way that lets that nondetederminism leak out -- if it doesn't provide a deterministic iteration order, you shouldn't iterate over it. Sometimes determinism can be won back (just using lookup methods on your hash table, sorting the hash elements after iterating over the hash table) but in some cases it's not really possible, and in many cases it's at least impractical. Not providing a mechanism for nondeterminism in the first place can be simpler, but it comes with different problems. (Security problems are an obvious example -- an OS that gives deterministic bits when you ask for random bits is a worry.)
IcePic 6y ago
Do you have a guarantee that random() will give you the same sequence on different endians, on different libcs, on different 32/64bit arches, on different OSes or even dists? The expectation of reproducability is probably lost if you switch any of the above "details", so the problem with bad-random-generation is that it's not only the people who thinks the entropy is good in it that are wrong, the ones that think rand() didn't change in the last 40(?) years are equally wrong.
admax88q 6y ago
Why should everyone be compromised because fuzzers want to use the simpler rand() API instead of something different? I'm not saying we shouldn't have a way to generate predictable "random" sequences. But the default, simple, API for random numbers in any given language should be secure. The vast majority of software does not need pseudorandom sequences. Developers shouldn't have to think every time "is pseudorandom good enough for this use case?" It should just be strong random every time. If you need a pseudorandom we should have a separate API for that.

h_anna_h 6y ago

> 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.

asveikau 6y ago

This was specifically a discussion of the impact of purposefully breaking a strict interpretation of a POSIX API, though. They looked at where it was used, which is appropriate.