7 ms·

What about https://github.com/jedisct1/libsodium https://github.com/jedisct1/libsodium then? Very high profile, no CVEs found to date. EDIT: Can't respond to

What about https://github.com/jedisct1/libsodium https://github.com/jedisct1/libsodium then? Very high profile, no CVEs found to date. EDIT: Can't respond to lambda below. I was responding to THIS assertion, not proposing libsodium as a general purpose openssl replacement: "nobody can write secure C." To which I said, here's a project that's written in C that's apparently secure.

lambda 10y ago
It also doesn't interoperate with any widely deployed crypto standards. Yes, NaCL is a better design for cryptographic primitives, being much more limited in scope and reducing the number of primitives supported. It's great, if you can control both sides of the protocol so you can use something like this, and if you can also write your own safe, secure protocol code on top of it that doesn't introduce any errors of its own. The problem being solved by OpenSSL is much harder; for interoperability, you need to support a much wider range of standards, and they are always changing. It also supplies the full protocol stack to implement TLS, including multiple versions of TLS, rather than just the crypto primitives. It's when you have code that is trying to do all of this, and evolve over time, with contributions from multiple people, that it's easy for such mistakes to creep in. Writing a single piece of code in C with no vulnerabilities is hard, but not impossible; maintaining such a piece of code, implementing complex and changing standards, over time, over a variety of platforms, and so on, without introducing vulnerabilities, does seem to be impossible in C.
- tptacek 10y ago
  Not interoperating with TLS's CBC construction is a feature, not a liability.
nickpsecurity 10y ago
Almost always by super-human's, though. These people that can do in programming what most people can't do across the board. Including write C code with almost no defects. Now, what about mere humans with average or above average intelligence? What about us!? We can't be basing our expectations of what most can do with garbage like C on what the mental elite can pull off.
- ArkyBeagle 10y ago
  This is the thing - it's NOT super human. It's not even difficult. It's nothing more than learned behavior. I, for example, just had the advantage of having employers pay me to learn this stuff on the job. Debugging a C++ template crash is difficult. Finding out why the Windows TCP stack does certain things is difficult. Writing clean and non-memory-over-writey 'C' isn't even close to those.
  - nickpsecurity 10y ago
    I have no idea what kinds of apps you're writing where it's that easy. Most apps with widespread use do complex things with code integrated in from many styles and skill levels of programmer. They have to get code cranked out quickly to meet deadlines. In the process, someone slips up with a pointer, array, whatever. This has been true for many projects done by experienced C programmers. Hence, if not superhumans, then writing safe/secure C in such circumstances takes unusual talent. Whereas, it's effortless for people using something like Modula-3 to avoid most of those problems. By design. And checking for fools that turned it off is easy to automate: text search for "UNSAFE."
    - ArkyBeagle 10y ago
      Hi nick! I don't know how to describe what it is I do. For lack of a better rubric - "embedded". Frequently, large things are involved, large things with diesel engines. Shipping bugs is always an option. I'm pretty adamant about not doing that any more than I have to. And I work fast enough that this isn't a problem - most of that is that I know how to code & test very quickly. But there's furniture in the code to check for the usual 'C' bug suspects. And yes - "hell is other people's code." This is why I try very very hard not to leave these sort of bugs around, build test fixtures and do other things to defend myself. I have used static analysis now and again. It's kind of nice. Again, and again, and again, dysfunctional organizations abound and it's possible to avoid them altogether. But first you must earn to identify them. It would be absolutely fascinating to work with a security pro to see how I'm doing. Right now, that's not in the cards.
lambda 10y ago
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.
- CiPHPerCoder 10y ago
  > 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. https://twitter.com/CiPHPerCoder/status/727530489255485440 https://twitter.com/CiPHPerCoder/status/727530489255485440

lambda 10y ago

It also doesn't interoperate with any widely deployed crypto standards. Yes, NaCL is a better design for cryptographic primitives, being much more limited in scope and reducing the number of primitives supported. It's great, if you can control both sides of the protocol so you can use something like this, and if you can also write your own safe, secure protocol code on top of it that doesn't introduce any errors of its own. The problem being solved by OpenSSL is much harder; for interoperability, you need to support a much wider range of standards, and they are always changing. It also supplies the full protocol stack to implement TLS, including multiple versions of TLS, rather than just the crypto primitives. It's when you have code that is trying to do all of this, and evolve over time, with contributions from multiple people, that it's easy for such mistakes to creep in. Writing a single piece of code in C with no vulnerabilities is hard, but not impossible; maintaining such a piece of code, implementing complex and changing standards, over time, over a variety of platforms, and so on, without introducing vulnerabilities, does seem to be impossible in C.

tptacek 10y ago
Not interoperating with TLS's CBC construction is a feature, not a liability.

nickpsecurity 10y ago

Almost always by super-human's, though. These people that can do in programming what most people can't do across the board. Including write C code with almost no defects. Now, what about mere humans with average or above average intelligence? What about us!? We can't be basing our expectations of what most can do with garbage like C on what the mental elite can pull off.

ArkyBeagle 10y ago
This is the thing - it's NOT super human. It's not even difficult. It's nothing more than learned behavior. I, for example, just had the advantage of having employers pay me to learn this stuff on the job. Debugging a C++ template crash is difficult. Finding out why the Windows TCP stack does certain things is difficult. Writing clean and non-memory-over-writey 'C' isn't even close to those.
- nickpsecurity 10y ago
  I have no idea what kinds of apps you're writing where it's that easy. Most apps with widespread use do complex things with code integrated in from many styles and skill levels of programmer. They have to get code cranked out quickly to meet deadlines. In the process, someone slips up with a pointer, array, whatever. This has been true for many projects done by experienced C programmers. Hence, if not superhumans, then writing safe/secure C in such circumstances takes unusual talent. Whereas, it's effortless for people using something like Modula-3 to avoid most of those problems. By design. And checking for fools that turned it off is easy to automate: text search for "UNSAFE."
  - ArkyBeagle 10y ago
    Hi nick! I don't know how to describe what it is I do. For lack of a better rubric - "embedded". Frequently, large things are involved, large things with diesel engines. Shipping bugs is always an option. I'm pretty adamant about not doing that any more than I have to. And I work fast enough that this isn't a problem - most of that is that I know how to code & test very quickly. But there's furniture in the code to check for the usual 'C' bug suspects. And yes - "hell is other people's code." This is why I try very very hard not to leave these sort of bugs around, build test fixtures and do other things to defend myself. I have used static analysis now and again. It's kind of nice. Again, and again, and again, dysfunctional organizations abound and it's possible to avoid them altogether. But first you must earn to identify them. It would be absolutely fascinating to work with a security pro to see how I'm doing. Right now, that's not in the cards.

lambda 10y ago

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.

CiPHPerCoder 10y ago
> 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. https://twitter.com/CiPHPerCoder/status/727530489255485440 https://twitter.com/CiPHPerCoder/status/727530489255485440