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

61–70 of 121 posts

Re: The PGP problem (2019)

#61

Post by zimmerfrei »

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 and/or encryption, for modern crypto including AEAD, Argon2, PQC.

Sure, it still implements OpenPGP/RFC 9580 (which is not the ideal format most people would define from scratch today) but it throws away the dirty water (SHA1, old cruft) while keeping the baby (interoperability, the fine bits).

[0] https://sequoia-pgp.org/

[1] https://archive.fosdem.org/2025/events/attachments/fosdem-20...

Re: The PGP problem (2019)

#62

Post by DJBunnies »

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…

Tall order.

Re: The PGP problem (2019)

#64

Post by anthk »

GPG, as OpenSSL, are too huge and complex in order to use them on daily basis.

OpenBSD has signifiy, which works fine. But I wouldn't mind something like a cleaned up age(1) but without the mentioned issues.

GNU tends to stack features like crazy. It had sense over the limited Unix tools in the 90's, but nowadays 'ls -F', oksh with completion and the like make them decent enough while respecting your freedom and not being overfeatured.

LibreSSL did the same over OpenSSL.

Re: The PGP problem (2019)

#65

Post by anthk »

F3nd0 wrote: post #30
stackghost wrote: post #27

Earlier quoted context omitted.

The mark of good security is not "has no bugs". It's how the maintainers respond to security-relevant bugs.

… in which case, ‘on Discord’ is not off to a good start.

Indeed. A mail list plus IRC would be a better start.

Go runs on far more platforms than Discord. And, worse, Discord it's propietary.

Re: The PGP problem (2019)

#66

Post by upofadown »

bayesnet wrote: post #58

I wasn’t aware of the efail disclosure timeline. Apparently Koch responds to the report by noting that GPG prints an error when MDC is stripped, which has eerie parallels to the justification behind the recent gpg.fail WONTFIX response (see https://news.ycombinator.com/item?id=46403200 )

I think the two cases are different. The EFAIL researchers were suggesting that the PGP code (whatever implementation) should throw an error on an MDC integrity error and then stop. The idea was that this would be a fix for EFAIL in that the modified message would not be passed on to the rest of the system and thus was failsafe. The rest of the system could not pass the modified message along to the HTML interpreter.

In the gpg.fail case the researchers suggested that GPG should, instead of returning the actual message structure error (a compression error in their case), return an MDC integrity error instead. I am not entirely clear why they thought this would help. I am also not sure if they intended all message structure errors to be remapped in this way or just the single error. A message structure error means that all bets are off so they are in a sense more serious than a MDC integrity error. So the suggestion here seems to be to downgrade the seriousness of the error. Again, not sure how that would help.

In both cases the researchers entirely ignored regular PGP authentication. You know, the thing that specifically is intended to address these sorts of things. The MDC was added as an afterthought to support anonymous messages. I have come to suspect that people are actually thinking of things in terms of how more popular systems like TLS work. So I recently wrote an article based on that idea:

* https://articles.59.ca/doku.php?id=pgpfan:pgpauth

It's occurred to me that it is possible that the GnuPG people are being unfairly criticized because of their greater understanding of how PGP actually works. They have been doing this stuff forever. Presumably they are quite aware of the tradeoffs.

Re: The PGP problem (2019)

#67

Post by SahAssar »

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…

But if you use the modern crypto stuff you loose interoperability, right? What is the point of keeping the cruft of the format if you still won't have compatability if you use the modern crypto? The article mentions this:

> Take AEAD ciphers: the Rust-language Sequoia PGP defaulted to the AES-EAX AEAD mode, which is great, and nobody can read those messages because most PGP installs don’t know what EAX mode is, which is not great.

Other implementations also don't support stuff like Argon2.

So it feels like the article is on point when it says

> You can have backwards compatibility with the 1990s or you can have sound cryptography; you can’t have both.

Re: The PGP problem (2019)

#69

Post by ekjhgkejhgk »

I feel like I'm taking pills, but hear me out.

If there's one thing we learned from the Snowden leaks is that the NSA can't break GPG.

Look at it from the POV of someone who like me isn't an expert: on the one hand I have ivory tower researchers telling me that GPG is "bad". On the other hand I have fact that the most advanced intelligence in the world can't break it. My personal conclusion is that GPG is actually fucking awesome.

What am I missing?

Re: The PGP problem (2019)

#70

Post by zimmerfrei »

SahAssar wrote: post #67
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…

But if you use the modern crypto stuff you loose interoperability, right? What is the point of keeping the cruft of the format if you still won't have compatability if you use the modern crypto? The article mentions this: > Take AEAD ciphers: the Rust-language Sequoia PGP defaulted to the AES-EAX AEAD mode, which is great, and nobody can read those messages because most PGP installs don’t know what EAX mode is, which…

When you encrypt something, you are the one deciding which level of interoperability you want and you can select the crypto primitives matching capabilities you know you recipient reasonably have. I don't see anything special with this: when you run a web service, you also decide if you want to talk to TLS 1.0 clients (hopefully not).

sequoia's defaults are reasonable as far as I remember. It's also bit strange that the post found it defaulted to using AEAD in 2019 when AEAD was standardized only in 2024 with RFC 9580.

But the elephant in the room is that gpg famously decided to NOT adopt RFC 9580 (which Sequoia and Proton do support) and stick to a variant of the older RFC (LibrePGP), officially because the changes to the crypto were seen as too "ground-breaking".

Post reply on HN