3 ms·

Can you be specific about why you believe Solaris urandom would be unsuitable for any specific cryptographic task? The short version is that, on Solaris, /dev/

Can you be specific about why you believe Solaris urandom would be unsuitable for any specific cryptographic task? The short version is that, on Solaris, /dev/random has certain guarantees that /dev/urandom does not and so if you are generating long-term keys or high-value keying material, you should use /dev/random. While Solaris (over time) has tried to make the differences between the two as little as possible, for a variety of reasons, they are not identical. As just one example, one difference between the two is that, for organizations or individuals with specific security requirements, /dev/random can be configured to use only hardware-based sources registered with the kernel-level cryptographic framework by disabling the software-based provider using cryptoadm. The fact that the "Solaris cryptographic framework team" believes something to be true is inadequate evidence for me. They are the domain experts, authors of said material, and my friends. I'm sorry that you don't believe them, but I've known some of them almost a decade or more and I have no reason to believe they have anything other than the best interests of others in mind when they provide this guidance. In the end, you'll have to choose what to believe on your own, all I can tell you is that the Solaris crypto team provides the guidance that "high-value" keying material should be generated using /dev/random and that I have every reason to believe that advice is sound and competent.

tptacek 10y ago
If you're going to argue that Solaris random is more secure than Solaris urandom, it's problematic that you're claiming that urandom is OK for "short term" secrets, because that's not how cryptographic attacks on randomness work. This is the same argument Ted T'so made on HN a few years ago, and it was pretty easy to point out that attacks on things like nonces and IVs were just as devastating as attacks on things like keys. Further: no matter what authority you're going to appeal to, I'm still going to look at what the systems engineering details are. According to the document you sent, Solaris urandom uses a cryptographic DRBG seeded from a kernel random pool. That's what the LRNG does, too. In fact, if I was going to take your appeal to the Solaris cryptographic framework team seriously, I would also have to concede that Linux urandom was insecure --- because the LRNG team has maintained for years that it is inferior, and only this year is finally conceding otherwise. What am I missing? Can you be specific?
- binarycrusader 10y ago
  As a result of system configuration or specific requirements placed upon an organization, contractual or otherwise, only /dev/random is guaranteed suitable for high-value keying material. So from a programmatic standpoint, developers should use /dev/random on Solaris if they believe the material being generated is "high value". It is up to the developer to determine whether the material being generated is "high value".
  - tptacek 10y ago
    Yes, that's what I understood you to be saying before. What I'm saying is that nobody has come up with an argument for why that would be. In fact: every argument, even the ones that get down to the level of kmem-style magazines, ultimately ends up in an argument isomorphic to the argument we just had about the LRNG. No case has actually been made for why the argument is different on Solaris than it is on Linux. I'm increasingly convinced that's because there's no difference, regarding this issue, between Linux and Solaris. The generators are different, but equally safe once the generators are seeded.
    - binarycrusader 10y ago
      Let me put it plainly -- system configuration can affect /dev/random in ways that do not affect /dev/urandom. As a result, organizational or contractual requirements that a system administrator may have are only guaranteed to be met when using /dev/random. This system configuration is specific to Solaris, which is why Solaris is different than Linux.
      - tptacek 10y ago
        See, the problem with this is that you haven't put it plainly. I understand how CSPRNGs work. I understand a lot about how Linux's works, and a little bit about how Solaris's works. My sense is that if there's an argument about how Solaris urandom is inferior, I should be able to understand what it is. What is it? I'm becoming increasingly convinced that there is no difference between the urandom story on Linux and the urandom story on Solaris. Not that the generators are the same, but that the differences simply do not matter. If you don't know the specific answer, could you get one of your friends on the team to chime in? I'm reaching a threshold at which I'm going to start noisily telling people that urandom on Solaris is fine --- incidentally, a lot of very well-regarded software already agrees with me, so I feel reasonably safe joining the chorus.

tptacek 10y ago

If you're going to argue that Solaris random is more secure than Solaris urandom, it's problematic that you're claiming that urandom is OK for "short term" secrets, because that's not how cryptographic attacks on randomness work. This is the same argument Ted T'so made on HN a few years ago, and it was pretty easy to point out that attacks on things like nonces and IVs were just as devastating as attacks on things like keys. Further: no matter what authority you're going to appeal to, I'm still going to look at what the systems engineering details are. According to the document you sent, Solaris urandom uses a cryptographic DRBG seeded from a kernel random pool. That's what the LRNG does, too. In fact, if I was going to take your appeal to the Solaris cryptographic framework team seriously, I would also have to concede that Linux urandom was insecure --- because the LRNG team has maintained for years that it is inferior, and only this year is finally conceding otherwise. What am I missing? Can you be specific?

binarycrusader 10y ago
As a result of system configuration or specific requirements placed upon an organization, contractual or otherwise, only /dev/random is guaranteed suitable for high-value keying material. So from a programmatic standpoint, developers should use /dev/random on Solaris if they believe the material being generated is "high value". It is up to the developer to determine whether the material being generated is "high value".
- tptacek 10y ago
  Yes, that's what I understood you to be saying before. What I'm saying is that nobody has come up with an argument for why that would be. In fact: every argument, even the ones that get down to the level of kmem-style magazines, ultimately ends up in an argument isomorphic to the argument we just had about the LRNG. No case has actually been made for why the argument is different on Solaris than it is on Linux. I'm increasingly convinced that's because there's no difference, regarding this issue, between Linux and Solaris. The generators are different, but equally safe once the generators are seeded.
  - binarycrusader 10y ago
    Let me put it plainly -- system configuration can affect /dev/random in ways that do not affect /dev/urandom. As a result, organizational or contractual requirements that a system administrator may have are only guaranteed to be met when using /dev/random. This system configuration is specific to Solaris, which is why Solaris is different than Linux.
    - tptacek 10y ago
      See, the problem with this is that you haven't put it plainly. I understand how CSPRNGs work. I understand a lot about how Linux's works, and a little bit about how Solaris's works. My sense is that if there's an argument about how Solaris urandom is inferior, I should be able to understand what it is. What is it? I'm becoming increasingly convinced that there is no difference between the urandom story on Linux and the urandom story on Solaris. Not that the generators are the same, but that the differences simply do not matter. If you don't know the specific answer, could you get one of your friends on the team to chime in? I'm reaching a threshold at which I'm going to start noisily telling people that urandom on Solaris is fine --- incidentally, a lot of very well-regarded software already agrees with me, so I feel reasonably safe joining the chorus.