We should talk about Werner Koch's response gpg.fail on the oss-security mailing list.
openwall.com/lists/oss-securit…
Yes, and actually the only serious bug from their list.
Koch either didn't watch the talk, he is in such defense of his own ego that he can't see how serious the bugs were, or he's tacitly admitting that PGP is not a serious recommendation.
Can you distinguish between these three explanations?
Could it be all of them are true?
ImpactWhile this may allow remote code execution (RCE), it definitively causes memory corruption.
Good research.
I think this sarcastic quip is what reveals Werner Koch's opinion about the security researchers and their work.
The rest of his email is measured (and partly responding to other mailing list participants rather than the disclosure directly).
Soatok Dreamseeker
Als Antwort auf Soatok Dreamseeker • • •I think 2026 should be the year that we make PGP irrelevant.
Not just GnuPG (Koch's implementation), but the entire OpenPGP ecosystem.
Most cryptographers I talk to gave up on PGP over a decade ago.
(After seeing the arrogance and dismissiveness that bled through Koch's oss-security email, who can blame them?)
If you're a country whose government mandates the use of PGP, even in obscure places, let's talk about how to replace PGP.
elrido
Als Antwort auf Soatok Dreamseeker • •Soatok Dreamseeker
Als Antwort auf elrido • • •Soatok Dreamseeker
Als Antwort auf Soatok Dreamseeker • • •What To Use Instead of PGP - Dhole Moments
Dhole Momentselrido mag das.
elrido
Als Antwort auf Soatok Dreamseeker • •@Soatok Dreamseeker Thank you very much for the link and I do agree with pretty much all of the recommendations of alternative tools for the non-email use cases. I wasn't aware the I can also sign my git commits with ssh, which would let me use a single toolchain (ssh) for talking to, authenticating & signing my commits instead of two stacks (ssh + gpg). Really appreciate this!
I do have my own mailserver and 25 years of email history, 20 of those I have been using pgp on at least some channels that greatly matter to me (some business, mostly activism and FOSS projects). So a) I do want to keep access to those, incl. my long revoked old and insecure keys and legacy crypto that those used. I could create a toolchain to decrypt all those old mails and store them in my IMAP account, but that would possible loose their metadata and certainly eliminate the possibility to validate any of their signatures.
My b) problem is that switching to signal is not really
... mehr anzeigen@Soatok Dreamseeker Thank you very much for the link and I do agree with pretty much all of the recommendations of alternative tools for the non-email use cases. I wasn't aware the I can also sign my git commits with ssh, which would let me use a single toolchain (ssh) for talking to, authenticating & signing my commits instead of two stacks (ssh + gpg). Really appreciate this!
I do have my own mailserver and 25 years of email history, 20 of those I have been using pgp on at least some channels that greatly matter to me (some business, mostly activism and FOSS projects). So a) I do want to keep access to those, incl. my long revoked old and insecure keys and legacy crypto that those used. I could create a toolchain to decrypt all those old mails and store them in my IMAP account, but that would possible loose their metadata and certainly eliminate the possibility to validate any of their signatures.
My b) problem is that switching to signal is not really an option for me. Here in Switzerland I have only found two groups that use it, most here seem to prefer Threema. There is no native SailfishOS client, so I have to install it via aurora store (but it does work without google play services, unlike Threema). I can't host my own signal server, as far as I have seen. I don't know how feasible it were to try and convert my email history into signal messages.
At the same time everyone can get my emails and every device seems to have native clients for it. And sure, most people wont be able to get encrypted mails from me, but at least 5% of my mail traffic can and I like to keep that option.
As someone running mailservers I whole heartedly can attest that they are a PITA to set up, and the many protocols, extensions and stacks involved in it are a well ripened, many-layered pile of manure, having grown and aged very badly.
But I don't see it going away, unless we can figure out a migration path that at least can preserve read-only archives of the past communication, with search-indexing for the non-encrypted meta-data and plain text bodys.
Fabio Valentini
Als Antwort auf Soatok Dreamseeker • • •VVelox
Als Antwort auf Fabio Valentini • • •maryjane
Als Antwort auf Soatok Dreamseeker • • •Honest question, since it is one of the main uses for OpenPGP regardless of implementation:
How do you replace package signing?
Just stick with checksums?
VVelox
Als Antwort auf maryjane • • •Petr Menšík
Als Antwort auf Soatok Dreamseeker • • •Soatok Dreamseeker
Als Antwort auf Petr Menšík • • •F4GRX Sébastien
Als Antwort auf Soatok Dreamseeker • • •@pemensik you cant do that. Email is a de facto standard that works *everywhere*. You cant ditch that for another protocol before decades, and thats supposing tge new stuff has all the required features
It's good to be idealist but the industrial world needs practical solutions. I would love a good replacement for PGP, but lets be honest, there is no tool that can protect files and email before transfer NOW.
Maybe the path forward is fixing pgp, not yeeting it.
Soatok Dreamseeker
Als Antwort auf F4GRX Sébastien • • •Soatok Dreamseeker
Als Antwort auf Soatok Dreamseeker • • •@f4grx @pemensik You cannot fix emails. I'm sorry, but that's just not going to happen.
You either replace email or you give up entirely. There's too much political power in the hands of people that do not want anything solved.
PGP is downstream of that mess. People have tried for years to fix PGP. That's what Sequoia allegedly was going to be.
That still hasn't happened, because PGP implementations refuse to say "we only support the newest stuff, and only the features and use cases that need to exist".
Why was the
\fflag even in GnuPG? That shouldn't be a feature. If you designed a CTF challenge with that feature the judges would tell you it's too obvious and stupid, and to go back to the drawing board.VVelox
Als Antwort auf Soatok Dreamseeker • • •@Soatok Dreamseeker As some one familiar with the whole stack when it comes to email, it is not that there is any political power holding back adding in something to replace PGP with a working RFC, it is that there is a stupidly large number of projects involved to make it all work and it requires getting every one on board. It is why new RFCs tend to get adopted slowly for it. Takes it's way to make it through the entire ecosystem.
If you want a closer to home example, look at the encryption stuff you've mentioned working on for ActivityPub/Mastodon. So once you get it implemented for Mastodon, there is still every other ActivityPub server that also needs to support it as well.
And here we are talking about a ecosystem that is incredibly small compared to the entire stack that is email.
Soatok Dreamseeker
Als Antwort auf VVelox • • •@vvelox @f4grx @pemensik I stand by the following:
VVelox
Als Antwort auf Soatok Dreamseeker • • •@Soatok Dreamseeker Ohh, I completely agree on both of those points. :)
I'm just saying the issue is not those with political power keeping it back, but implementing a standard for it is utterly doomed thanks to the need to get every one on the same page and frankly good look with that.
Petr Menšík
Als Antwort auf Soatok Dreamseeker • • •Soatok Dreamseeker
Als Antwort auf Petr Menšík • • •@pemensik
No. The problems with encrypted email are unsolvable by RFCs.
This is why github.com/soatok/awoo-specifi… is still an empty repo: It's work I planned to do after I solved key transparency for Fedi and E2EE happens.
Literally, soatok.blog/2025/12/15/announc…
soatok/awoo-specification
GitHubOrman
Als Antwort auf Soatok Dreamseeker • • •Soatok Dreamseeker
Als Antwort auf Orman • • •@orman @pemensik And there's half a century of legacy baked into the email RFCs and software that implements them.
Most end users don't care about RFCs or protocols. They care about their user experience.
Thus, I'm going to write an encrypted alternative to email, rather than try to fix email itself.
It will be encrypted always. There is no plaintext mode. The entire failure mode of "oops I replied to an encrypted email with plaintext" is a stupid problem to have.
VVelox
Als Antwort auf Soatok Dreamseeker • • •@Soatok Dreamseeker If you don't mind me saying, you are looking are likely looking at creating a encrypted messaging system than a actual alternative to email.
Saying you are creating a alternative to email means tackling a whole hell of a lot of infrastructure that needs replacing.
I'm not saying you should not start work on something like that, I just think you massively underestimate how much is involved or some of the unique issues bodies the server can't parse as they are encrypted bring(such as it makes adversarial handling much harder as writing a replacement for Spamassassin needs to use headers only then, meaning you now need to split it in two as you need part to run on the server and part to run on the viewing client). Writing a replacement for Sieve means similar issues as well.
Soatok Dreamseeker
Als Antwort auf VVelox • • •VVelox
Als Antwort auf Soatok Dreamseeker • • •@Soatok Dreamseeker Cool. :)
Nearly everybody that says that seems to not understand what they are biting off. =^.^=
But yeah, definitely interested.
That said some thoughts I have is you can reduce the amount of work involved. Recycle non-foot gun bits.
From a parsing/handling perspective there are some nice things about the basic message format. The way the headers work makes it easy to handle and it gives you an order of when stuff was added by handling servers along the route.
Using Maildir++ for storage is basically a must. SQL etc does not scale in any meaningful way when it comes to this.
IMAP/Sieve is another bit that can easily being reused if using a very limited subset of basic format. You can use something rock solid with lots of auth choices etc like Dovecot. This also avoids having to deal with the complex issue of making caching and the like work nice for fetching headers.
Also using a limited subset of stuff from
... mehr anzeigen@Soatok Dreamseeker Cool. :)
Nearly everybody that says that seems to not understand what they are biting off. =^.^=
But yeah, definitely interested.
That said some thoughts I have is you can reduce the amount of work involved. Recycle non-foot gun bits.
From a parsing/handling perspective there are some nice things about the basic message format. The way the headers work makes it easy to handle and it gives you an order of when stuff was added by handling servers along the route.
Using Maildir++ for storage is basically a must. SQL etc does not scale in any meaningful way when it comes to this.
IMAP/Sieve is another bit that can easily being reused if using a very limited subset of basic format. You can use something rock solid with lots of auth choices etc like Dovecot. This also avoids having to deal with the complex issue of making caching and the like work nice for fetching headers.
Also using a limited subset of stuff from the basic email message format would mean you can also get a jump on adversarial handling via relying on header bits Spamassassin can under stand.
Going to need some meaningful manner to ingest stuff that does not really need to be encrypted, such as what ever is being used to replace the likes of msmtp or ssmtp(the commandline sendmail replacements).
Petr Menšík
Als Antwort auf Soatok Dreamseeker • • •VVelox
Als Antwort auf Petr Menšík • • •Soatok Dreamseeker
Als Antwort auf Petr Menšík • • •Petr Menšík
Als Antwort auf Soatok Dreamseeker • • •VVelox
Als Antwort auf Petr Menšík • • •Soatok Dreamseeker
Als Antwort auf VVelox • • •GitHub - C2SP/C2SP: Community Cryptography Specification Project
GitHubVVelox
Als Antwort auf Soatok Dreamseeker • • •@Soatok Dreamseeker You realize you are having a completely different coversation with @Petr Menšík than me?
I'm the one that originally said fuck the IETF in this part and said the important part was the RFC. I agreed with you.
FurryBeta
Als Antwort auf Soatok Dreamseeker • • •It’s amazing to me how many people think email is secure, with or without the S/Mime extension. Even people who should know better (HR, finance, etc).
I continually have to tell people that email is like a postcard sent through postal service. Anyone who has access to it can read it. “Would you feel comfortable sending a postcard with your credit card information plainly written on it?”
RootWyrm 🇺🇦
Als Antwort auf FurryBeta • • •@FurryBeta oh, that's nothing. I have yelled repeatedly because email CAN be secure. We fucking have TLS1.3 transport. We've had good local filtering mechanisms since the 1990's.
And guess what? The big three are the biggest fucking impediment by refusing to enforce TLS, intentionally sabotaging known secure methods, and continually misleading users and customers.
Soatok Dreamseeker
Als Antwort auf RootWyrm 🇺🇦 • • •@rootwyrm @FurryBeta TLS 1.3 gives transport-layer encryption.
The fact that TLS isn't already universally a thing for email is annoying.
But the thing we're talking about (and why PGP keeps coming up) is folks want their emails confidential from their provider.
And, sorry, that's just not doable. Experts routinely reply to PGP-encrypted emails with plaintext, often quote-replying the email that was encrypted.
VVelox
Als Antwort auf Soatok Dreamseeker • • •@Soatok Dreamseeker My favorite failure mode for this...
While most clients will store the sent email encrypted, but most clients will get the encrypted email, decrypt it, and then store it back to IMAP decrypted.