5 ms·

Except that's blatantly incorrect as anything running before the RNG is seeded will be completely insecure. Sure, that's good enough for generating SSL keys aft

Except that's blatantly incorrect as anything running before the RNG is seeded will be completely insecure. Sure, that's good enough for generating SSL keys after a system has been running for a while, but what about those SSH keys generated on first boot? See this paper for further details: https://factorable.net/weakkeys12.extended.pdf https://factorable.net/weakkeys12.extended.pdf This has been a huge problem in the embedded device world. We need something reliably secure, not just secure after a while. /dev/urandom does not fit this criteria. Currently the best reliable option for Linux applications is to seed a CSPRNG from /dev/random and run it in usermode. Which can also be quite error prone. This is why I think this syscall is a very good improvement over the current state of things.

tptacek 12y ago
This is why Linux distributions save seed files and seed the RNG at bootup. The RNG isn't "secure after awhile". The instant the RNG is seeded, it's secure. You don't have to take my word for it; look at the design of the Nacl library --- that's Bernstein, Schwabe, and Lange --- for an example of "just use urandom".
- ultramancool 12y ago
  And if there's no RNG seed available? We're talking about the first boot of a system here. You're going to have to wait for sufficient entropy to be available to the kernel or start reading junk. This is why the embedded devices hit many problems. Sure, /dev/urandom is a good general strategy, I'm not disagreeing with you there, but it's not perfect and it very easily could be made better by simply blocking when needed to gather more entropy. getrandom() seems like a much better solution, providing an RNG without these idiosyncrasies.
  - sarciszewski 12y ago
    Most developers are not going to be writing code that has to compete in a race against the operating system's RNG seeding process. (I have to explain this to PHP programmers all the time.) And the ones who are, ought to be made aware of the danger on Linux. Patching /dev/urandom to block if it's not seeded on boot seems like a winning strategy to me. Why aren't we doing that?
    - dezgeg 12y ago
      Because it could break existing boot scripts/programs that read from /dev/urandom. Linus doesn't consider "[...] the ones who are [writing code that runs at boot], ought to be made aware of the danger" as a solution.

tptacek 12y ago

This is why Linux distributions save seed files and seed the RNG at bootup. The RNG isn't "secure after awhile". The instant the RNG is seeded, it's secure. You don't have to take my word for it; look at the design of the Nacl library --- that's Bernstein, Schwabe, and Lange --- for an example of "just use urandom".

ultramancool 12y ago
And if there's no RNG seed available? We're talking about the first boot of a system here. You're going to have to wait for sufficient entropy to be available to the kernel or start reading junk. This is why the embedded devices hit many problems. Sure, /dev/urandom is a good general strategy, I'm not disagreeing with you there, but it's not perfect and it very easily could be made better by simply blocking when needed to gather more entropy. getrandom() seems like a much better solution, providing an RNG without these idiosyncrasies.
- sarciszewski 12y ago
  Most developers are not going to be writing code that has to compete in a race against the operating system's RNG seeding process. (I have to explain this to PHP programmers all the time.) And the ones who are, ought to be made aware of the danger on Linux. Patching /dev/urandom to block if it's not seeded on boot seems like a winning strategy to me. Why aren't we doing that?
  - dezgeg 12y ago
    Because it could break existing boot scripts/programs that read from /dev/urandom. Linus doesn't consider "[...] the ones who are [writing code that runs at boot], ought to be made aware of the danger" as a solution.