> Can we recognize that this is a good first step, and definitely constitutes a huge improvement over gmail/yahoo type webmail solutions?
No its not. "Browser crypto" in the form of JS is broken. There are many different possible attacks. So a false sense of security is actually worse then no security at all.
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.
A new theoretical attack was published in 2013 that showed that RC4 was still weak in TLS. While the attack was more academic, it did raise questions of what else would be possible.
We often forget that RC4 is a fundamentally broken algorithm.
> No, as explained in the writeup, the server stores your private key encrypted with your passphrase. The server never sees your passphrase, or your private key.
The only place a private key belongs to is the users machine (preferably somewhere without internet access).
> As mentioned in the writeup, there's a beautiful way you can protect even non-power-users. Because the extension downloads and verifies the webapp HTML, CSS and JS every time it runs, the web app is constantly being validated.
Imagine the following. An Attacker manages to hijack your server. They fingerprint[1] the browsers of each user and only send malicious JS to certain users that dont use your extension. No one will ever know, that they have been compromised.
No its not. "Browser crypto" in the form of JS is broken. There are many different possible attacks. So a false sense of security is actually worse then no security at all.