3 ms·

Here's what I can say: I asked the crypto authors about the guidance in the past. They assured me the text had been updated to reflect current guidance. When

Here's what I can say: I asked the crypto authors about the guidance in the past. They assured me the text had been updated to reflect current guidance. When I asked Darren about this in the past (paraphrasing from memory), the response was that constraints on the implementation and/or applied by system configuration ensure that bytes from /dev/random provide the highest quality random numbers produced by the generator, and so are the most suitable for high-value keying material. So as I understand it, yes, it's more than just applicable to the case of requests before the kernel CSPRNG has been seeded. Also, keep in mind that on Solaris live migration may mean that your process (well, the zone hosting it anyway) is live migrated to an entirely different system and so may be hosted by a different kernel without your process ever being aware of it. So relying on assumptions about the state of the kernel is inadvisable. If I receive any additional information I can share, I will do so.

tptacek 10y ago
Once again, cryptographically speaking, there's no practical sense in which a random is "high quality" or "low quality". There are cryptographically unpredictable numbers, and there are insecure numbers. As you can see from the Illumos code, unless Solaris deliberately broke their urandom (hint: they did not), urandom on Solaris produces (so long as it's seeded) cryptographically unpredictably random numbers. That's the second randomness canard introduced on this subthread (the first being that there is a kind of cryptographic random number that is suitable for IVs and nonces but not for "long-term" cryptographic secrets). The two canards are related, but not identical. I doubt the Solaris KCF team is thrilled to be virtually interposed into this argument; it is unlikely that they disagree with what I'm saying, since I'm making a pretty banal observation about FIPS cryptographic DRBGs and about the plain meaning of the KCF random code. The Solaris urandom story is, in practical (end-user) terms, the same as urandom's story on Linux. There's some confirmation of this on Twitter, if you care to look.
- binarycrusader 10y ago
  Once again, cryptographically speaking, there's no practical sense in which a random is "high quality" or "low quality". There are cryptographically unpredictable numbers, and there are insecure numbers. Once again, all information available to me contradicts your assertions: "Bytes retrieved from /dev/random provide the highest quality random numbers produced by the generator, and can be used to generate long term keys and other high value keying material." "While bytes produced by the /dev/urandom interface are of lower quality than bytes produced by /dev/random, they are nonetheless suitable for less demanding and shorter term cryptographic uses such as short term session keys, paddings, and challenge strings." https://docs.oracle.com/cd/E53394_01/html/E54777/urandom-7d.html https://docs.oracle.com/cd/E53394_01/html/E54777/urandom-7d.... I doubt the Solaris KCF team is thrilled to be virtually interposed into this argument; it is unlikely that they disagree with what I'm saying, since I'm making a pretty banal observation about FIPS cryptographic DRBGs and about the plain meaning of the KCF random code. Everything I've said has been taken from either the current documentation or from conversations I've had with the crypto team. Since they confirmed the documentation is up to date and correct, then I don't see how your assertion can possibly be correct. The Solaris urandom story is, in practical (end-user) terms, the same as urandom's story on Linux. There's some confirmation of this on Twitter, if you care to look. I see no confirmation on Twitter from anyone that is currently working on Solaris -- only a past member that left the organization some time ago. Until I have independent confirmation from the team involved, I'll have to agree to disagree.
  - tptacek 10y ago
    So: the man page says so.

tptacek 10y ago

Once again, cryptographically speaking, there's no practical sense in which a random is "high quality" or "low quality". There are cryptographically unpredictable numbers, and there are insecure numbers. As you can see from the Illumos code, unless Solaris deliberately broke their urandom (hint: they did not), urandom on Solaris produces (so long as it's seeded) cryptographically unpredictably random numbers. That's the second randomness canard introduced on this subthread (the first being that there is a kind of cryptographic random number that is suitable for IVs and nonces but not for "long-term" cryptographic secrets). The two canards are related, but not identical. I doubt the Solaris KCF team is thrilled to be virtually interposed into this argument; it is unlikely that they disagree with what I'm saying, since I'm making a pretty banal observation about FIPS cryptographic DRBGs and about the plain meaning of the KCF random code. The Solaris urandom story is, in practical (end-user) terms, the same as urandom's story on Linux. There's some confirmation of this on Twitter, if you care to look.

binarycrusader 10y ago
Once again, cryptographically speaking, there's no practical sense in which a random is "high quality" or "low quality". There are cryptographically unpredictable numbers, and there are insecure numbers. Once again, all information available to me contradicts your assertions: "Bytes retrieved from /dev/random provide the highest quality random numbers produced by the generator, and can be used to generate long term keys and other high value keying material." "While bytes produced by the /dev/urandom interface are of lower quality than bytes produced by /dev/random, they are nonetheless suitable for less demanding and shorter term cryptographic uses such as short term session keys, paddings, and challenge strings." https://docs.oracle.com/cd/E53394_01/html/E54777/urandom-7d.html https://docs.oracle.com/cd/E53394_01/html/E54777/urandom-7d.... I doubt the Solaris KCF team is thrilled to be virtually interposed into this argument; it is unlikely that they disagree with what I'm saying, since I'm making a pretty banal observation about FIPS cryptographic DRBGs and about the plain meaning of the KCF random code. Everything I've said has been taken from either the current documentation or from conversations I've had with the crypto team. Since they confirmed the documentation is up to date and correct, then I don't see how your assertion can possibly be correct. The Solaris urandom story is, in practical (end-user) terms, the same as urandom's story on Linux. There's some confirmation of this on Twitter, if you care to look. I see no confirmation on Twitter from anyone that is currently working on Solaris -- only a past member that left the organization some time ago. Until I have independent confirmation from the team involved, I'll have to agree to disagree.
- tptacek 10y ago
  So: the man page says so.