Having done just a small to moderate amount of automation in CI/CD pipelines around GPG tools I know this pain. Back then I was waiting for https://sequoia-pgp.org/ which recently (Dec 2024) released its v1.0 of the sq CLI which seemed to have a lot of promise of fixing the strange and inconsistent ergonomics of using the gpg tools.
I agree that I would love to be able to do without PGP, and I regularly see posts of cryptographers saying "it's easy, there are plenty of solutions, use sigstore, age, etc etc".
The reality is that PGP has become a de facto standard, and moving away from it is hard. I am really trying, but here are a few examples:
- Linux distributions typically use PGP to sign packages. I don't think they all agreed to switch to a new, perfect solution, so there is nothing I can do there.
- If I publish packages to Maven, I have to sign them with PGP. I could add sigstore, which I believe is supported (or in beta), but PGP will still be mandatory for the years to come, because... well sigstore is not ubiquitous. Until all the tools related to this support sigstore, there is no reason to use it. And why sigstore? If we're going for a new standard, why not another one? What if the community gets divided between sigstore and 2 alternatives?
- I use Yubikeys, and they support PGP. It works really well for signing with git, relatively well with jj. Now if I start signing my commits with the SSH key on my Yubikeys, it becomes more complicated (it's just a tooling issue of course, but that's still the case): it doesn't "just work", I need to make sure the ssh-agent works with the key, etc. I used that for 2 years and went back to PGP.
- Age is cool, but really the only use-case I have is for my password manager (currently password-store, and passage is a fork using Age instead). It's cool to use Age of course, but now with my Yubikey I need to use PIV, which I'm less comfortable with. With PGP, it really just works with my Yubikey. There is infrastructure to share PGP public keys, I don't know for Age, etc.
- Let's talk about email. Cryptographers will happily say that it makes absolutely no sense to send sensitive data over email. Yet here we are, companies use emails in practice, and having PGP encryption between colleagues because the company uses a service like Infomaniak or Proton is better than nothing. And with PGP, it means that I can use existing tooling (though last time I checked, ProtonMail was super annoying to use and required a weird bridge trick, but that's Proton's mistake IMHO).
Don't get me wrong: it is really nice that we are getting newer tools that slowly replace PGP. And because a big criticism of PGP is that it's complicated because it does everything, it means that we need many newer tools that each do one thing and do it well.
Yes, use the alternatives when possible! Use Signal, use Age, use magic-wormhole! But don't tell me I can just "do without PGP", it's totally not true.
>Now I’m still excited about the future, but I dream of a world where I can uninstall it.
From 10 years ago, but still, there is nothing today as secure as GPG. Why, because I control the key, not some application or company that embeds encryption into their product.
Since 2015 we have seen may applications that use encryption, and almost every one has given up their key once the company get a legal request from their government. Just look a China for an example.
The only thing I still do not fully understand are 'sub' keys, but that does not prevent me from using gpg.
Another thing is gpg2 pinentry on *BSD needs to be fixed. It fails 100% of the time when gpg2 is called on a GUI application (ex: Emacs) on Net/OpenBSD. On gpg1, a text prompt use to be presented in Emacs, when in X, gpg2 GUI call fails.
> From 10 years ago, but still, there is nothing today as secure as GPG.
Age?
> Since 2015 we have seen may applications that use encryption, and almost every one has given up their key once the company get a legal request from their government. Just look a China for an example.
Having done just a small to moderate amount of automation in CI/CD pipelines around GPG tools I know this pain. Back then I was waiting for https://sequoia-pgp.org/ which recently (Dec 2024) released its v1.0 of the sq CLI which seemed to have a lot of promise of fixing the strange and inconsistent ergonomics of using the gpg tools.
I agree that I would love to be able to do without PGP, and I regularly see posts of cryptographers saying "it's easy, there are plenty of solutions, use sigstore, age, etc etc".
The reality is that PGP has become a de facto standard, and moving away from it is hard. I am really trying, but here are a few examples:
- Linux distributions typically use PGP to sign packages. I don't think they all agreed to switch to a new, perfect solution, so there is nothing I can do there.
- If I publish packages to Maven, I have to sign them with PGP. I could add sigstore, which I believe is supported (or in beta), but PGP will still be mandatory for the years to come, because... well sigstore is not ubiquitous. Until all the tools related to this support sigstore, there is no reason to use it. And why sigstore? If we're going for a new standard, why not another one? What if the community gets divided between sigstore and 2 alternatives?
- I use Yubikeys, and they support PGP. It works really well for signing with git, relatively well with jj. Now if I start signing my commits with the SSH key on my Yubikeys, it becomes more complicated (it's just a tooling issue of course, but that's still the case): it doesn't "just work", I need to make sure the ssh-agent works with the key, etc. I used that for 2 years and went back to PGP.
- Age is cool, but really the only use-case I have is for my password manager (currently password-store, and passage is a fork using Age instead). It's cool to use Age of course, but now with my Yubikey I need to use PIV, which I'm less comfortable with. With PGP, it really just works with my Yubikey. There is infrastructure to share PGP public keys, I don't know for Age, etc.
- Let's talk about email. Cryptographers will happily say that it makes absolutely no sense to send sensitive data over email. Yet here we are, companies use emails in practice, and having PGP encryption between colleagues because the company uses a service like Infomaniak or Proton is better than nothing. And with PGP, it means that I can use existing tooling (though last time I checked, ProtonMail was super annoying to use and required a weird bridge trick, but that's Proton's mistake IMHO).
Don't get me wrong: it is really nice that we are getting newer tools that slowly replace PGP. And because a big criticism of PGP is that it's complicated because it does everything, it means that we need many newer tools that each do one thing and do it well.
Yes, use the alternatives when possible! Use Signal, use Age, use magic-wormhole! But don't tell me I can just "do without PGP", it's totally not true.
Keybase did a lot, for me, to smooth out the pgp/gpg experience.
>Now I’m still excited about the future, but I dream of a world where I can uninstall it.
From 10 years ago, but still, there is nothing today as secure as GPG. Why, because I control the key, not some application or company that embeds encryption into their product.
Since 2015 we have seen may applications that use encryption, and almost every one has given up their key once the company get a legal request from their government. Just look a China for an example.
The only thing I still do not fully understand are 'sub' keys, but that does not prevent me from using gpg.
Another thing is gpg2 pinentry on *BSD needs to be fixed. It fails 100% of the time when gpg2 is called on a GUI application (ex: Emacs) on Net/OpenBSD. On gpg1, a text prompt use to be presented in Emacs, when in X, gpg2 GUI call fails.
> there is nothing today as secure as GPG
Depending on what part of the huge hulk that GPG is, there are many tools that are as secure (or more) than it.
For encryption age[0] comes to mind. For signing minisign[1] or, more recently, plain ssh-keygen[2]. For encryption at rest, restic[3].
PGP having all this built-in with forward-compatibility is a liability.
[0] https://github.com/FiloSottile/age
[1] https://github.com/jedisct1/minisign
[2] https://man.openbsd.org/ssh-keygen.1
[3] https://github.com/restic/restic
The 4 tools you've listed all lack any notion of trust inheritance, which is an utterly vital property of any good crypto system.
The only viable alternative for that is x509 and that's useless for individuals due to the design.
> From 10 years ago, but still, there is nothing today as secure as GPG.
Age?
> Since 2015 we have seen may applications that use encryption, and almost every one has given up their key once the company get a legal request from their government. Just look a China for an example.
https://xkcd.com/538/ ?!?!