26 ms·

It has already been fixed with thegetrandom(2) syscall: https://lwn.net/Articles/605828/ https://lwn.net/Articles/605828/ EDIT: this is in 3.17, so it will be

by nteon 12y ago

It has already been fixed with thegetrandom(2) syscall: https://lwn.net/Articles/605828/ https://lwn.net/Articles/605828/ EDIT: this is in 3.17, so it will be a while before it is commonly available.

ultramancool 12y ago
That's great news, Linux may finally have an RNG where we don't have to choose between poor speed and poor security. However, it is still quite possible to fix /dev/urandom for existing code which runs at boot, which has caused many security issues on routers and such. Glad to see progress is being made though.
- tptacek 12y ago
  I'm just going to keep replying to comments like this to point out that Linux applications are not actually forced to choose between random hangs (which is the real problem with random(4)) and security. Linux applications should just use urandom.
  - ultramancool 12y ago
    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.
  - acqq 12y ago
    Actually they should "just use getrandom." Reasons: 1) urandom doesn't block if it's not initialized (that can happen on the embedded devices after the boot) and getrandom does that only then and never again. 2) it provides resilience against file descriptor exhaustion attacks. Documented in: https://lwn.net/Articles/605828/ https://lwn.net/Articles/605828/
    - tptacek 12y ago
      If you have getrandom(), use it. Sure.

by nteon 12y ago

It has already been fixed with thegetrandom(2) syscall: https://lwn.net/Articles/605828/ https://lwn.net/Articles/605828/ EDIT: this is in 3.17, so it will be a while before it is commonly available.

ultramancool 12y ago

That's great news, Linux may finally have an RNG where we don't have to choose between poor speed and poor security. However, it is still quite possible to fix /dev/urandom for existing code which runs at boot, which has caused many security issues on routers and such. Glad to see progress is being made though.

tptacek 12y ago
I'm just going to keep replying to comments like this to point out that Linux applications are not actually forced to choose between random hangs (which is the real problem with random(4)) and security. Linux applications should just use urandom.
- ultramancool 12y ago
  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.
- acqq 12y ago
  Actually they should "just use getrandom." Reasons: 1) urandom doesn't block if it's not initialized (that can happen on the embedded devices after the boot) and getrandom does that only then and never again. 2) it provides resilience against file descriptor exhaustion attacks. Documented in: https://lwn.net/Articles/605828/ https://lwn.net/Articles/605828/
  - tptacek 12y ago
    If you have getrandom(), use it. Sure.