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.
1
1
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
I think if you want to push using a CSPRNG everywhere by default, it needs to be ChaCha8 or hardware AES with a thread-local cache though. That's more than fast enough to replace *nearly* all PRNG uses especially since typical PRNG implementations are often SLOWER than ChaCha8.
1
1
i.e. beyond just replacing those legacy C APIs but also replacing the non-secure random number generation across languages, applications, libraries, etc. A lot of it does need to be fast, and it can be both secure and fast, but the global locking + ChaCha20 doesn't really do it.
1
1
People also usually need random number generation within a range with uniform distribution. If you're avoiding locking and have a really fast (CS)PRNG, that's a huge part of the overhead. Part of what a good API should provide. arc4random has decent but not great 32-bit only one.