5 ms·
Careful, the rules for random vs. urandom on Linux do not apply to all other NIX or NIX-like operating systems. As an example, Solaris makes them different int
by binarycrusader 10y ago
Careful, the rules for random vs. urandom on Linux do not apply to all other NIX or NIX-like operating systems. As an example, Solaris makes them different intentionally and provides guidance on their appropriate use.
I'll just point to my comments from last time:
https://news.ycombinator.com/item?id=7363188 https://news.ycombinator.com/item?id=7363188
https://news.ycombinator.com/item?id=7364121 https://news.ycombinator.com/item?id=7364121
- tptacek 10y agoPeople 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.
- chimeracoder 10y ago> 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?
- derefr 10y agoIn 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.
- jboy55 10y agoIts kind of like asking a lawyer, "If I do X, will that prevent me from being sued?" The answer is always No, but they think about it for a few hours before they reply.
- tptacek 10y agoThe 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.
- binarycrusader 10y agoCan 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 agoIf 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?