GPG and me (2015)
moxie.org
moxie.org
There are threat models where TLS is good enough. There are (mostly quite paranoid) threat models where GPG, for all its usability issues, makes sense. There is no threat model where Signal makes sense.
Finally, GPG's usability issues are contingent and fixable. Probably in GPG-the-program, and certainly without abandoning OpenPGP-the-protocol. Throw a bit of money at it, get an actual UX designer to spend a couple of months on a nice UI, and who knows where that would take us? Whereas Signals flaws are there by design.
I also don't fully understand why Signal needs to be centralized. What if it were a generic chat server that could, optionally, receive messages via SMS?
https://signal.org/blog/the-ecosystem-is-moving/
> An open source infrastructure for a centralized network now provides almost the same level of control as federated protocols, without giving up the ability to adapt. If a centralized provider with an open source infrastructure ever makes horrible changes, those that disagree have the software they need to run their own alternative instead. It may not be as beautiful as federation, but at this point it seems that it will have to do.
I get it, but I don't really get it. The argument that "federation does freeze protocols in time" doens't make a ton of sense to me. Just look at Bitcoin: people want to keep participating, so they upgrade. It's probably easier to get a bunch of scattered servers to upgrade than a few centralized ones.
As a counterpoint to Bitcoin (which is still quite a young and under-adopted protocol), consider how hard it has proven to upgrade the IP protocol from version 4 to 6 (20 years and still not complete?)
1) We -can't- just take the backend of signal and deploy our own because all clients are hardcoded to use Signal central servers. You currently -must- trust central Signal servers to not store metadata and the government their servers live under. You totally can have end to end encryption -and- have federation as Matrix.org and Riot.im have well demonstrated.
2) There is no reason at all you need to be centralized to encrypt SMS via the signal protocol. The Silence project has already demonstrated this https://silence.im/
I have yet to find an email client that is actually comfortable to use, especially one that supports GPG out-of-box, or even with trivial setup.
It's also not portable: I can't use it from another person's machine like a web client.
1. Type message in a text file.
2. Use one command to encrypt that.
3. Send the encrypted file to the other party using what medium you deem convenient or necessary.
4. Other person uses one command to decrypt it.
That's all. There's people in police states that communicate with me regularly with that method. Non-technical people I've shown find it simple but tedious. So, that's what we should recommend if we want to avoid the complexity. If he's being fair, that's what Moxie should be comparing any new solution against when assessing how easy it can be (or isn't) to use GPG.
Further, we can either modify the program and/or put a front end in to remove what little complexity it has. Especially knock out the ridiculous delay on randomness, pick good ciphers by default, and eliminate putting the sender/receiver full name in there. Just click a person's name for the latter. I'd have already done the stuff myself if I could stomach learning C++ plus whatever the author's style is. Maybe add SaferCPlusPlus or something like that to further reduce likelihood of code injection. If preventing injection and using isolation mechanisms, one could just freeze the forked codebase not adding anything else to it past protocol-level fixes that are required over time for just the features one uses to encrypt or decrypt a text file. Then, slowly rewrite and/or subtract pieces from it to make it simpler over time.
That should've been the response a long time ago. It would've saved cryptographers and security professionals that know C++ a lot of criticism. They could've just posted a link to the simplified program I just described that's a two-step process for each party when sending messages.
What you think about my greater claim that one can use it effectively exchanging text files after learning a handful of commands? It's more important because it refutes the GPG is too hard argument.
I disagree that GPG is easy, and I think telling people to use it will mean they screw it up. But I also think efforts to make it easier are likely to automate failure.
Why would people paste the text into the composer rather than attaching the file?
> I disagree that GPG is easy, and I think telling people to use it will mean they screw it up.
We can tell people to zip up files (possibly encrypting them with a password) and attach them to an email, but I've never heard anyone argue that telling people to do that would mean that they would screw it up. What makes GPG different (other than the public/private key thing)?
Maybe one way to introduce people to GPG would be to have them use symmetric encryption at first to send messages and files (as an alternative to a password protected zip or other archive format).
Then tell them that if they create keypairs, they only need to give the other person their public key and the other person does not need to tell them the password of the day anymore to securely send the message.
Note that Im telling them to attach a text file they encrypted rather than mess with encodings and stuff. They just encrypt a file, attach it, done. Alternatively, the front end has a built in editor that outputs an encrypted file with the name they pick.
Far as failure automation, you could say that about anything. Ive reduced the problem of communicating to two steps. Most things aren't that easy centralized or decentralized.
• Users who don't trust the big advertising companies to make benevolent decisions about their data
• Users who worry about how governments tend to change, and want to prevent a future despotic administration from accessing their history.
Are we sure no single employee can be pressured by the government they operate under or the company as a whole?
Are we sure none of them are compromised and perhaps don't even know it?
Who holds the signing keys for the mobile apps? How have they been handled?
Are their internal CI servers secure? Do they do reproducible builds? How can we verify no last minute changes were slipped in by an employee or an NSA operative that has broken into their systems?
Considering Moxie has been openly opposed to third parties wanting to do externally verified reproducible builds such as f-droid... I simply can't have much confidence here.
On their website signal says they "...design open protocols, develop Open Source software, and give it away for free."
In spite of this, they do not allow spinning up your own clients and servers to validate their work without forking their client and re-implementing portions of their server.
I would challenge that we should not run from a situation where we have too much trust in one entity only to put complete trust in another.
I agree with the rest of your arguments.
I agree with the literal interpretation of this statement; most Signal users don't need that level of security. But many users want a level of security that makes it much harder for their government to intercept their messages, and I believe Signal is better for that than Facebook Messenger. I think you could make a convincing argument that Whisper could be strong-armed by the US government, but for me it seems unlikely that they could be compelled to install a back door by Turkey, Russia, China, or some other such illiberal regime (at least, less likely than Google/Facebook).
For example, see https://www.cultofmac.com/426440/whatsapp-wins-encryption-vi..., where WhatsApp (which uses the Signal protocol) was not able/willing to hand over message data to a Brazilian court. That is the feature that Signal users are choosing that FB Messenger does not have.
> For example, see https://www.cultofmac.com/426440/whatsapp-wins-encryption-vi..., where WhatsApp (which uses the Signal protocol) was not able/willing to hand over message data to a Brazilian court. That is the feature that Signal users are choosing that FB Messenger does not have.
Actually I'd say it's a feature that FB Messenger has and Signal doesn't, since the salient fact is that Facebook inc. refused to turn over private messages. Facebook has the resources to play hardball with governments; they could afford to have their service shut off for 3 days in Brazil. Does Signal have that kind of warchest?
Also note that FB Messenger doesn't have e2e encryption, and I'm fairly sure that FB would hand over any data that they do have to any government that asked. They certainly hand such information over to the NSA.
The reason I brought WhatsApp in as an example was because even Facebook, a company well-known for sharing its users' data with government security agencies, was not able to share Signal messages. That is fairly strong evidence that their protocol implementation does not have a secret backdoor; if there was such a backdoor, there would be no story of an FB exec in jail, since FB would have quietly handed over the messages that Brazil asked for.
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
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.
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.
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.
I wonder what proportion of his plaintext email from strangers is interesting. For me it's close to 0%, mostly spam or people demanding I do free work to fix issues in open source code. I really doubt this has much to do with GPG mails specifically.
I do agree that GPG has been largely a failure. A tool too general and too vaguely defined for the average user. A powerful tool but only really usable by crypto nerds. What's worse, the key distribution problem was never really solved and that's the most critical component of the entire system. Even today there are scant few email clients that will query the keyservers for you.
I have sucessfuly migrated dozens of friends and engineering teams at 3 companies to daily use of gpg via this same non-intrusive setup.
GPG is fairly pain free (and far more secure) if you put in the one time effort to set up a security token.
I assume Android. How easy is this to set up?
https://www.yubico.com/support/knowledge-base/categories/art...
It seems to be a workable option with PGP/GPG, but do you have to plug it in per use rather than leave it in as this post says (to use the onscreen keyboard)?
To make maintianing trust on this easy, all commits to this folder are made with commits signed by the owner of the respective key, and then a merge commit signed by a maintainer that verified it.
This makes it really easy for automation to have a source of trouth to check/validate commit signatures in other repos.
As it turns out, the gpg encrypted emails which were only a small fraction of the ones we received, and made up the substantial majority of actionable issues we rewarded on.
If a security researcher is not capable of encrypting email to a public key, they probably are not bringing me anything worth my time to read.
This has been posted in the past, and there's a pretty good discussion on it with more from moxie here.
But... 1400 lines of code is not that much.
1) it is now much easier to use with Mac mail. The GUI is simple to use once configured. Gpgtools.org has done a great job.
2) when you ‘sign’ email it appears visibly different than otherwise to the recipient and can be a good anti-phishing indicator.
3) I agree with Moxie that GPG encrypted mail is rare. S/MIME with its support from Microsoft, seems to be winning in that space.
S/MIME and X.509 generally are used in enterprise scenarios where people want one corporate Certification Authority and thus keeping things simple (the underlying encoding is far from simple but that's another topic).
[0]: https://www.comodo.com/home/email-security/free-email-certif...
* Add an authentiction subkey and you now have a drop-in-replacement for ssh keys.
* Password managers like "Password Store" use a git repository full of gpg encrypted files as a backend allowing for a secure password management solution that only decrypts the credential you need vs decrypting -all- of them at once like most popular tools.
* If you make use of the solid smartcard support you can even avoid your keys ever being exposed to system memory where malware can steal them.
That is because web clients like don't support it, and offline clients require setting it up.
It's a rather unfortunate reality, because GPG itself is fantastic.
Is it true that PGP has uses that do not overlap with Signal? If no, then please ignore the rest of this comment.
Is it true that a block cipher has uses that do not overlap with a stream cipher?
Signing and verfiying files.1
Encrypting files.
From what I have read, Signal is concerned with messaging. But there is more to PGP than just messaging. Files that need to be signed/verified or encrypted do not necessarily always have to be sent to or received from others.
The blog post singles out one particular use of PGP, i.e. email, and complains about one implementation of PGP: GPG. Maybe the GPG software is not user friendly. Maybe PGP email is hopelessly complex. It is easy to make those arguments. Many have done it before.
However PGP encryption, in the general sense, not when used for email and not necessarily as implemented by the GPG software, can still be useful.
Files can still be useful, even when not in the context of the "messaging" business, Twitter subsidiaries, Facebook subsidiaries, advertising, smartphones, etc.
1 I prefer ed25519 for signing and verifying files but perhaps there are advantages to PGP I am not aware of.
Exactly, OpenPGP is more like a framework for many things and the underlying structures support cryptographic agility (switching algorithms). OpenPGP can also be used to authenticate to servers (like SSH keys) and for broadly defined trust management.