TIL busybox generates password salts from current time in usec. Does this matter? Probably not, but seems mildly sus.
12
11
123
Conversation
Replying to
Probably not a vuln, but I don't like the philosophy. We should switch from "use a secure RNG when needed" to "use a secure RNG by default and only use an insecure RNG if you have very good reasons, which is incredibly rare (e.g. predictable seed)"
2
3
17
Some years ago, OpenBSD made the libc random interfaces (random(3), rand(3), etc) use a CSPRNG unless explicitly seeded using a separate srandom_deterministic(3) function. man.openbsd.org/random.3
3
9
I think twitter.com/DanielMicay/st is the main issue with the OpenBSD approach. It's going to be a hard sell to have global locking (arc4random) to retrieve random numbers and ChaCha20 just isn't fast enough. ChaCha8 is almost competitive with typical non-CS PRNGs though.
Quote Tweet
Replying to @hanno and @RichFelker
An important part of that is making the CSPRNG ridiculously fast and offering it as the standard easy-to-use API available everywhere. For example, ChaCha8 with a 64 to 256 byte thread-local cache. Can use ChaCha20 when that overkill makes sense but it's usually pretty wasteful.
I've not measured this, but I think most intensive users of random numbers can be switched back to the traditional fast + non-cryptographic PRNG.
It's mostly the programs that require a little randomness, occasionally that see a security win from CSPRNG-by-default
1
I think most programs where random number generation performance and/or quality matter much are already using something other than the legacy C APIs. OpenBSD approach is a reasonable trade-off for software that doesn't care much about what they get.
1
1
Show replies