On 06/29/2017 08:01 AM, I wrote: > Some platforms are not secure and cannot be made secure.
This is relevant to the RNG discussion, and lots of other stuff besides. *) For example, you can use openssl rsa to generate a so-called private key, but it will not actually be private (in any practical sense) if the operating system's RNG has been compromised. There is little that openssl can do to detect this problem. RNGs are infamously hard to test. *) As another example, a VM guest is at the mercy of the host. *) Don't enable remote administration using "admin" as the root password. *) Etc. etc. etc. All this "should" be obvious. However, there are lots of people who use openssl but don't know much about security in general or crypto in particular. Therefore the limitations need to be prominently mentioned in the openssl documentation. That's not sufficient by itself, but it counts as a step in the right direction. Series metaphor: A chain is only as strong as its weakest link. Parallel metaphor: A fence is only as strong as its weakest picket. One of the defining properties of modern civilization is division of labor. You simply cannot have everybody be responsible for everything. We make jokes when the division is done improperly: https://www.av8n.com/physics/not-my-job.htm but even so, a great many divisions are necessary. -- If you hire a locksmith to install a deadbolt on your front door, that does not make him responsible for the fact that the back door is made of balsa wood, and the side door is standing wide open. ++ If you hire a security consultant to look at the big picture, that's different. +- The locksmith MAY remark on security problems that he notices, but he is not obliged to fix them, or even to search for them. In this parable, openssl is the locksmith. The project does not have the resources to do much beyond basic locksmithing. ======== There are deep issues here that I don't know how to solve. For example, what should be done when the situation is discovered to be insecure? a) Ignore the discovery and soldier on? b) Print a warning? c) Block? Blocking generally infuriates the users. They replace the offending software with something that doesn't block, even if it's less secure. Warnings aren't much better. It does little good to print a warning about a problem that the user does not understand and could not solve. Ignorance is not bliss. Into the valley of death rode the six hundred. Asking the user a question that has no good answers, e.g. to choose between /dev/random and /dev/urandom, does not solve the problem at all. ================================= On 06/29/2017 10:07 AM, Theo de Raadt wrote: >> As has been said many times before, what we need (but do not have) >> is /one/ source of randomness that never blocks and never returns >> bits that are guessable by the adversary. > I've been preaching this for more than a decade, and that is exactly > what I built in OpenBSD. > It isn't very hard to do this properly in the kernel. Sometimes it's not very hard ... but sometimes it's provably impossible, depending on what sort of support is available from the hardware. I stand by the assertion that some platforms are not secure and cannot be made secure. RNGs are one manifestation of this, among others. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev