While all what's written is true OpenPGP at it's core is surprisingly simple standard for truly decentralized trust management.
A little bit of fresh thinking can be used to revitalize OpenPGP, like integrating Keybase.io-like identities (e.g. verified Github/Twitter profile): https://tools.ietf.org/html/draft-vb-openpgp-linked-ids-01
No, this is incorrect, for several reasons.
1. Signal and OpenPGP have substantially different intended use cases. OpenPGP is a protocol for encrypting and signing fully offline, asynchronous messages using only public-key encryption and digital signature schemes such as RSA and DSA, respectively. Signal is an OTR-based protocol for both asynchronous and synchronous messaging. You can send something that looks like email using Signal, but you cannot natively use OpenPGP for encrypted instant message, voice calls or video calls.
2. Due to these differences, OpenPGP and Signal also have substantially different features. OpenPGP is not only intended for asynchronous messaging: it cannot be used for synchronous communication from a purely technical perspective. OpenPGP does not have a native system for symmetric encryption or key exchange, which means it cannot establish or maintain a secure channel efficiently. Therefore by necessity OpenPGP is slower and has higher latency because it can only natively implement public-key encryption for communication, and users must manually supply the rest. Signal's cryptosystem is much more sophisticated, and incorporates mechanisms for public-key encryption, digital signatures, private-key encryption and key-exchange.
3. Aside from just supporting synchronous communication, Signal's larger cryptosystem scope allows for security guarantees beyond the basic trifecta of confidentiality, authentication and non-repudiation that OpenPGP cannot provide. For example, Signal's protocol provides perfect forward secrecy and message delivery notification. You could only do this using OpenPGP by manually handling key exchange, then manually pre-sharing sufficiently large secret keys, or doing a new key exchange for each communication.
Furthermore, Signal is an open protocol much like OpenPGP, and in that sense doesn't "compete" with any other protoco. I use both Signal and GPG, and I'm not affiliated with Signal; that said what I'm trying to convey here is that OpenPGP has significant technical limitations that make it basically ineligible for being fairly compared with Signal (or any other similarly sophisticated messaging cryptosystem). Moxie and Perrin didn't really have to "compete" to get the Signal Protocol adopted at a massive scale by Google and Facebook - from a technical and usability perspective it enables secure communication that OpenPGP simply doesn't.
Of course you can use OpenPGP in IM [0] but as you note it won't have perfect forward secrecy and has some disadvantages but could you show me how to send an e-mail through Signal?
[0]: https://xmpp.org/extensions/xep-0027.html
> This is aside from the fact that Signal is also an open protocol
By open protocol you mean I can read specs and run my own server but I won't be able to communicate with anyone else?
This is exactly the reason I stopped bothering with PGP.
Edit: Admittedly it might be different for a trained / disciplined group of people who really have something to hide.
A simple standard doesn't automatically give you an end-user product that is simple and that anyone wants to use. GnuPG as a piece of software is ridiculously complicated and uses terms and concepts that the vast majority of people don't and won't understand.
Is it possible to make a simple experience from the OpenPGP spec, one that would be accessible to the majority of non-technical users, and could be seamlessly integrated into common communications workflows? I don't know, though I would suspect it's not.
I never said it does. What Moxie claims is that decentralized standard (like OpenPGP) will always be worse than centralized, curated solution (like Signal).
As for making OpenPGP easier to use check out OpenKeychain [0]. The developers have clear design guidelines to keep things simple.
[0]: https://www.openkeychain.org/
Another example of decentralized solution more in line of the current messanging topic: Conversations.im [1] - supports end-to-end encryption and you can set it up on your own server (uses XMPP).
I suspect it would. Certainly it's not a possibility we should write off when no-one's seriously tried.
1) For a web-based client, the keypair is stored out of the user's control, so it ends up meaning you're outsourcing trust to a third party, not just that they're trustworthy, but that they'll never experience a breach.
2) For a local client, the keypair isn't backed up anywhere, so if the user switches computers or suffers a hardware failure, the key is gone. These days you can mitigate that issue by integrating a cloud backup feature, but then you're risking that the user is protecting the private key with a weak password (which I'd expect to be common). I expect that most people don't use thick clients these days, outside of corporate use that mandates Exchange/Outlook or something similar.
3) You don't get the benefits of the web of trust. These sorts of users will never go to a key-signing party or anything like that, so one of the stated goals of OpenPGP -- that you can examine that web to feel safe that you're actually communicating with whom you think you are -- just falls away.
I'd say no-one has tried at the level of committing significant resources to it - i.e. a couple of full-time developers/designers. Certainly not the level of investment that Signal has got.
> 2) For a local client, the keypair isn't backed up anywhere, so if the user switches computers or suffers a hardware failure, the key is gone. These days you can mitigate that issue by integrating a cloud backup feature, but then you're risking that the user is protecting the private key with a weak password (which I'd expect to be common). I expect that most people don't use thick clients these days, outside of corporate use that mandates Exchange/Outlook or something similar.
All true. I'd hope that hardware tokens (Yubikey et al) could offer a solution, if we could agree on a standard for them. A good "web crypto" API would also be a huge help - browsers are more willing to add new APIs these days, so something like an encrypted input field where the cryptography is managed by the browser and the far side never sees the plaintext is a bit more feasible. Also the rise of bitcoin means people are having to get used to the level of key/passphrase security necessary for securing genuinely valuable things - we're seeing a new wave of interest in things like SSSS split keys. There are serious challenges, but there's room for hope as well.
> 3) You don't get the benefits of the web of trust. These sorts of users will never go to a key-signing party or anything like that, so one of the stated goals of OpenPGP -- that you can examine that web to feel safe that you're actually communicating with whom you think you are -- just falls away.
True, though there are also a lot more ways identities could be passed around these days. When Keybase started I dared to hope they'd help improve the OpenPGP ecosystem, though they seem to have gone down the opposite track now.
You are being a bit harsh. Sure, it's complicated if you don't understand the basics of public key encryption, but as soon as you do, GPG is trivial to use.
The problem most people have is an unwillingness to learn the basic concepts. Public key encryption is a novel idea, and really isn't hard to learn.
Do you have any research to support your claims?
Because everything I've seen says that PGP / GPG is hard to use, even for smart tech-literate people who have something to hide.
These are all old. I don't know if it's got much better.
http://reports-archive.adm.cs.cmu.edu/anon/1998/abstracts/98...
https://ritter.vg/blog-deanonymizing_amm.html
https://people.eecs.berkeley.edu/~tygar/papers/Why_Johnny_Ca...
I thought it obvious from the language that I was sharing an anecdote.
It's possible to use OpenPGP in instant messaging [0] and it works fine (transparent encryption and decryption in a client) although there are newer solutions more suited to IM [1].
For some definitions of "possible" and "works fine", sure. But OpenPGP is not natively designed for instant messaging. You can use OpenPGP as the public-key component of a cryptosystem that is suited for instant messaging, but at that point you're better off just going with an OTR protocol that already has the key-exchange and secret-key encryption functionality baked into it.
Beyond that, the page you're citing mentions this:
> The method defined herein has the following security issues:
> Key exchange relies on the web of trust model used on the OpenPGP keys network.
> There is no mechanism for checking a fingerprint or ownership of a key other than checking the user IDs on a key.
> When the recipient is not mentioned in the encrypted body, replay attacks are possible on messages.
> Replay of the signed <presence/> status is possible.
> It relies on signing or encryption of XML character data; therefore, it does not support signing or encryption of <iq/> stanzas, and it allows signing of the presence <status/> element and encryption of the message <body/> element only.
> Thus the method is not acceptable when signing or encryption of full stanzas is required. It does not enable both signing and encryption of a stanza, only signing of the presence status and encryption of the message body.
In particular, the warts of using an asynchronous protocol for a synchronous communication system are exposed here: you can replay the signed presence status, which sort of defeats the purpose of having an open connection. In a secure, synchronous communication channel, the "freshness" checks incorporate non-repudiation. This is before we even address the problem of not being able to verify key ownership aside from the user IDs.
[1] I can admittedly think of two people I know for whom I could probably find public keys and who would probably be able to decrypt a PGP'ed email if I were to send them one, but they're both Debian maintainers who I met via IRC. Whereas I have maybe a couple of hundred people on my phone from various walks of life I could send Signal messages to with literally no extra effort.
I'd rather say that Moxie implies that OpenPGP is broken beyond repair and thus the only alternative is his centralized solution. While he doesn't say this explicitly his other post (The ecosystem is moving) says exactly this.
Your anecdotal evidence while interesting does not show that OpenPGP cannot be improved, only that given enough government funding you can build a nice centralized, encrypted solution but as the top comment by lmm shows [0] it's not clear what audience is Signal aimed at:
> There is no threat model where Signal makes sense.