
GPG and me (2015) - tosh
https://moxie.org/blog/gpg-and-me/
======
lmm
Signal is useless for the only people it could be useful for. Most people
don't need better-than-TLS security, and for those people Facebook Messenger
or any number of other options are perfectly adequate. The people who do need
better security are precisely the same people who a) can't afford to use phone
numbers as IDs, not even burner phones, when they mean a hostile government
who captures one person can immediately start tracing the location of all
their contacts and b) can't afford to trust an unaudited server run by a
company that could relatively easily be forced to cooperate with a hostile
government (particularly when the encryption protocol uses a novel semi-TOFU
construct that makes attacks a lot more plausible when the server is
cooperating).

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.

~~~
nerdponx
I don't totally understand why you can't just swap public keys and just send
GPG-encrypted messages.

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?

~~~
theptip
Here's Moxie's justification/explanation for the design decision to make
Signal centralized:

[https://signal.org/blog/the-ecosystem-is-
moving/](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.

~~~
nerdponx
That's fair, but it still entails additional trust in the host. On, e.g.
Matrix, I can run my own homeserver, so if something evil happens on another
homeserver it's not really a big deal for me, unless there's a protocol
vulnerability that allows them to mess with my own homeserver. Whereas on
Signal, I might not even know if the centralized host has been compromised,
and then as a casual user I have to wait around until a non-compromised host
has appeared.

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.

~~~
theptip
Absolutely, it's a trade-off, and is probably strictly worse for power users.

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?)

~~~
im3w1l
Ip works at a much deeper level which is why it's harder to change.
_Everything_ uses ip, including hardware and software that's no longer getting
updated but is still in use.

~~~
theptip
Which supports my point -- the quote "federation does freeze protocols in
time" was being questioned, and IPv4 is the textbook example of a federated
protocol that was frozen in time.

------
Shoothe
I think it would be good to read this post remembering that Moxie is competing
with OpenPGP with his Signal app.

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](https://tools.ietf.org/html/draft-vb-openpgp-linked-ids-01)

~~~
kelnos
> _OpenPGP at it 's core is surprisingly simple standard_

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.

~~~
thomastjeffery
> is ridiculously complicated and uses terms and concepts that the vast
> majority of people don't and won't understand.

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.

~~~
DanBC
> 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.

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...](http://reports-
archive.adm.cs.cmu.edu/anon/1998/abstracts/98-155.html)

[https://ritter.vg/blog-deanonymizing_amm.html](https://ritter.vg/blog-
deanonymizing_amm.html)

[https://people.eecs.berkeley.edu/~tygar/papers/Why_Johnny_Ca...](https://people.eecs.berkeley.edu/~tygar/papers/Why_Johnny_Cant_Encrypt/OReilly.pdf)

~~~
thomastjeffery
> Do you have any research to support your claims?

I thought it obvious from the language that I was sharing an anecdote.

------
throwaway7767
> When I receive a GPG encrypted email from a stranger, though, I immediately
> get the feeling that I don’t want to read it. Sometimes I actually
> contemplate creating a filter for them so that they bypass my inbox
> entirely, but for now I sigh, unlock my key, start reading, and with a faint
> glimmer of hope am typically disappointed.

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.

~~~
jandrese
I wonder if he has an especially onerous password? It doesn't seem like it
should be that big of a burden to pop in the password for an email. I guess he
has it set for ultra-paranoid mode where you have to enter the password every
time you even think about touching the mail.

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.

~~~
lrvick
Since my GPG subkeys are in my yubikey I literally just tap it to decrypt,
ssh, or sign commits. I also plug my key into my phone and tap it to
decrypt/sign email or decrypt passwords too.

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.

~~~
jandrese
Did you have your coworkers publish their public keys in the internet
keyservers or did you have them all exchange their public keys by hand?

~~~
Shoothe
With GPG there are many more options: have internal keyserver, have
"certification authority" key that signs new employee keys and everyone else
trusts this authority (via trust signatures. For details see:
[https://www.linuxfoundation.org/blog/pgp-web-of-trust-
delega...](https://www.linuxfoundation.org/blog/pgp-web-of-trust-delegated-
trust-and-keyservers/)

~~~
lmm
Too many options, honestly. I'd love to see a widely agreed "basic profile"
for GPG, so that everyone writing tutorials etc. would be suggesting the same
thing.

------
Jtsummers
[https://news.ycombinator.com/item?id=9104188](https://news.ycombinator.com/item?id=9104188)

This has been posted in the past, and there's a pretty good discussion on it
with more from moxie here.

------
kyberias
"Mailpile had to write 1400 lines of python code just to interface with a
native GnuPG installation for basic operations, and it still isn’t rock
solid."

But... 1400 lines of code is not that much.

------
kenbaylor
GPG has multiple uses.

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.

~~~
sigjuice
Mail on iOS/macOS and Thunderbird support S/MIME as well.

~~~
smnrchrds
Does anyone still offer S/MIME certificates?

~~~
Shoothe
Comodo does [0].

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...](https://www.comodo.com/home/email-security/free-email-
certificate.php)

------
nimbius
this smacks of he usual “hard work is hard” argument and i for one am sick of
hearing the excuses. gpg has had ecdh and curve25519 for an entire version,
rainloop and thunderbird and mutt all handle pgp seamlessly. having to trust a
key is a bit archaic, but this is all worth it for he one reason openpgp
exists: security

------
rasengan
Gpg still has a lot of uses. There isn’t one solution for every problem nor is
there a single solution for any single problem. We need to have as many tools
as possible if we the people want to win.

------
thomastjeffery
GPG is hard to use with email.

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.

------
feelin_googley
How does a user send a file of arbitrary type through Signal?

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.

~~~
Shoothe
> But there is more to PGP than just messaging.

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.

