Serious question: does this matter? The PGP key ecosystem is microscopic in 2023, and is actively atrophying. Consensus among cryptographers is that PGP hasn’t reflected anything close to acceptable cryptographic design in decades, and its lack of adoption in serious tools and products reflects that.
Without a serious use case hanging in the balance, this is just OSS drama.
Most of these distros are using PGP to distribute software, often binaries that are distributed to end users.
Gentoo as an example, requires all commits to the gentoo repo to be signed by a key in the "gentoo-developers" keyring. Gentoo also provides "stage3" images which are signed by the "gentoo-release" key. Since this is a source based distro there are no binary packages, but the main ebuild repo is signed and verified upon syncing.
I know some other distros like Arch also do similar things with PGP.
Maybe you will say that this isn't actually using PGP because it's not using the "web of trust", but I don't think this is relevant, because there is much more to PGP than the WoT and those features are being used.
This is really two different worlds. PGP for signing repos is alive and works well enough. In particular the key management is a lot easier since there's really only a small handful of entities signing things and they also control the platform. If you need to add keys (for third party repos) the process is just one more step in adding the repo in the first place so very little friction.
PGP for signing email however has been a perpetual failure. Decades later they still have not figured out a reasonable key management system, which left the community fractured and unable to scale. As you note, the Web of Trust has been a disaster for everybody except the most exceptionally paranoid who can't accept anything less. And those people talk to so few other people that they don't have the scaling issues that regular people face.
> Consensus among cryptographers is that PGP hasn’t reflected anything close to acceptable cryptographic design
Because these cryptographers haven't actually delivered anything else that's actually usable by people who just want to encrypt the bodies of their emails?
Cryptographers and cryptographic experts overwhelmingly agree that encrypting email is a chump's game[1]. If you want secure E2EE transit, Signal is widely recommended.
Signal is useless for many use cases where email is widely used. For example, it requires a phone number which just makes it useless for anything where people want to use a (possibly short-lived) pseudonym.
And note that I specifically said "people who just want to encrypt the bodies of their emails". That is still incredibly useful, even if the metadata is (obviously) not encrypted.
My understanding is that Matrix is widely considered to have acceptable design tradeoffs for pseudonymous E2EE. It isn't perfect[1], but it's miles better than the theatre of PGP encrypted emails.
> That is still incredibly useful, even if the metadata is (obviously) not encrypted.
To whom? What is the threat model in which a user who is serious about the security of their messages is better served by PGP-over-email?
PGP over email is used in the real world and used successfully.
Research about online black markets (which serves as a nice "case study") will show that the main form of communication between people there have been pasting a PGP encrypted message into a text box and sending it, and sometimes literally using email.
In a situation like this, where anonymity and privacy are critical, signal is not even remotely an option because it requires a phone number.
Matrix may be possible to use, but it would require that someone run a matrix server that allow people to make accounts with no information required for sign up, and allow signup and use of the server over tor, which are all unlikely.
PGP over email or pasted into a web form is simple, it doesn't require signing up with a phone number or any PI, it can be used over tor, and it can be done with basic utils installed on almost any Linux distro.
I suspect a lot of cryptographers have not done research about what goes on "in the real world" or "in the wild". It would be interesting for them to setup a mock situation where two people attempt to send messages to each other without doing anything that could identify them in any way, completely anonymously, to emulate what using these tools in the real world would be like for a whistleblower or journalist or whatever.
It's worth reading through the criminal complaints against various Silk Road people[1]. You'll notice two things: (1) the government nails these people despite encrypted messages, because their email metadata is more than sufficient, and (2) people whose literal lives depend on using PGP correctly fail to do so (e.g. by sending some messages without encryption, or forwarding previously encrypted messages as unencrypted).
There's a selection effect here -- the criminal complaints are the people who got caught. And drug dealers aren't exactly known for technical literacy.
I think the usability complaints here are very valid, but
chlorion has a good point that PGP still wins for particular use cases. Heck, if you're really paranoid [and metadata is not your primary concern], use PGP over Signal. I don't think any of the alternatives proposed in this thread are chainable in this way like PGP.
There's a problem here: we can't make falsifiable claims about the criminals who aren't caught. I could just as easily say the same thing about Signal!
There's one critical difference, however: governments have identified Signal and its ilk specifically as a threat to their intelligence gathering capabilities. They don't talk this way about PGP; the public signals overwhelmingly indicate that (1) virtually nobody uses PGP for anything worth surveilling, and (2) anybody who does use it for things worth surveilling bungles it (see above). Thats the government's dream!
> Heck, if you're really paranoid [and metadata is not your primary concern], use PGP over Signal. I don't think any of the alternatives proposed in this thread are chainable in this way like PGP.
This doesn't make sense. What is the "paranoid" model in which PGP provides (1) better cryptographic guarantees and (2) metadata isn't your primary concern? PGP cannot provide forward secrecy, provides all-around weaker cryptographic primitives, and is significantly harder to use correctly. It isn't a rational choice for a paranoid actor to make.
>This doesn't make sense. What is the "paranoid" model in which PGP provides (1) better cryptographic guarantees and (2) metadata isn't your primary concern? PGP cannot provide forward secrecy, provides all-around weaker cryptographic primitives, and is significantly harder to use correctly. It isn't a rational choice for a paranoid actor to make.
I think you must have misunderstood me. By "PGP over Signal" I meant PGP-encrypting messages and pasting the ASCII-armored ciphertext into the Signal client. The idea being that even if the NSA can break Signal's crypto, they might fail to also break whatever crypto you select with PGP. I should have said "both PGP and Signal", sorry for the poor communication.
I acknowledge PGP's flaws, but I like it as a ubiquitous DIY tool. I'm hoping that niche gets filled with something better. Though to be honest, I think for the "ubiquitous DIY tool" niche, forward secrecy might just be impractical.
No problem, apologies for my response based on a misunderstanding.
> The idea being that even if the NSA can break Signal's crypto, they might fail to also break whatever crypto you select with PGP.
This is an intuitive idea, but I’ll also hazard that it’s probably security theater: at a “building blocks” level, a theoretical NSA that breaks Signal’s crypto has broken the finite subgroup problem that underpins all of PGP’s cryptography as well.
(The reality is that the NSA doesn’t crack this kind of cryptography, at least not when it’s done correctly. They’re much bigger fans of exploits and implants, which they are absolutely not wasting on “ordinary” criminals.)
Hm, interesting. I don't know much about crypto math. I just typed 'gpg --version' on the command line, and it looks like my gpg has support for various public key schemes including elliptic curves. Are they all based on the same variant of the hidden subgroup problem?
Even if the math itself is bulletproof -- as you stated, there could be an implementation flaw in either the Signal code or the GPG code that effectively bypasses the math, right? See e.g. https://en.wikipedia.org/wiki/GNU_Privacy_Guard#Vulnerabilit...
>They’re much bigger fans of exploits and implants, which they are absolutely not wasting on “ordinary” criminals.
The ASCII-armor scheme I described could be helpful here too. Run Signal in a VM (e.g. with Qubes -- endorsed by Snowden). Copy/paste ciphertext in and out of the VM to GPG. Should be fairly idiotproof because ciphertext doesn't look like plaintext. Now even if the NSA sends you a Signal message that owns the VM, they still need some sort of VM escape/CPU sidechannel, or else knowledge of a vulnerability in GPG's encryption.
>The Rule of Two is a data security principle from the NSA's Commercial Solutions for Classified Program (CSfC).[3] It specifies two completely independent layers of cryptography to protect data. For example, data could be protected by both hardware encryption at its lowest level and software encryption at the application layer. It could mean using two FIPS-validated software cryptomodules from different vendors to en/decrypt data.
>The importance of vendor and/or model diversity between the layers of components centers around removing the possibility that the manufacturers or models will share a vulnerability. This way if one components is compromised there is still an entire layer of encryption protecting the information at rest or in transit. The CSfC Program offers solutions to achieve diversity in two ways. "The first is to implement each layer using components produced by different manufacturers. The second is to use components from the same manufacturer, where that manufacturer has provided NSA with sufficient evidence that the implementations of the two components are independent of one another."[4]
I agree that it's error prone and far from ideal, and that most people should be using signal or matrix or something, but I'm not sure what other practical answers there are for more intense cases where people don't have access to those things.
> To whom? What is the threat model in which a user who is serious about the security of their messages is better served by PGP-over-email?
Sending credentials to a coworker, for example. I don't care who knows that I emailed them. I don't even care if they know what it's about (database credentials), as long as they can't get the actual credentials simply by accessing the mail server. I don't have to set up any new infrastructure (not realistic within most orgs), all that is needed is for both parties to use gpg.
What kind of fakakte organization is encouraging you to email credentials? Even the most haphazard, incompetent companies I've worked with have managed to configure an off-prem 1Password group.
Small businesses. But sure, let's hand over our credentials (and a ton of money) to the americans instead of using an open source solution that has worked fine for over a decade.
Yes, it does matter. PGP is by far the most common standard for signatures used in software distribution (Git tags, RPM packages, Yum repos, Deb repos, ad-hoc signature schemes, etc.), and nothing else is particularly close in terms of number of signatures verified per day. While the absolute number of verifications is a lot lower than it could be, there is still substantial inertia behind these current standards, including US government standards.
I am also aware that you are actively involved in moving ecosystems away from PGP and towards solutions in the Sigstore ecosystem, so this is definitely not news to you. I understand you want the situation to change, but for now it's disingenuous to pretend like GPG in particular doesn't have the super majority of "market" share around signatures and that drama like this wouldn't have potential impact to a lot of folks.
> Yes, it does matter. PGP is by far the most common standard for signatures used in software distribution
No, that would be bespoke PKIs on various proprietary OSes. PGP is miniscule compared to any of these; it's not even a rounding error. This is true even when you juice the numbers with things like git signing (which is not only ignored by 99.9% of clients but doesn't even sign the relevant software artifact for end users).
> I understand you want the situation to change, but for now it's disingenuous to pretend like GPG in particular doesn't have the super majority of "market" share around signatures and that drama like this wouldn't have potential impact to a lot of folks.
If you know me, then you know I've run the numbers here[1]: even ecosystems that encouraged PGP use for decades have all the hallmarks of the signatures being completely unused. End users do not verify PGP signatures, signers do not maintain their keys; PGP's tooling encourages this behavior.
I won't deny that workflows will be broken by moving away from PGP. But those workflows are (1) a tiny, tiny minority, and (2) overwhelmingly security theater, especially now that PGP's principle feature (the WoT) is dead.
OK, fair point regarding bespoke PKI on Windows/Mac being more common. I do agree with that. I'll amend my statement to: PGP is by far the most common standard for server-side software distribution. I'll also quickly add that I agree that git signing is worthless as currently implemented.
I have read your blogpost and I agree that PyPI had unused and useless PGP support. I also agree that signatures are a waste of time when the client tooling does not verify by default. However, this is not true for the Linux distro packaging ecosystem where approximately all downloads have their signatures verified. Until you convince RedHat and Debian to move their packaging and repository formats to another standard, PGP will remain very relevant for production server software.
Don't mistake me as a defender of PGP-the-standard. I have absolutely no opinion on its cryptography. I would happily use minisign or any other tool that used only modern cryptography to produce signatures. As a distributor of software though, I don't really get to decide how to sign, I am at the mercy of government and ecosystem standards, and as a result no other signature scheme is close to the level of use that PGP has for enterprises that run server-side software.
> PGP is by far the most common standard for server-side software distribution.
This is probably true, for Linux. Windows does its bespoke PKI thing with Authenticode; OpenBSD uses signify[1].
> Until you convince RedHat and Debian to move their packaging and repository formats to another standard, PGP will remain very relevant for production server software.
This is a fair point! But I'll point something important out: these platforms are essentially using PGP as a dumb key encapsulation format; they benefit (correctly!) from being able to pre-baked rings of trusted distribution keys. The fact that they use PGP for this is an implementation quirk, one that has materially negative consequences[2].
It's not easy for them to switch, but all of these platforms would be well (better) served by switching from PGP to signify, minisign, or similar.
> I am at the mercy of government and ecosystem standards, and as a result no other signature scheme is close to the level of use that PGP has for enterprises that run server-side software.
Out of curiosity: which government standards? I'm not aware of a US Gov't standard that mandates PGP; this would be very valuable to know.
I agree that RedHat and Debian use OpenPGP mostly for its signature only and do not rely on any Web of Trust or other infrastructure for key distribution in the basic case. As a side-note just for fun:
They distribute their public keys on their own web infrastructure, so it's effectively TOFU. In your criticism of PyPI, you rightly pointed out that keys are useless unless pushed to a publicly-known key server because they aren't discoverable for users, which leads to ~no one verifying installs. I agree with this for PyPI, but in Postgres' case, if you do not have their key pulled locally, installs will fail by default. This means that users do generally install keys locally (actually they typically install the repo RPMs which configures local repositories as well as installs keys), even if the discovery mechanism isn't enforced by yum. My point here is that ecosystems without the ability to pre-bake rings of trust can still result in ~all downloads being verified as long as the client tooling defaults to the correct thing. pip not doing so is the main reason why OpenPGP signing never caught on in the Python ecosystem.
But yes, I agree: A modern day dpkg and rpm could swap to something with safer cryptography rather easily without changing anything about distribution. OpenPGP is a lot of bloat for their needs.
> Out of curiosity: which government standards? I'm not aware of a US Gov't standard that mandates PGP; this would be very valuable to know.
I don't believe any mandate OpenPGP specifically. I was more trying to get across that many institutions mandate FIPS 140-2/3, and current implementations (like on RHEL) complain if signatures are not present in their expected format. Because OpenPGP is my only choice for signing yum infrastructure and RPMs, it's a de-facto government standard today.
That's for developers. But if I'm a user of Debian and I download and install the ISO, I am not part of the web of trust. I'm trusting Debian as a central authority to ship me a valid keyring.
Which is fine; the centralization here makes sense, for the same reason I trust Microsoft to give me Windows updates or McDonalds to give me fries and burgers. But it's no more "web of trust" than either of those examples.
My guess is that there are a lot more "signature verification events" on Linux that pull from a deb or yum repository than there are on Windows servers, both because the mean server in terms of global usage seems to be Linux (though not the median, I'd think?) as well as because it seems like Linux folk rely an awful lot more on distribution repositories than Windows server users download things. Happy to be corrected if anyone has real numbers, though. My feelings are informed by my company's download statistics which may not be representative.
Without a serious use case hanging in the balance, this is just OSS drama.