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.
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.
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?
[1]: https://www.latacora.com/blog/2020/02/19/stop-using-encrypte...
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.
> 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?
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.
PGP is not a serious answer here.
[1]: https://www.justice.gov/sites/default/files/opa/press-releas...
Consider the ANOM[1] case: the FBI found it easier to FUD criminals into using a backdoored chat app than to break actual chat apps.
[1]: https://slate.com/technology/2021/12/fbi-fake-encrypted-mess...
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 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.
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.
> 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.)
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]
https://en.wikipedia.org/wiki/Multiple_encryption
As for implants, that's going to require physical or root access as a prerequisite, no?
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.
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.
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.
[1]: https://blog.yossarian.net/2023/05/21/PGP-signatures-on-PyPI...
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.
I have a strong suspicion AuthentiCode is similarly common, plus a certain winner outside the server space.
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.
[1]: https://www.openbsd.org/papers/bsdcan-signify.html
[2]: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1461834
It's interesting to consider third parties who maintain Linux package repos, like Postgres https://ftp.postgresql.org/pub/repos/yum/
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.
So there are certain assurances that keys in the keyring got verified.
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.