You can generally respond even if you don't have the link by clicking on the timestamp ("1 hour ago" or whatever) to go directly to my comment. My comment was

You can generally respond even if you don't have the link by clicking on the timestamp ("1 hour ago" or whatever) to go directly to my comment. My comment was not meant to point out that libsodium doesn't make a general OpenSSL replacement. It was meant to point out that if you restrict the problem domain enough, of course it's possible for people to write secure C. I can write a secure "Hello, World!" program; even a secure networked "Hello, World!". But being able to write a secure "Hello, World" does not mean that I am capable of writing secure C in general. Pointing out one small piece of code that is apparently secure isn't what a claim like "nobody can write secure C" is really about. "Nobody can write secure C" means that when programming in the large, implementing standardized network protocols with all of their warts, having codebases that evolve over time, that no one can consistently and reliably write secure C. So sure, libsodium may, as of now, have no known CVEs. But it's based on NaCL, which is written by djb. He's also written qmail and djbdns, both claimed to be secure. qmail has had exploitable problems on 64 bit platforms with large amounts of virtual memory: http://www.guninski.com/where_do_you_want_billg_to_go_today_4.html http://www.guninski.com/where_do_you_want_billg_to_go_today_... and djbdns has had security problems exploitable on any platform: http://article.gmane.org/gmane.network.djbdns/13864 http://article.gmane.org/gmane.network.djbdns/13864. OpenBSD is likewise a minimalist system with a heavy emphasis on security, but even with that approach, they have had to change their slogan to "Only two remote holes in the default install, in a heck of a long time." Now, of course, this does point out a few things. Minimalism is important for security; and more minimalist approaches and care in writing code can help reduce the frequency and severity of critical vulnerabilities. But even given some of the most careful, security conscious approaches, people still make mistakes. That's why, when practicing responsible security, you should use defense in depth. In addition to all of the care, review, minimalism, principal of least authority, isolation, etc, you should also use tools that can prevent whole classes of bugs at compile time.