3 ms·

Can you personally ask the Solaris cryptography group why, in detail they think this is the case? No explanation I've seen for this makes sense. I have, and ag

Can you personally ask the Solaris cryptography group why, in detail they think this is the case? No explanation I've seen for this makes sense. I have, and again, most of the reasoning is Solaris-specific. The primary difference between urandom and random is currently higher quality re-keying for /dev/random, but there are a few internal implementation differences as well. Fundamentally, it's about constraints placed on the implementation that currently make /dev/random more "secure". In addition, for Solaris /dev/random (and getrandom(GRND_RANDOM)) when the administrator explicitly configures a specific validation mode then the bits you get come from a validated DRBG (Deterministic Random Bit Generator). /dev/urandom is not affected by that validation mode. I think the Solaris people are wrong. I'm not sure, but I'd be willing to bet a small amount of money on it. They're really not in this case, but in fairness, you'd have no way of knowing about this without source code access and a few decades of knowledge about Solaris crypto. You can find a summary from two years ago written by one of the primary Solaris cryptography engineers and architects here: https://blogs.oracle.com/darren/en_GB/entry/solaris_random_number_generation https://blogs.oracle.com/darren/en_GB/entry/solaris_random_n... ...they intend to update it soon for the next Solaris release.

tptacek 11y ago
Yeah, I've read that page. It doesn't explain what makes /dev/random better than /dev/urandom. I'm not trying to be obtuse: I'm telling you, the Linux kernel maintainer and architect for random/urandom also believes that urandom is inappropriate for long-term keys on Linux, and he is also wrong. So that particular argument from authority is not compelling to me. From what I can tell, the situation on Solaris is very similar to that on Linux: * there are two separate pools that service random and urandom, * but both use very similar generators (in particular, both use CSPRNG DRBG constructions); * some additional care is taken in random's case to ensure initialization (a good thing) * but that care doesn't matter once this system is fully booted, * and random is more aggressive about reseeding, * but that only matters for post-compromise forward-secrecy, the need for which in this case implies you are completely boned anyways. I'm standing by what I said before: use urandom, to the exclusion of all other generators, very much including Solaris.
- binarycrusader 11y ago
  both use very similar generators (in particular, both use CSPRNG DRBG constructions) Except /dev/random, which can use a different generator when the administrator configures a specific validation mode. Again, specific cryptographic requirements. that only matters for post-compromise forward-secrecy Not all cryptographic requirements are purely technical or even "ideal"; some reflect specific policy and/or customer requirements based on their specific cryptographic needs. I'm standing by what I said before: use urandom, to the exclusion of all other generators, very much including Solaris. To you, this advice is based on "authority"; to me, it's based on my long-term friendship and working relationship I've established with them over the years and my respect for them as engineers/developers/crypto experts. These are people that would run circles around most "geeks" and have been doing crypto for a decade or more and they have both the pedigree and track record to show for it. So in the end, you're of course free to believe what you'd like, and while I agree that your advice is generally reasonable, I continue to assert that it is wrong in specific cases for Solaris. As I already pointed out, and you seem to have ignored, the results you get from /dev/urandom are not the same as /dev/random in certain configurations. As I said before, the Solaris crypto team intends to update the blog post I linked before with more details at a later date. Perhaps that will have the elusive information you're looking for.
  - tptacek 11y ago
    I'm suggesting that there are no such cryptographic requirements. I'm not alone in making that suggestion; you can, for instance, look up Thomas Pornin's comments on Crypto Stack Overflow for a similar discussion. I'm sticking with this argument because it is a common one. There's a widespread belief that there are low-quality and high-quality random numbers (or, if you must, "random numbers suitable for one kind of cryptographic application" and "those suitable for another"). I'm pretty sure this is an urban myth. To me, in this case, the smoking gun is the Solaris team blog post that suggests urandom is appropriate for ephemeral and short-term secrets and nonces, and than random is appropriate for long-term secrets. Unless they're trying to communicate that random is worse than urandom, and so it's safer to use it in offline scenarios, but not in demanding online scenarios, they have the threat model exactly backwards.

tptacek 11y ago

Yeah, I've read that page. It doesn't explain what makes /dev/random better than /dev/urandom. I'm not trying to be obtuse: I'm telling you, the Linux kernel maintainer and architect for random/urandom also believes that urandom is inappropriate for long-term keys on Linux, and he is also wrong. So that particular argument from authority is not compelling to me. From what I can tell, the situation on Solaris is very similar to that on Linux: * there are two separate pools that service random and urandom, * but both use very similar generators (in particular, both use CSPRNG DRBG constructions); * some additional care is taken in random's case to ensure initialization (a good thing) * but that care doesn't matter once this system is fully booted, * and random is more aggressive about reseeding, * but that only matters for post-compromise forward-secrecy, the need for which in this case implies you are completely boned anyways. I'm standing by what I said before: use urandom, to the exclusion of all other generators, very much including Solaris.

binarycrusader 11y ago
both use very similar generators (in particular, both use CSPRNG DRBG constructions) Except /dev/random, which can use a different generator when the administrator configures a specific validation mode. Again, specific cryptographic requirements. that only matters for post-compromise forward-secrecy Not all cryptographic requirements are purely technical or even "ideal"; some reflect specific policy and/or customer requirements based on their specific cryptographic needs. I'm standing by what I said before: use urandom, to the exclusion of all other generators, very much including Solaris. To you, this advice is based on "authority"; to me, it's based on my long-term friendship and working relationship I've established with them over the years and my respect for them as engineers/developers/crypto experts. These are people that would run circles around most "geeks" and have been doing crypto for a decade or more and they have both the pedigree and track record to show for it. So in the end, you're of course free to believe what you'd like, and while I agree that your advice is generally reasonable, I continue to assert that it is wrong in specific cases for Solaris. As I already pointed out, and you seem to have ignored, the results you get from /dev/urandom are not the same as /dev/random in certain configurations. As I said before, the Solaris crypto team intends to update the blog post I linked before with more details at a later date. Perhaps that will have the elusive information you're looking for.
- tptacek 11y ago
  I'm suggesting that there are no such cryptographic requirements. I'm not alone in making that suggestion; you can, for instance, look up Thomas Pornin's comments on Crypto Stack Overflow for a similar discussion. I'm sticking with this argument because it is a common one. There's a widespread belief that there are low-quality and high-quality random numbers (or, if you must, "random numbers suitable for one kind of cryptographic application" and "those suitable for another"). I'm pretty sure this is an urban myth. To me, in this case, the smoking gun is the Solaris team blog post that suggests urandom is appropriate for ephemeral and short-term secrets and nonces, and than random is appropriate for long-term secrets. Unless they're trying to communicate that random is worse than urandom, and so it's safer to use it in offline scenarios, but not in demanding online scenarios, they have the threat model exactly backwards.