|
|
|
|
|
|
by nly
4534 days ago
|
|
|
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'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.