5 ms·

So your position is that Debian didn't go far enough? They should have disabled OpenSSL's CSPRNG entirely and redirected its internal calls to perform IO opera

So your position is that Debian didn't go far enough? They should have disabled OpenSSL's CSPRNG entirely and redirected its internal calls to perform IO operations on /dev/[u]random?

tptacek 13y ago
Modulo the fact that Debian shouldn't be mucking with the inner workings of packages in the first place, sure; stubbing out OpenSSL's CSPRNG with calls to the OS CSPRNG seems like a reasonable plan. It is, by the way, part of the NaCL design too.
- marshray 13y ago
  Last I heard, there were still some "security oriented" OSes using RC4 for their /dev/random.
  - tptacek 13y ago
    arc4random predates modern OS CSPRNGs.
    - marshray 13y ago
      So does OpenSSL. I think it's just not reasonable to expect a widely-portable crypto primitive and protocol library to judge the quality of the host /dev/[u]random and delegate to it. Of course, they seed from the host device and try to estimate the entropy it provides. Even that OS with the biased /dev/[u]random using RC4 because it was fast would keep a separate RC4 state in each process' libc to avoid the overhead of kernel calls.
      - tptacek 13y ago
        So then, you think NaCL's design decision to rely on /dev/urandom was a mistake?
        marshray 13y ago
        I think if NaCL ever gets popular that design decision will bite somebody, somewhere, on some OS. Our crypto libraries need to provide their own belt to wear with the OS-provided suspenders. Yes, I know about potential fork() bugs, but our modern VM-crazed deployments introduce that possibility at kernel level too. We need our good crypto implementers shipping good lightweight CSPRNGs, rather than the kernel developers who try to compensate with 6000 bit entropy pools.
        tptacek 13y ago
        If some OS screws up urandom so much that it bites someone, it'll bite a huge number of different apps, and not just the ones that use NaCL. Like it or not, urandom has to work; all sorts of things depend on it. The urandom ship has sailed. Meanwhile, better to have just one codebase to review, rather than 100 crappy ones, like the SecureRandom from Harmony.
        marshray 13y ago
        OK, so NaCL will not be guilty and they will be in good company. I'm sure these principles of minimal redundancy will be of great comfort to those users who get their private keys exposed. Do you see the paradox here? Find me these developers who are undoubtedly competent to implement their own CSPRNG, but prefer not to. These are the folks I want implementing the CSPRNG that will be generating my keys, rather than kernel developers who find entropy pools exciting.
        tptacek 13y ago
        You see my point, right? A lot of your security already depends on urandom working. Everyone knows this, and a lot of effort has gone into validating the kernel random driver (there have been some pretty good systems security papers on it). Given that you already depend on urandom, all a new CSPRNG gets most developers is a second single point of failure.
        13y ago

So your position is that Debian didn't go far enough? They should have disabled OpenSSL's CSPRNG entirely and redirected its internal calls to perform IO operations on /dev/[u]random?

tptacek 13y ago

Modulo the fact that Debian shouldn't be mucking with the inner workings of packages in the first place, sure; stubbing out OpenSSL's CSPRNG with calls to the OS CSPRNG seems like a reasonable plan. It is, by the way, part of the NaCL design too.

marshray 13y ago
Last I heard, there were still some "security oriented" OSes using RC4 for their /dev/random.
- tptacek 13y ago
  arc4random predates modern OS CSPRNGs.
  - marshray 13y ago
    So does OpenSSL. I think it's just not reasonable to expect a widely-portable crypto primitive and protocol library to judge the quality of the host /dev/[u]random and delegate to it. Of course, they seed from the host device and try to estimate the entropy it provides. Even that OS with the biased /dev/[u]random using RC4 because it was fast would keep a separate RC4 state in each process' libc to avoid the overhead of kernel calls.
    - tptacek 13y ago
      So then, you think NaCL's design decision to rely on /dev/urandom was a mistake?
      - marshray 13y ago
        I think if NaCL ever gets popular that design decision will bite somebody, somewhere, on some OS. Our crypto libraries need to provide their own belt to wear with the OS-provided suspenders. Yes, I know about potential fork() bugs, but our modern VM-crazed deployments introduce that possibility at kernel level too. We need our good crypto implementers shipping good lightweight CSPRNGs, rather than the kernel developers who try to compensate with 6000 bit entropy pools.
        tptacek 13y ago
        If some OS screws up urandom so much that it bites someone, it'll bite a huge number of different apps, and not just the ones that use NaCL. Like it or not, urandom has to work; all sorts of things depend on it. The urandom ship has sailed. Meanwhile, better to have just one codebase to review, rather than 100 crappy ones, like the SecureRandom from Harmony.
        marshray 13y ago
        OK, so NaCL will not be guilty and they will be in good company. I'm sure these principles of minimal redundancy will be of great comfort to those users who get their private keys exposed. Do you see the paradox here? Find me these developers who are undoubtedly competent to implement their own CSPRNG, but prefer not to. These are the folks I want implementing the CSPRNG that will be generating my keys, rather than kernel developers who find entropy pools exciting.
        tptacek 13y ago
        You see my point, right? A lot of your security already depends on urandom working. Everyone knows this, and a lot of effort has gone into validating the kernel random driver (there have been some pretty good systems security papers on it). Given that you already depend on urandom, all a new CSPRNG gets most developers is a second single point of failure.
        13y ago