[dale_glass]

GPG sadly never grew up. It's a program firmly stuck in the 90s.

The original PGP manual talked about secretly communicating with your lover. That was the usage model, transmitting secret messages to people you could sometimes meet in person, and where the model was you talking to people you directly know.

Try to verify the GPG signature on say, the Tor Browser. It's signed by "Tor Browser Developers (signing key)". Have you ever met this "Tor Browser Developers" person?

Okay, what about the web of trust? Well, GPG offers no help whatsoever in finding a way of making a connection.

And that's why it's dying, because the model it targets ceased to be relevant, and we developed plenty new needs like verifying software signed by random people on the other side of the globe, while GPG did nothing to accommodate that use.

[rany_]

> and we developed plenty new needs like verifying software signed by random people on the other side of the globe, while GPG did nothing to accommodate that use

That's actually a really common use-case for GPG. I've seen it used for this more than for email...

[dale_glass]

I mean sure, there's a bunch of developers out there signing their code with GPG. But have you actually tried verifying it properly?

To verify the tor browser correctly, you need a trust path.

Option A: You've met at least one of them directly, and for some reason decided to sign a key with the label "Tor Browser Developers" on it. How did that person prove to you that they're a legitimate Tor developer? That's a pretty tricky thing to demonstrate.

Option B: You've signed the key of somebody who did the above. Same problem, but even more dubious.

Technically, GPG allows longer trust paths, you can do Alice -> Bob -> Carol -> Tor, or I think even Alice -> Bob -> Carol -> Dave -> Tor. But the software won't help you with this.

To do the first, you download the Tor key, look at who signed it, download all those keys, and hope that one of those might have a signature by somebody you know on it.

To do the second... you're on your own. You can do a brute force key download, where you download thousands of keys in the hopes of some connection being found, and blowing up the size of your keyring. This will add lots of random people into whatever UI you use and slow down every GPG invocation. And you'll need to write some sort of shell script for that, it's a pain.

[kylebenzle]

I don't agree, it's dead simple:

For your example,

1. Download the software form the official website.

2. Verify the signature.

3. Done. If you are very concerned, you can double check the signature from a previous version from the Way back Machine.

What are the chances the official site AND the archive were both compromised?

[dale_glass]

Then you're using it wrong. GPG isn't adding anything to this that SHA256 wouldn't, and you're just relying on the SSL certificate.

Look at your list of CAs sometime. There's multiple national organizations there. Controlled by a government.

And any of those will be deemed as valid, so if you go to https://www.torproject.org/download/ and it's signed by a Chinese CA for some reason, to your browser that's perfectly fine.

> What are the chances the official site AND the archive were both compromised?

You're talking about a piece of software that's designed to hide stuff from state level actors. If you're in actual need of such a thing, that threat is pretty damn serious.

[rany_]

I agree with you here, unless you've vetted that GPG public key very well .... it is indeed no better than trusting the CA.

In a way, having JavaScript client-side verification of files as an option would be as secure (if not more secure) in most circumstances because it'd be more noob friendly. At the very least to ensure mirrors aren't doing anything nefarious.

[aborsy]

You download the Tor Browser key from a key server such as openpgp, and verify that the fingerprint is the same as that published in the Tor Browser as well as other websites. You can check who has signed that key also.

Once you verify the fingerprint, you import the key into your keyring and sign the key. It’s TOFU, so it’s done only once.

[dale_glass]

TOFU isn't the proper usage model for GPG, especially not for anything of actual importance.

GPG was made to be a self-contained system. It works based on chains of signatures (web of trust). The GPG program enforces this model, you must sign keys for a signature to be identified as valid. Approximations like "I can find the same key on this other website" aren't part of the intended model.

Key servers don't provide trust, they provide convenience. You may obtain keys from keyservers, but to actually trust a key you're supposed to do the work of verifying it. Eg, if you get my key from a keyserver the only legitimate reasons to trust it is that either you met me personally and compared fingerprints, or you trust somebody else who did that.

[anon-sre-srm]

The technology of gpg isn't the problem, it's the CLI and non-CLI UX that's the problem.

Mailvelope makes it sort-of easier, but it also fails at UX because it doesn't support clear signatures. Gmail and such should address this. Proton is an improvement but it doesn't allow using an external GPG key. keybase sort-of solved the scalability of effort problem / barrier that is web of trust, countersigning keys, and the bad UX of keyservers.

There is no readily suitable admixture of keybase, Mailvelope, and Proton that doesn't suck while supporting maximum flexibility.

[dale_glass]

Everything about GPG is a problem.

The tech is old and out of sync with modern cryptographic principles. It supports a bunch of obsolete algorithms for backwards compatibility, some of which are badly broken. It has a complicated packet format that's hard to parse and itself has security issues. It encourages bad practices like keeping ancient keys around because they have signatures on them.

It's also highly hostile to using it in any way but how it was designed. For ages, there was no library to parse OpenPGP packets. You had to run gpg itself, maybe give it a fake home directory, feed it whatever you need, parse the output... it's an enormous amount of pain even for simple things, and it's all terribly slow.

And it badly damaged the ecosystem, because either you spend lots and lots of time on reimplementing lots of crypto (which tends to be a bad idea), or you try to trick GPG into doing what you need and end up with a system that's dreadfully slow and painful to use.

The problems you speak of are probably due to this. There wasn't an usable base to build services on until very recently, when GPG was already effectively dead.

[anon-sre-srm]

You're being dramatic and uncharitable.

GPG works.

If you don't like it, invent something better.

[dale_glass]

> You're being dramatic and uncharitable.

Being uncharitable with security critical software is the right attitude to have.

> GPG works.

Yeah, not quite. I've used it extensively. I've got an excellently well connected key. I've tried writing software that uses gpg. I've reached the conclusion that it's a lost cause.

> If you don't like it, invent something better.

People have. Things like the Signal protocol for instance.

[kylebenzle]

Pgp is alive and well on the dark web and the kids with a brain are going to be just fine. You are right though, for the idiot masses "the powers that be" were successful in killing it off.

They HATE encryption, it's why control of the Bitcoin GitHub repo is so critical, an encrypted peer to peer payment option is even more dangerous than encrypted peer to peer communication.