People say this every time this issue comes up with, and point to the same very long Solaris RNG blog post. But that blog post doesn't support the claim: it says that urandom and random are different on Solaris, but that urandom is a FIPS-derived DRBG running from a kernel random pool --- ie, a kernel CSPRNG, like on Linux.
Can you be specific about why you believe Solaris urandom would be unsuitable for any specific cryptographic task?
The fact that the "Solaris cryptographic framework team" believes something to be true is inadequate evidence for me.
> Solaris cryptographic framework team" believes something to be true is inadequate evidence for me.
I don't follow - why would you believe that something is secure despite the developers of it saying it is not? If you trust that they are competent, wouldn't you trust a competent cryptographer who says that their code is insecure? And if you don't trust that they are competent enough to make that evaluation, why would the assumption be that they are still somehow able to write secure code, even if they can't correctly identify it as such?
In security, competence in securing things and level of paranoia about possible threats are pretty orthogonal. Someone can be very good on a ground level when it comes to following best practices to get crypto done, while also imagining all sorts of implausible threat scenarios without thinking them fully through that make them say that what they've done is "not enough."
You can find such people outside of cryptography as well: for example, the parent (or bodyguard) who won't let their child (client) leave the house because of all the deadly things that happen every day to people who leave their houses.
It's what happens when you combine a profession that relies on a certain amount of healthy anxiety, with an anxiety disorder.
The cryptographic framework teams of operating system projects have not generally been great sources of authority on cryptographic engineering, which is a much narrower speciality than a lot of people think it is.
That doesn't make them incompetent! The lawyer comparison is a telling one. I have a lawyer I work with on contract review that I think is amazing. But that doesn't mean he's my best source of wisdom about litigation, because litigation is a very specific speciality of law practice, and most lawyers don't do it. Just like the OS crypto developers, he has to know a lot of stuff about litigation to do his job, and I respect that. But that doesn't make him a litigator.
The LRNG developers thought they were accomplishing something quite important with the /dev/random reseeding/blocking system. But as you've seen from the man page update, the consensus is, that thing they were trying to accomplish was in fact counterproductive.
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.
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.
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".
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.
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.
I have personally verified that the documentation and guidance in Solaris is up to date and correct per the authors.
As I said before, and I as I will say again, the differences do matter for some administrators with specific contractual and/or other obligations and when generating "high value" keying material.
If you choose to advise others contrary to the documented guidance that Solaris provides, that is your choice.
I've just read through the Illumos code, and for Illumos at least, urandom actually seems less scary: there's a direct code path in /dev/random that reads raw entropy bytes (like thread timing) and returns it to callers, but the urandom path always goes through fips_random_inner() or equivalent.
Always use urandom. If your contracts require you not to, revise your contracts, not your code.
The reason tptacek looked at the illumos source code is because I mentioned to them that a blog post you've previously linked to about the Solaris random devices [1] appeared [2] to suggest that the entropy provided by KCF randomness providers is given out fairly directly by /dev/random (with each byte of entropy XORed with the byte returned 1024 bytes earlier). Do you know if that specific thing has been changed to stop being true since illumos diverged? Do you know if urandom has been changed to no longer always run things through fips_random_inner (as illumos does and Darren Moffat's blog post says Solaris does)?
[Edited to add: it looks as though the tweeting questions-at Darren Moffat protocol has been initiated: https://twitter.com/tqbf/status/817496091759362048 . It's also worth noting (which I failed to do previously) that two of the three random providers in the blog post are described as doing their own hashing/similar processing of the entropy bytes they provide to the random pool, and the other one appears to do so from the illumos source.]
> Use of urandom contrary to official guidance is not recommended.
This is, I think, a case where using the passive voice is suboptimal. The official guidance obviously does not recommend using urandom contrary to official guidance, nor do you. Some others do recommend it, as this whole argument shows.
More substantively, this is the part of your stance that would be, as tptacek previously suggested, equally applicable to Linux urandom prior to Linux fixing their man pages. At that time, the official guidance on urandom was that it was inferior to random in general instead of solely in the one specific case of requests before the kernel CSPRNG has been seeded. If the official guidance is incorrect about when and if urandom is inferior to random, then use of urandom contrary to official guidance should be recommended.
[2]: The blog post only briefly mentions the rndc_addbytes and rndc_getbytes functions where the entropy provision and randomness-extraction bottom out, so it is possible that it just omits the details of any additional processing performed at that level. But it at least does not mention any further processing performed on the bytes from KCF providers except in FIPS mode.
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.
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.
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."
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.
Can you be specific about why you believe Solaris urandom would be unsuitable for any specific cryptographic task?
The fact that the "Solaris cryptographic framework team" believes something to be true is inadequate evidence for me.