Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The PGP problem (2019)

latacora.com

Post reply on HN
Print view View original

101–110 of 121 posts

Re: The PGP problem (2019)

#101

Post by zimmerfrei »

tptacek wrote: post #92
zimmerfrei wrote: post #61

As mentioned a few days ago, this post mainly covers a gpg problem not a PGP problem. I recommend people to spend some time and try out sequoia (sq) [0][1], which is a sane, clean room re-implementation of OpenPGP in Rust. For crypto, it uses the backend you prefer (including openssl, no more ligcrypt!) and it isn't just a CLI application but also as a library you can invoke from many other languages. It does signing…

I wrote the post and object to the argument that it primarily covers GnuPG issues. But stipulate that it does, and riddle me this: what's the point? You can use Sequoia set up for "modern crypto including AEAD", yes, but now you're not compatible with the rest of the installed base of PGP. If you're going to surrender compatibility, why on Earth would you continue to use OpenPGP, a design mired in 1990s decisions tha…

If you use AEAD, you clearly expect your recipients to use a recent client. Same as if you want to use PQC or any other recent feature.

If your audience is wider, dont use AEAD but make sure to sign the data too.

With respect to the 90's design, yes, it is not pretty and it could be simpler. It is also not broken and not too difficult to understand.

Re: The PGP problem (2019)

#102

Post by tptacek »

zimmerfrei wrote: post #101
tptacek wrote: post #92

Earlier quoted context omitted.

I wrote the post and object to the argument that it primarily covers GnuPG issues. But stipulate that it does, and riddle me this: what's the point? You can use Sequoia set up for "modern crypto including AEAD", yes, but now you're not compatible with the rest of the installed base of PGP. If you're going to surrender compatibility, why on Earth would you continue to use OpenPGP, a design mired in 1990s decisions tha…

If you use AEAD, you clearly expect your recipients to use a recent client. Same as if you want to use PQC or any other recent feature. If your audience is wider, dont use AEAD but make sure to sign the data too. With respect to the 90's design, yes, it is not pretty and it could be simpler. It is also not broken and not too difficult to understand.

You're missing my point. I agree that you can use Sequoia to communicate between peers also using Sequoia. But you're no longer compatible with the overwhelming majority of PGP deployments. So what's the point? Why not just use a modern tool with that same group of peers?

Re: The PGP problem (2019)

#103

Post by some_furry »

some_furry wrote: post #83
xelxebar wrote: post #59

Recently, this opinionated list of PGP alternatives went around: https://soatok.blog/2024/11/15/what-to-use-instead-of-pgp/ One use case I've not seen covered is sending blobs asynchronously with forward secrecy. Wormhole requires synchronously communicating the password somehow, and Signal requires reasonable buy-in by the recipient. Basically, I'd like to just email sensitive banking and customer data in an encrypt…

One of the projects I alluded to in that post makes a technological solution to what you want easy to build, but the harder problem to solve is societal (i.e., getting it adopted). https://github.com/fedi-e2ee/public-key-directory-specificat... My current project aims to bring Key Transparency to the Fediverse for building E2EE on ActivityPub so you can have DMs that are private even against instance moderators. One…

In case anyone reading this thread is curious about the blog post I was writing six hours ago: https://soatok.blog/2026/01/04/everything-you-need-to-know-a...

Re: The PGP problem (2019)

#104

Post by pheggs »

tptacek wrote: post #91
pheggs wrote: post #82

I tried to find something in the article that bothered me, but I don’t find it very convincing. Points like "someone can forward your email unencrypted after they decrypt it" are just... well, yeah - that can happen no matter what method you choose. It feels like GPG gets hate for reasons other than what’s actually mentioned, and I'm completely oblivious to what those reasons might be.

It's not that someone can forward your mail unencrypted. It's that in the normal operation of the system, someone taking the natural next step in a conversation (replying) can --- and, in the experience of everyone I've talked to who has used PGP in anger for any extended period of time, inevitably does --- destroy the security of the entire conversation by accidentally replying in plaintext. That can't happen in any…

well that's fair, but sounds more like a email client issue than an actual issue with gpg/pgp. My client shows pretty clearly when it gets encrypted. But maybe I am oblivious.

Re: The PGP problem (2019)

#105

Post by tptacek »

pheggs wrote: post #104
tptacek wrote: post #91

Earlier quoted context omitted.

It's not that someone can forward your mail unencrypted. It's that in the normal operation of the system, someone taking the natural next step in a conversation (replying) can --- and, in the experience of everyone I've talked to who has used PGP in anger for any extended period of time, inevitably does --- destroy the security of the entire conversation by accidentally replying in plaintext. That can't happen in any…

well that's fair, but sounds more like a email client issue than an actual issue with gpg/pgp. My client shows pretty clearly when it gets encrypted. But maybe I am oblivious.

I agree that it's an email problem, which is why I wrote a whole article about why email can't be made secure with any reasonable client. But email is overwhelmingly the messaging channel PGP users use; in fact, it's a common-cited reason why people continue to use PGP (because it allows them to encrypt email).

Re: The PGP problem (2019)

#106

Post by Avamander »

maqp wrote: post #5

The biggest issue with PGP/gpg is the difficulty of getting rid of it. If you work on big distros, or know someone who works on big distros, please (start asking them to) add https://github.com/jedisct1/minisign to pre-installed packages to facilitate transition. It's almost a chicken egg problem but the sad thing is, no project wants to swap the signing tool to a better one until everyone can verify the new signatur…

For starters I'd like to see ssh-agent not being replaced with gpg-agent. Those who need it should install it themselves.

Re: The PGP problem (2019)

#107

Post by tptacek »

defanor wrote: post #90
jeltz wrote: post #78

Earlier quoted context omitted.

What is your issue with Sequoia PGP? It is not proprietary, it is not centralized and it is much better than GunPG from what I can tell.

I have no issues with it, and actually happy to see alternative implementations. Possibly because I did not use it much, but it does look fine to me. Not as a complete GPG replacement yet, since some software still depends on GPG, but a viable one, and a suitable one for most of the manual CLI usage (ignoring that its version on slightly older systems has a different interface, adding a bit of confusion; hopefully it…

Since you mentioned me: what's the point? It would be one thing if you could (1) use Sequoia, (2) be assured of modern cryptography, and (3) maintain compatibility with the majority of the installed base of PGP users. But you can't. That being the case, why put up with all the PGP problems that Sequoia can't address? You're losing compatibility either way, so use an actually-good cryptosystem.

Re: The PGP problem (2019)

#108

Post by tptacek »

bgwalter wrote: post #97
pheggs wrote: post #82

I tried to find something in the article that bothered me, but I don’t find it very convincing. Points like "someone can forward your email unencrypted after they decrypt it" are just... well, yeah - that can happen no matter what method you choose. It feels like GPG gets hate for reasons other than what’s actually mentioned, and I'm completely oblivious to what those reasons might be.

Yes, it is odd that this criticism is only allowed for gpg while worse Signal issues are not publicized here: https://cloud.google.com/blog/topics/threat-intelligence/rus... Some Ukrainians may regret that the followed the Signal marketing. I have never heard of a real world exploit that has actually been used like that against gpg.

Why would anyone care if you brought phishing attacks on Signal users up?

Re: The PGP problem (2019)

#109

Post by pheggs »

tptacek wrote: post #105
pheggs wrote: post #104

Earlier quoted context omitted.

well that's fair, but sounds more like a email client issue than an actual issue with gpg/pgp. My client shows pretty clearly when it gets encrypted. But maybe I am oblivious.

I agree that it's an email problem, which is why I wrote a whole article about why email can't be made secure with any reasonable client. But email is overwhelmingly the messaging channel PGP users use; in fact, it's a common-cited reason why people continue to use PGP (because it allows them to encrypt email).

out of curiosity, would you like to share why you think it's an email protocol problem? Because I see that more as an email client problem

Re: The PGP problem (2019)

#110

Post by brewmarche »

eddythompson80 wrote: post #8
schoen wrote: post #6

Earlier quoted context omitted.

There's a section in this post with proposed replacements: https://www.latacora.com/blog/2019/07/16/the-pgp-problem/#th... I was also frustrated with this criticism in the past, but there are definitely some concrete alternatives provided for many use cases there. (But not just with one tool.)

I’m still frustrated by the criticism because I internalized it a couple of years ago and tried to move to age+minisig because those are the only 2 scenarios I personally care about. The overall experience was annoying given that the problems with pgp/gpg are esoteric and abstract that unless I’m personally are worried about a targeted attack against me, they are fine-ish. If someone scotch tapes age+minisig and conv…

> git/GitHub/gitlab/codeberge

Is this about commit signing? Git and all of the mentioned forges (by uploading the public key in the settings) support SSH keys for that afaik.

git configuration:

gpg.format = ssh

user.signingkey = /path/to/key.pub

If you need local verification of commit signatures you need gpg.ssh.allowedSignersFile too to list the known keys (including yours). ssh-add can remember credentials. Security keys are supported too.

Post reply on HN