The OpenPGP library it uses has been audited (twice). Most of the mistakes that could have be made are avoided this way.
Edit: Yes, you lose PFS by using PGP, but it would not really be possible to negotiate PFS via, say, email.
The OpenPGP library it uses has been audited (twice). Most of the mistakes that could have be made are avoided this way.
Edit: Yes, you lose PFS by using PGP, but it would not really be possible to negotiate PFS via, say, email.
That has nothing to do with PGP. You could do the same by base64-ing an OTR session (in fact, people do that all the time).
I don't like the choice of PGP because it has non-repudability. If you send me a message, I can prove to anyone in the world that you sent me the message. OTR and Axolotl don't have this problem (only I can be sure you sent me the message and I cannot prove that I didn't fake it to anyone else).
Only if you sign the message, right? But you can use PGP to send encrypted messages without signing them.
Axolotl and OTR provide signatures, just that they are "non-transferrable" (so to speak). Not to mention that the actual crypto is more modern.
But PGP also works for printing stuff on a post-card (or you know, email) - asynchronous communication. While Axolotl does push OTR-like modes towards asynchronous use - they do involve a lot more than getting hold of a public key (say, one published in a magazine, or shown in a frame of a movie, or...).
There's been an argument since the early crypto-wars about whether gpg/pgp could (should) be made easier to use. And I absolutely think it could (and should).
Key distribution is still hard, but it's not helped by a silly cli app, and no great recommendations on how to manage trust (I suppose the gist is: get a hw token for your key, print a backup and store a revocation order in a safe, sign keys you trust and upload them to the keyservers. But even if that list seems easy, users are left with questions like: which hw tokens should I use? When I lose it, "re-trusting" keys? How big a problem is it that I've just exported meta-data about who I communicate with? Which clients easily integrates with my hw token so that I can use gpg on my smart phones, my laptop and my desktop? What if my phone lacks NFC? Can't use USB host? And last, but certainly not least -- why isn't there a fork of gpg2 that does "the right thing(tm)" out of the box -- and make this "best of breed" flow easy, rather than making all kinds of sub-key shenanigans equally cryptic?)
That's how you'd prefer to bootstrap secure communication with a journalist, or for recruiting people to demonstrate against the current regime in Egypt?
> But in principle if you assume that key distribution is "solved" then you can implement the unique parts of OTR.
How can it make sense to think of it as solved? How do you backup your keys? Your list of trusted keys? Protect them against theft? Alert others to their compromise? Get alerted when keys are compromised?
Key distribution really is the only really interesting problem in secure, trusted, communication (with secure one time pads, most problems go away. The trick is to make sure you have secure one time pads, shared only with the person(s) you want to communicate with...).
Public key encryption opens up some new ways to make the problem easier, but it's just one step in the right direction.
It's hard to say that most mistakes are avoided from two audits. Especially in a browser; there's a lot of attack vectors.
What do you consider a "trusted medium?"