The PGP Encryption Problem

[ronpunz]

Reading this article,
https://latacora.micro.blog/2019/07/16/the-pgp-problem.html, it's clear
the authors have little to no confidence in the security or capabilities
of PGP encryption.

Is this article a scare mongering propaganda exercise or do they have
valid concerns about why we should not be using PGP? The seem to
advocate using OPENBSD's Signify - do we move to this?

[Chris Laprise]

I worry when I read articles like this, because they make some good
points (along with some bad ones) against PGP but their recommendations
often demonstrate a blindness to the things they're criticizing.

Case in point: 'Use Signal.' While Signal is a pleasure to use for many
people, its tied to identities in the telephone system, which is a
problem from the 1890s not 1990s. When I see this slip up, I start
worrying about the soundness of their other recommendations.

I also don't necessarily agree with the idea that many different
encryption tools should be used for many different purposes. This is
another red flag for me, because it hides deeper UX and compatibility
issues behind a veneer of simplistic apps.

Yet another red flag is the way the author treats some of PGP's problems
as specific to an old design, when really the problem is more
fundamental. Leaking metadata, for example, is a common problem that
bedevils even programs like Tor.

And yet another is arguing from the assumption that Web Of Trust is a
necessary ingredient in PGP usage. It isn't, and that fact dispels many
claims that PGP is too complex to use.

IMO, the reason we're having this bout of "don't use PGP" is the
keyserver vulnerability that enables the recent spate of DoS attacks.
This problem is rooted in design, but luckily doesn't run deep and is
therefore solvable. That's not to say I think PGP is just fine, but if
we're going to move beyond it and its (admittedly crummy) formats then
we should have something else to manage identity across a broad range of
use cases – we should have a proper replacement. Otherwise, I fear that
information security as a field will have failed.

--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

[ronpunz]

Thanks for your comprehensive reply.

I think you're right, Signal isn't the be all and end all that some
people think it is. Here's a comprehensive pro-PGP piece
https://arstechnica.com/information-technology/2016/12/signal-does-not-replace-pgp/

[ronpunz]

On 7/17/19 11:11 AM, Chris Laprise wrote:

Sorry about top posting my earlier reply -  here it is again

[Daniel Moerner]

I agree with everything that Chris said. A few more thoughts:

First, I think the article is probably right that PGP is not the right solution for most problems for most users, mainly because of inertia against integrating subkeys into your workflow. But qubes-gpg-split makes many features of PGP work very well for Qubes users.

Second, the issue of complexity. The "Answers" section seems to suggest using seven different tools to replace PGP. And consider some of the complaints about complexity in PGP:

 The actual system doesn’t get simpler. There are keys and subkeys. Key IDs and key servers and key signatures. Sign-only and encrypt-only. Multiple “key rings”. Revocation certificates. Three different compression formats. This is all before we get to smartcard support.

This is complexity, but complexity I use. I use keys, subkeys, sign-only and encrypt-only keys, revocation certificates, etc. In fact, it is the very complexity that lets PGP get around some of the complaints in the article.

Third, the recommendation to use Signal. One complaint about encrypted PGP email is that the recipient can forward your unencrypted message to someone else. Exactly the same thing is possible in Signal! In fact, it's not trivial to construct a protocol that avoids this problem while still allowing ease of use.

Fourth, the recommendation to use signify. It's definitely a well-implemented tool. But I do miss the web of trust when it comes to verifying keys. Consider this quote from the original paper: (http://www.openbsd.org/papers/bsdcan-signify.html)

There are no key servers for signify. No web of trust. Just keys. The good news is the keys are pretty small. As demonstrated. We can stick them just about everywhere, and we do. They're on the web site, they're on twitter, they're on the top side of CD. 56 base64 characters. You can read it out loud over the phone in under a minute.

The newest keys are not on Twitter, as far as I can see. OpenBSD doesn't sell CDs anymore. I'd much rather read a fingerprint over the phone than 56 base64 characters. The main keys are hosted on all the mirrors, but the firmware keys are, to my knowledge, only verifiable by going to the release page: https://www.openbsd.org/65.html, or by downloading base.tgz and extracting it yourself.

Of course, you can use signify and provide more ways to verify keys. But note that the simplicity of signify means this requires each user to set up their own infrastructure to do so, rather than relying on the (admittedly flawed) way that PGP provides.

By the way, if people want to play with signify in Qubes, I've refreshed my copr packages of a Linux port: https://copr.fedorainfracloud.org/coprs/dmoerner/outils/

Best,

Daniel

[panina]

I think I agree with most of your criticism of the critique...
And to me, I have long felt that PGP is problematic, and not always the
best to use, and should probably be replaced.
But I do not believe that the replacement has arrived yet.

And this article points out, in a lot of places, that to benefit from
security systems, you have to use them correctly. And I think I know my
way around PGP fairly well. I've used it in a few different ways for
quite some years now.
If I'm going to learn a new system, I'll mess up, a lot. And it's likely
I'll find myself the only user of this new, shiny system.

I do test a lot of new systems. But I'm not in any way ready to leave
GPG behind just yet. It's so deeply ingrained in our ecosystem that it'd
be hard to navigate without it. Whatever we replace it with doesn't just
have to be better, or more usable. It has to be used.