This was djbs introduction to CurveCP, a project to replace TCP with an encrypted, authenticated, end-to-end solution that always gives you PFS. Unfortunately the Nacl code base (containing the CurveCP reference implementation) hasn't seen any community love that I know of, so the project seems to be kind of stillborn... although ZeroMQ recycled some of the ideas and cryptography in CurveZMQ
GnuTLS, OpenSSL, and CryptoPP are low-level libraries that for the most part provide only primitives and protocol compatibility. Keyczar, Nacl, and cryptlib are high-level libraries that provide secure constructions designed to be "developer-proof". The vast majority of people who try to build new cryptosystems using OpenSSL fail, because combining low-level crypto primitives to try to build a cryptosystem is very difficult and requires domain knowledge that people don't realize they lack.
The CurveCP implementation in libchloride doesn't claim to be embeddable, and I wouldn't personally use libcurvecpr where it mattered because it's yet well eye-balled. The author, Noah Fontes, with utmost kudos and respect to him, seems to be working on it alone and admits that he lacks that domain knowledge ("I don't claim to be a security or cryptography expert in any senses of the terms").
I think it's fair to say that CurveCP isn't production ready despite being "developer proof" since 2011.
What I mean to say about the project being "stillborn" is that it hasn't progressed to something like an IETF RFC or gained any real traction as an alternative to TLS. It's a real shame because a cryptographically secure session layer and long-overdue rework of TCP are things we really need. Projects like Mosh (SSH alternative) have already demonstrated how mobility can be improved with good crypto at the session layer, rather than above it.
Going back to ZeroMQ... it's one of the most "developer proof" libraries out there for messaging, yet they decided to implement the half they felt they could get away with. They could have opted for a "curvecp://<key>" URI scheme for bind() and connect(), defaulted to UDP under the hood, and perhaps gained endpoint mobility, but it didn't happen. Pragmatic perhaps, but if there was anyone who could have pushed CurveCP further it would have been those guys.
I don't see the complexity and mess of TLS going away anytime soon... and I expect most people implementing TLS in C or C++ to be using GnuTLS, OpenSSL or perhaps Mozilla NSS for the foreseeable future.
If you are talking about CurveCP, I don't have strong opinions. In fact, there are issues with CurveCP; CodesInChaos posted a critique of the CurveCP key exchange awhile back. Trevor Perrin pointed out at Baysec a few months back that key exchanges are particularly hard to get right, using CurveCP as an example. CurveCP may very well be DOA. I don't know.
If you're talking about Nacl, though, from everything I can tell Nacl is very successful and seems to have a pretty bright future. Certainly, I'd recommend Nacl over any other crypto library you might use to build a new system with.
http://media.ccc.de/browse/congress/2010/27c3-4295-en-high_s...
This was djbs introduction to CurveCP, a project to replace TCP with an encrypted, authenticated, end-to-end solution that always gives you PFS. Unfortunately the Nacl code base (containing the CurveCP reference implementation) hasn't seen any community love that I know of, so the project seems to be kind of stillborn... although ZeroMQ recycled some of the ideas and cryptography in CurveZMQ