14 ms·

Gpg.fail

450 points by todsacerdoti 10mo ago

GaryBluto 10mo ago
> brb, were on it!!!!
rurban 10mo ago
Zero-days from the CCC talk https://fahrplan.events.ccc.de/congress/2025/fahrplan/event/to-sign-or-not-to-sign-practical-vulnerabilities-i https://fahrplan.events.ccc.de/congress/2025/fahrplan/event/... But trust in Werner Koch is gone. Wontfix??
- corndoge 10mo ago
  I am curious what you mean by "trust in Werner Koch is gone". Can you elaborate?
  - karambahh 10mo ago
    OP is complaining about GPG team rejecting issues with "wontfix" statuses.
    - rawmaterial 10mo ago
      'Team' is Werner.
- cpach 10mo ago
  To be frank, at this point, GPG has been a lost cause for basically decades. People who are serious about security use newer, better tools that replace GPG. But keep in mind, there’s no “one ring to rule them all”.
  - perching_aix 10mo ago
    What are those better tools? I've been broadly looking into this space, but never ventured too deep.
    - singpolyma3 10mo ago
      Sequoia for example has been doing a great job and implements the latest version of the standard which brings a lot of cryptography up to date
      - perching_aix 10mo ago
        I'm yet to finish watching the talk, but it starts with them confirming the demo fraudulent .iso with sequoia also (they call it out by name), so this really makes me think. :)
        tptacek 10mo ago
        Sequioa hasn't fixed the attack from the beginning of the talk, the one where they convert between cleartext and full signature formats and inject unsigned bytes into the output because of the confusion.
      - akerl_ 10mo ago
        The latest version of a bad standard is still bad. This page is a pretty direct indicator that GPG's foundation is fundamentally broken: you're not going to get to a good outcome trying to renovate the 2nd story.
        singpolyma3 10mo ago
        That's just not true. Nothing in this page is a problem with the standard and everything in this page is the outdated parts of the old standard.
        akerl_ 10mo ago
        So then why do a bunch of these affect Sequoia as well?
    - arccy 10mo ago
      ssh or minisign for signing age for file encryption
  - ghickPit 10mo ago
    > To be frank, at this point, GPG has been a lost cause for basically decades. Why do high-profile projects, such as Linux and QEMU, still use GPG for signing pull requests / tags? https://docs.kernel.org/process/maintainer-pgp-guide.html https://docs.kernel.org/process/maintainer-pgp-guide.html https://www.qemu.org/docs/master/devel/submitting-a-pull-request.html https://www.qemu.org/docs/master/devel/submitting-a-pull-req... Why does Fedora / RPM still rely on GPG keys for verifying packages? This is a staggering ecosystem failure. If GPG has been a known-lost cause for decades, then why haven't alternatives ^W replacements been produced for decades?
    - deleted 10mo ago
      [deleted]
    - talideon 10mo ago
      Let's not conflate GPG and PGP-in-general. RPM doesn't use GPG, it uses Sequoia PGP. GPG is what GP is referring to as a lost cause. Now, it can be debated whether PGP-in-general is a lost cause too, but that's not what GP is claiming.
      - ghickPit 10mo ago
        > it can be debated whether PGP-in-general is a lost cause too, but that's not what GP is claiming It is though what both the fine article, and tptacek in these comments, are claiming!
        Avamander 10mo ago
        They are also correct, but that's indeed not what the person you replied to said. > then why haven't alternatives ^W replacements been produced for decades? Actually we do have alternatives for it. For example Git supports S/MIME and could absolutely be used to sign commits and tags. Even just using self-signed certificates wouldn't be far off from what PGP offers. However if people used their digital IDs like many countries offer, mission-critical code could have signatures with verifiable strong identities. Though there are other approaches as well, both for signing and for encrypting. It's more that people haven't really considered migrating.
WesolyKubeczek 10mo ago
gpg.fail fail: "brb, we're on it!"
deleted 10mo ago
[deleted]
_haxx0rz 10mo ago
hug of death?
- deleted 10mo ago
  [deleted]
- rurban 10mo ago
  Nope. Not yet enabled. It was submitted to HN right after the talk where they promised to make it public "really soon" after the talk. We all saw the talk live or on the stream
smallerize 10mo ago
Seems to be down? Here's a thread with a summary of exploits presented in the talk: https://bsky.app/profile/filippo.abyssdomain.expert/post/3maya7cnoxj2l https://bsky.app/profile/filippo.abyssdomain.expert/post/3ma...
- orblivion 10mo ago
  Maybe the site is overloaded. But as for the "brb, were on it!!!!" - this page had the live stream of the talk when it was happening. Hopefully they'll replace it with the recording when media.ccc.de posts it, which should be within a couple hours.
  - karambahh 10mo ago
    Also expect contents referred in the slides (every "chapter" of the presentation referred to a url such as https://gpg.fail/clearsig https://gpg.fail/clearsig or https://gpg.fail/minisig https://gpg.fail/minisig and so on)
  - kleiba 10mo ago
    > this page had the live stream of the talk when it was happening As they said, they were on it...
    - selfbottle 10mo ago
      it's online now
    - orblivion 10mo ago
      Took me a second but I got your joke
elric 10mo ago
This is depressing. From what I can piece together while the site is down, it seems like they've uncovered 14 exploitable vulnerabilities in GnuPG, of which most remain unpatched. Some of those are apparently met by refusal to patch by the maintainer. Maybe there are good reasons for this refusal, maybe someone else can chime in on that? Is this another case of XKCD-2347? Or is there something else going on? Pretty much every Linux distro depends on PGP being pretty secure. Surely IBM & co have a couple of spare developers or spare cash to contribute?
- collinfunk 10mo ago
  Haven't read it since it is down, but based on other comments, it seems to be an issue with cleartext signatures. I haven't seen those outside of old mailing list archives. Everyone uses detached signatures nowadays, e.g. PGP/MIME for emails.
  - bytehamster 10mo ago
    If I understood their first demo correctly, they verified a fedora iso with a detached signature. The booted iso then printed "hello 39c3". https://streaming.media.ccc.de/39c3/relive/1854 https://streaming.media.ccc.de/39c3/relive/1854
    - unscaled 10mo ago
      It was a cleartext signature, not a detached signature. Edit: even better. It was both. There is a signature type confusion attack going on here. I still didn't watch the entire thing, but it seems that unlike gpg, they do have to specify --cleartext explicitly for Sequoia, so there is no confusion going on that case.
- akerl_ 10mo ago
  > Surely IBM & co have a couple of spare developers or spare cash to contribute? A major part of the problem is that GPG’s issues aren’t cash or developer time. It’s fundamentally a bad design for cryptographic usage. It’s so busy trying to be a generic Swiss Army knife for every possible user or use case that it’s basically made of developer and user footguns. The way you secure this is by moving to alternative, purpose-built tools. Signal/WhatsApp for messaging, age for file encryption, minisign for signatures, etc.
singpolyma3 10mo ago
AFAICT this is GnuPG specific and not OpenPGP related? Since GnuPG has pulled out of standards compliance anyway there are many better options. Sequoia chameleon even has drop in tooling for most workflows.
- rurban 10mo ago
  They presented critical parser flaws in all major PGP implementations, not just GNU PGP, also sequoia, minisign and age. But gpg made the worst impression to us. wontfix
  - akerl_ 10mo ago
    Since when are age or minisign PGP implementations?
    - some_furry 10mo ago
      The talk title includes "& Friends", for what it's worth.
    - pornel 10mo ago
      They're not, but the flaws they found are independent of PGP. Mainly invalid handling of strings in C and allowing untrusted ANSI codes in terminal output.
  - pornel 10mo ago
    Sequoia is mentioned in only one vulnerability for supporting lines much longer than gpg. gpg silently truncates and discards long base64 lines and sequoia does not. So the vulnerability is in ability to feed more data to sequoia which doesn't have the silent data loss of gpg. In all other cases they only used sequoia as a tool to build data for demonstrating gpg vulnerabilities.
    - tptacek 10mo ago
      The vulnerability that opens the talk, where they walk through verifying a Linux ISO's signature and hash and then boot into a malicious image, impacts both GnuPG and Sequoia.
derleyici 10mo ago
Werner Koch from GnuPG recently (2025-12-26) posted this on their blog: https://www.gnupg.org/blog/20251226-cleartext-signatures.html https://www.gnupg.org/blog/20251226-cleartext-signatures.htm... Archive link: https://web.archive.org/web/20251227174414/https://www.gnupg.org/blog/20251226-cleartext-signatures.html https://web.archive.org/web/20251227174414/https://www.gnupg...
- woodruffw 10mo ago
  This feels pretty unsatisfying: something that’s been “considered harmful” for three decades should be deprecated and then removed in a responsible ecosystem. (PGP/GPG are of course hamstrung by their own decision to be a Swiss Army knife/only loosely coupled to the secure operation itself. So the even more responsible thing to do is to discard them for purposes that they can’t offer security properties for, which is the vast majority of things they get used for.)
  - LtWorf 10mo ago
    Well python discarded signing entirely so that's one way to solve it :)
    - woodruffw 10mo ago
      Both CPython and distributions on PyPI are more effectively signed than they were before. (I think you already know this, but want to relitigate something that’s not meaningfully controversial in Python.)
      - LtWorf 10mo ago
        Being signed by some entity which is not the author is hardly more effective. (I think you already know this as well)
        woodruffw 10mo ago
        It is, in fact, signed by the author. It's just a PKI, so you intermediate trust in the author through an authority. This is exactly analogous to the Web PKI, where you trust CAs to identify individual websites, but the websites themselves control their keypairs. The CA's presence intermediates the trust but does not somehow imply that the CA itself does the signing for TLS traffic.
clacker-o-matic 10mo ago
its back up!
selfbottle 10mo ago
writeups are online :))
somethrowa123 10mo ago
the writeup is now available and the recording lives at https://media.ccc.de/v/39c3-to-sign-or-not-to-sign-practical-vulnerabilities-i https://media.ccc.de/v/39c3-to-sign-or-not-to-sign-practical...
oefrha 10mo ago
Okay, since there’s so much stuff to digest here and apparently there are issues designated as wontfix by GnuPG maintainers, can someone more in the loop tell us whether using gpg signatures on git commits/tags is vulnerable? And is there any better alternative going forward? Like is signing with SSH keys considered more secure now? I certainly want to get rid of gpg from my life if I can, but I also need to make sure commits/tags bearing my name actually come from me.
- larusso 10mo ago
  I did the switch this year after getting yet another personal computer. I have 4 in total (work laptop, personal sofa laptop, Mac Mini, Linux Tower). I used Yubi keys with gpg and resident ssh keys. All is fine but the configuration needed to get it too work on all the machines. I also tend to forget the finer details and have to relearn the skills of fetching the public keys into the keychain etc. I got rid of this all by moving to 1Password ssh agent and git ssh signing. Removes a lot of headaches from my ssh setup. I still have the yubi key(s) though as a 2nd factor for certain web services. And the gpg agent is still running but only as a fallback. I will turn this off next year.
  - hk1337 10mo ago
    > 1Password ssh agent and git ssh signing I’m still working through how to use this but I have it basically setup and it’s great!
  - hirako2000 10mo ago
    How is 1password safer than the local keychain?
    - larusso 10mo ago
      The keys never leave the 1Password store. So you don’t have the keys on the local file system. That and that these keys are shared over the cloud was the seller for me. I guess security wise it’s a bit of a downgrade compared to resident keys. But the agent support agent forwarding etc which wasn’t really working with yubi ssh resident keys. Also worth mentioning that I use 1Password. Bitwarden has a similar feature as far as I know. For the ones who want to self host etc might be the even better solution.
SSLy 10mo ago
https://media.ccc.de/v/39c3-to-sign-or-not-to-sign-practical-vulnerabilities-i#t=1 https://media.ccc.de/v/39c3-to-sign-or-not-to-sign-practical...
tptacek 10mo ago
A thru-line of some of the gnarliest vulnerabilities here is PGP's insane packet system, where a PGP message is a practically arbitrary stream of packets, some control and some data, with totally incoherent cryptographic bindings. It's like something in between XMLDSIG (which pulls cryptographic control data out of random places in XML messages according to attacker-controlled tags) and SSL2 (with no coherent authentication of the complete handshake). The attack on detached signatures (attack #1) happens because GnuPG needs to run a complicated state machine that can put processing into multiple different modes, among them three different styles of message signature. In GPG, that whole state machine apparently collapses down to a binary check of "did we see any data so that we'd need to verify a signature?", and you can selectively flip that predicate back and forth by shoving different packets into message stream, even if you've already sent data that needs to be verified. The malleability bug (attack #4) is particularly slick. Again, it's an incoherent state machine issue. GPG can "fail" to process a packet because it's cryptographically invalid. But it can also fail because the message framing itself is corrupted. Those latter non-cryptographic failures are handled by aborting the processing of the message, putting GPG into an unexpected state where it's handling an error and "forgetting" to check the message authenticator. You can CBC-bitflip known headers to force GPG into processing DEFLATE compression, and mangle the message such that handling the message prints the plaintext in its output. The formfeed bug (#3) is downright weird. GnuPG has special handling for `\f`; if it occurs at the end of a line, you can inject arbitrary unsigned data, because of GnuPG's handling of line truncation. Why is this even a feature? Some of these attacks look situational, but that's deceptive, because PGP is (especially in older jankier systems) used as an encryption backend for applications --- Mallory getting Alice to sign or encrypt something on her behalf is an extremely realistic threat model (it's the same threat model as most cryptographic attacks on secure cookies: the app automatically signs stuff for users). There is no reason for a message encryption system to have this kind of complexity. It's a deep architectural flaw in PGP. You want extremely simple, orthogonal features in the format, ideally treating everything as clearly length-delimited opaque binary blobs. Instead you get a Weird Machine, and talks like this one. Amazing work.
- oskarw85 10mo ago
  Thank you for this excellent explanation!
ekjhgkejhgk 10mo ago
[flagged]
cindyllm 10mo ago
[dead]
IAmLiterallyAB 10mo ago
Another related writeup https://www.latacora.com/blog/2019/07/16/the-pgp-problem/ https://www.latacora.com/blog/2019/07/16/the-pgp-problem/
- upofadown 10mo ago
  There is some misleading stuff in that article. To save time I made an article to provide my commentary: * https://articles.59.ca/doku.php?id=pgpfan:tpp https://articles.59.ca/doku.php?id=pgpfan:tpp
  - jcranmer 10mo ago
    Don't you think it's time to update it, given you start by saying that "If someone, while trying to sell you some high security mechanical system, told you that the system had remained unbreached for the last 20 years you would take that as a compelling argument"? Because you're clearly presenting it as a defense of PGP on a thread from a presentation clearly delineating breaks in it using exactly the kind of complexity that the article you're responding to predicts would cause it to break.
    - upofadown 10mo ago
      The mechanical analogy is particularly interesting here because at least one of the claimed vulnerabilities involves tricking the victim into decrypting an encrypted message for the attacker and then sending it to them. If someone can be tricked into opening a safe to let the burgler rummage around inside then few would consider that a failure of the safe technology. I mean there is still a problem there but it is a different one. I think this supports my contention that we spend much too much time quibbling about cryptographic trivialities when it comes to end to end encrypted messaging. We should spend more time on the usability of such systems.
      - tptacek 10mo ago
        The constraint that you have implicitly applied to cryptosystems forecloses on using GPG as a base layer in other computing systems; in your view, GPG is a "safe", which can only be opened by the owner of the contents to retrieve and remove those contents.
1317 10mo ago
[video]
wkat4242 10mo ago
I don't mind gpg. I still use it a lot especially with the private keys on openpgp smartcards or yubikeys. It's a pretty great ecosystem, most hardware smartcards are surrounded by a lot of black magic and secret handshakes and stuff like pkcs#11 and opensc/openct are much much harder to configure. I use it for many things but not for email. Encrypted backups, password manager, ssh keys. For some there are other hardware options like fido2 but not for all usecases and not the same one for each usecase. So I expect to be using gpg for a long time to come.
acoustics 10mo ago
I don't understand the disappointment expressed here in the maintainers deciding to WONTFIX these security bugs. Isn't this what ffmpeg did recently? They seemed to get a ton of community support in their decision not to fix a vulnerability
- some_furry 10mo ago
  ffmpeg doesn't have a cargo-cult of self-proclaimed "privacy experts" that tell activists and whistleblowers to use their thing instead of other tools cryptographers actually recommend.
  - landr0id 10mo ago
    Yeah, instead they have a cargo-cult of self-proclaimed OSS contribution experts who harass anyone that critiques or challenges ffmpeg's twitter account.
ekjhgkejhgk 10mo ago
Is anyone else worried that a lot of people coming from the Rust world contribute to free software and mindlessly slap on it MIT license because it's "the default license"? (Yes, I've had someone say this to me, no joke) GnuPG for all its flaws has a copyleft license (GPL3) making it difficult to "embrace extend extinguish". If you replace it with a project that becomes more successful but has a less protective (for users) license, "we the people" might lose control of it. Not everything in software is about features.
- loop22 10mo ago
  I think that's a feature not a bug for upstream projects encouraging these rewrites.
  - ekjhgkejhgk 10mo ago
    It's harmful if the license of the rewrites if less protective of users, and then the rewrite ends up being very popular.
    - MobiusHorizons 10mo ago
      Seems like the users are voting with their feet, right? Maybe respect the users wishes and stop preaching what users should be wanting?
      - bfkwlfkjf 10mo ago
        [flagged]
        MobiusHorizons 10mo ago
        Obviously I am aware that not all user actions represent choices, but the hypothetical being proposed was specifically in the context of good established free software alternatives existing. In that context users switching to software with more permissive licenses would imply a choice on the users part. It is reasonable to assume this choice implies the users value something about the other software more than they value what the GPL incumbent has to offer. Of course such a choice could be motivated by many things like newer features, slick website, the author’s marketing, but whatever the case if the license was not sufficient enticement to stay, this feels significant.
sorz 10mo ago
Lots of issues follow the pattern "ANSI escape code inside untrusted text". It feels like XSS but for terminal.
Valodim 10mo ago
For anyone relatedly wondering about the "schism", i.e. GnuPG abandoning the OpenPGP standard and doing their own self-governed thing, I found this email particularly insightful on the matter: https://lists.gnupg.org/pipermail/gnupg-devel/2025-September/036064.html https://lists.gnupg.org/pipermail/gnupg-devel/2025-September... > As others have pointed out, GnuPG is a C codebase with a long history (going on 28 years). On top of that, it's a codebase that is mostly uncovered by tests, and has no automated CI. If GnuPG were my project, I would also be anxious about each change I make. I believe that because of this the LibrePGP draft errs on the side of making minimal changes, with the unspoken goal of limiting risks of breakage in a brittle codebase with practically no tests. (Maybe the new formats in RFC 9580 are indeed "too radical" of an evolutionary step to safely implement in GnuPG. But that's surely not a failing of RFC 9580.)
- upofadown 10mo ago
  Here is my take on the OpenPGP standards schism: * https://articles.59.ca/doku.php?id=pgpfan:schism https://articles.59.ca/doku.php?id=pgpfan:schism Nothing has improved and everything has gotten worse since I wrote that. Both factions are sleepwalking into an interoperability disaster. Supporting one faction or the other just means you are part of the problem. The users have to resist being made pawns in this pointless war. >Maybe the new formats in RFC 9580 are indeed "too radical" of an evolutionary step to safely implement in GnuPG. Traditionally the OpenPGP process has been based on minimalism and rejected everything without a strong justification. RFC-9580 is basically everything that was rejected by the LibrePGP faction (GnuPG) in the last attempt to come up with a new standard. It contains a lot of poorly justified stuff and some straight up pointless stuff. So just supporting RFC-9580 is not the answer here. It would require significant cleaning up. But again, just supporting LibrePGP is not the answer either. The process has failed yet again and we need to recognize that.
  - Valodim 10mo ago
    Here is the short version from someone who took part in this process: while serving as the editor of the draft, Werner did not let anything into the draft that wasn't his own idea. But for his own ideas, there were cases where a new feature was committed to spec master and released in gnupg within the week. He was impossible to work with over many years, to the point that everyone agreed that the only way forward was to leave gnupg behind. This is a bonkers decision for OpenPGP as an ecosystem, but it was not made in ignorance of the consequences. And as far as I'm aware, even with today's hindsight, noone involved in the process regrets making the decision.
raphinou 10mo ago
I'm working on a multi sig file authentication solution based on minisign. Anyone knows the response of the dev regarding minisign's listed vulnerability? If I'm not mistaken, the response of the authors are not included in the vulnerabilities' descriptions.
- jedisct1 10mo ago
  Because the authors found out about it by chance on Hacker News. That said, these issues are not a big deal. The first one concerns someone manually reading a signature with cat (which is completely untrusted at that stage, since nothing has been verified), then using the actual tool meant to parse it, and ignoring that tool’s output. cat is a different tool from minisign. If you manually cat a file, it can contain arbitrary characters, not just in the specific location this report focuses on, but anywhere in the file. The second issue is about trusting an untrusted signer who could include control characters in a comment. In that case, a malicious signer could just make the signed file itself malicious as well, so you shouldn’t trust them in the first place. Still, it’s worth fixing. In the Zig implementation of minisign, these characters are escaped when printed. In the C implementation, invalid strings are now rejected at load time.
user3939382 10mo ago
If mass use of GPG benefited Microsoft, Amazon, Google and all the other assholes it would be polished, slick, and part of 9th grade curriculum. They call it “Face ID” that’s the Orwellian shit that makes money so that’s what we get instead. These things take resources, don’t blame the projects.
manuchojose76 10mo ago
[dead]
jwr 10mo ago
It has become fashionable to s*t on GnuPG. I just wish all the crypto experts doing that would point me to an alternative that is functionally equivalent. Something that will encrypt using AES-256 with a passphrase, but also using asymmetric crypto. Oh, and I want my secret keys printable if needed. And I want to store them securely on YubiKeys once generated (https://github.com/drduh/YubiKey-Guide https://github.com/drduh/YubiKey-Guide). I want to be able to encrypt my backups to multiple recipients. And I want the same keys (stored on Yubikeys, remember?) to be usable for SSH authentication, too. And by the way, if your fancy tool is written using the latest language du jour with a runtime that changes every couple of years or so, or requires huge piles of dependencies that break if you even as much as sneeze (python, anyone?), it won't do. BTW, in case someone says "age", I actually followed that advice and set it up just to be there on my systems (managed by ansible). Apart from the fact that it really slowed down my deployments, the thing broke within a year. And I didn't even use it. I just wanted to see how reliable it will be in the most minimal of ways: by having it auto-installed on my systems. If your fancy tool has less than 5 years of proven maintenance record, it won't do. Encryption is for the long term. I want to be able to read my stuff in 15-30 years. So before you go all criticizing GnuPG, please understand that there are reasons why people still use it, and are actually OK with the flaws described.
- tptacek 10mo ago
  There isn't an alternative that is functionally equivalent because what PGP does is dumb. It's a Swiss Army Knife. Nobody who wants to design an excellent saw sets out to design the Swiss Army Knife saw[†]. Nobody who needs shears professionally buys a Swiss Army Knife for the scissors. The cryptographic requirements of different problems --- backup, package signing, god-help-us secure messaging --- are in tension with each other. No one design adequately covers all the use cases. Trying to cram them all into one tool is a sign that something other than security is the goal. If that's the case, you're live action roleplaying, not protecting people. I'd be interested in whether you could find a cryptographer who disagrees with that. I've asked around! [†] I am aware that SAK nerds love the saw.
  - picture 10mo ago
SEJeff 10mo ago
One of my coworkers, Liam, gave this talk. If you like this and want to work with like minded individuals, apply to some of our seceng roles: https://www.asymmetric.re/careers https://www.asymmetric.re/careers
theshrike79 10mo ago
Could someone rewrite GPG in Rust please?
KooBaa 10mo ago
The 12 vulnerabilities mentioned in “gpg fail” are somewhat exaggerated. Here you can find a reply from GnuPG: https://www.openwall.com/lists/oss-security/2025/12/29/9 https://www.openwall.com/lists/oss-security/2025/12/29/9 And btw, it was mentioned in the talk that GnuPG does not sign commits. That’s just wrong. Everything, including the release tarballs, is signed.
annalexandra 10mo ago
[dead]

450 points by todsacerdoti 10mo ago

> brb, were on it!!!!

rurban 10mo ago

Zero-days from the CCC talk https://fahrplan.events.ccc.de/congress/2025/fahrplan/event/to-sign-or-not-to-sign-practical-vulnerabilities-i https://fahrplan.events.ccc.de/congress/2025/fahrplan/event/... But trust in Werner Koch is gone. Wontfix??

corndoge 10mo ago
I am curious what you mean by "trust in Werner Koch is gone". Can you elaborate?
- karambahh 10mo ago
  OP is complaining about GPG team rejecting issues with "wontfix" statuses.
  - rawmaterial 10mo ago
    'Team' is Werner.
cpach 10mo ago
To be frank, at this point, GPG has been a lost cause for basically decades. People who are serious about security use newer, better tools that replace GPG. But keep in mind, there’s no “one ring to rule them all”.
- perching_aix 10mo ago
  What are those better tools? I've been broadly looking into this space, but never ventured too deep.
  - singpolyma3 10mo ago
    Sequoia for example has been doing a great job and implements the latest version of the standard which brings a lot of cryptography up to date
    - perching_aix 10mo ago
      I'm yet to finish watching the talk, but it starts with them confirming the demo fraudulent .iso with sequoia also (they call it out by name), so this really makes me think. :)
      - tptacek 10mo ago
        Sequioa hasn't fixed the attack from the beginning of the talk, the one where they convert between cleartext and full signature formats and inject unsigned bytes into the output because of the confusion.
    - akerl_ 10mo ago
      The latest version of a bad standard is still bad. This page is a pretty direct indicator that GPG's foundation is fundamentally broken: you're not going to get to a good outcome trying to renovate the 2nd story.
      - singpolyma3 10mo ago
        That's just not true. Nothing in this page is a problem with the standard and everything in this page is the outdated parts of the old standard.
        akerl_ 10mo ago
        So then why do a bunch of these affect Sequoia as well?
  - arccy 10mo ago
    ssh or minisign for signing age for file encryption
- ghickPit 10mo ago
  > To be frank, at this point, GPG has been a lost cause for basically decades. Why do high-profile projects, such as Linux and QEMU, still use GPG for signing pull requests / tags? https://docs.kernel.org/process/maintainer-pgp-guide.html https://docs.kernel.org/process/maintainer-pgp-guide.html https://www.qemu.org/docs/master/devel/submitting-a-pull-request.html https://www.qemu.org/docs/master/devel/submitting-a-pull-req... Why does Fedora / RPM still rely on GPG keys for verifying packages? This is a staggering ecosystem failure. If GPG has been a known-lost cause for decades, then why haven't alternatives ^W replacements been produced for decades?
  - deleted 10mo ago
    [deleted]
  - talideon 10mo ago
    Let's not conflate GPG and PGP-in-general. RPM doesn't use GPG, it uses Sequoia PGP. GPG is what GP is referring to as a lost cause. Now, it can be debated whether PGP-in-general is a lost cause too, but that's not what GP is claiming.
    - ghickPit 10mo ago
      > it can be debated whether PGP-in-general is a lost cause too, but that's not what GP is claiming It is though what both the fine article, and tptacek in these comments, are claiming!
      - Avamander 10mo ago
        They are also correct, but that's indeed not what the person you replied to said. > then why haven't alternatives ^W replacements been produced for decades? Actually we do have alternatives for it. For example Git supports S/MIME and could absolutely be used to sign commits and tags. Even just using self-signed certificates wouldn't be far off from what PGP offers. However if people used their digital IDs like many countries offer, mission-critical code could have signatures with verifiable strong identities. Though there are other approaches as well, both for signing and for encrypting. It's more that people haven't really considered migrating.

WesolyKubeczek 10mo ago

gpg.fail fail: "brb, we're on it!"

deleted 10mo ago

[deleted]

_haxx0rz 10mo ago

hug of death?

deleted 10mo ago
[deleted]
rurban 10mo ago
Nope. Not yet enabled. It was submitted to HN right after the talk where they promised to make it public "really soon" after the talk. We all saw the talk live or on the stream

smallerize 10mo ago

Seems to be down? Here's a thread with a summary of exploits presented in the talk: https://bsky.app/profile/filippo.abyssdomain.expert/post/3maya7cnoxj2l https://bsky.app/profile/filippo.abyssdomain.expert/post/3ma...

orblivion 10mo ago
Maybe the site is overloaded. But as for the "brb, were on it!!!!" - this page had the live stream of the talk when it was happening. Hopefully they'll replace it with the recording when media.ccc.de posts it, which should be within a couple hours.
- karambahh 10mo ago
  Also expect contents referred in the slides (every "chapter" of the presentation referred to a url such as https://gpg.fail/clearsig https://gpg.fail/clearsig or https://gpg.fail/minisig https://gpg.fail/minisig and so on)
- kleiba 10mo ago
  > this page had the live stream of the talk when it was happening As they said, they were on it...
  - selfbottle 10mo ago
    it's online now
  - orblivion 10mo ago
    Took me a second but I got your joke

elric 10mo ago

This is depressing. From what I can piece together while the site is down, it seems like they've uncovered 14 exploitable vulnerabilities in GnuPG, of which most remain unpatched. Some of those are apparently met by refusal to patch by the maintainer. Maybe there are good reasons for this refusal, maybe someone else can chime in on that? Is this another case of XKCD-2347? Or is there something else going on? Pretty much every Linux distro depends on PGP being pretty secure. Surely IBM & co have a couple of spare developers or spare cash to contribute?

collinfunk 10mo ago
Haven't read it since it is down, but based on other comments, it seems to be an issue with cleartext signatures. I haven't seen those outside of old mailing list archives. Everyone uses detached signatures nowadays, e.g. PGP/MIME for emails.
- bytehamster 10mo ago
  If I understood their first demo correctly, they verified a fedora iso with a detached signature. The booted iso then printed "hello 39c3". https://streaming.media.ccc.de/39c3/relive/1854 https://streaming.media.ccc.de/39c3/relive/1854
  - unscaled 10mo ago
    It was a cleartext signature, not a detached signature. Edit: even better. It was both. There is a signature type confusion attack going on here. I still didn't watch the entire thing, but it seems that unlike gpg, they do have to specify --cleartext explicitly for Sequoia, so there is no confusion going on that case.
akerl_ 10mo ago
> Surely IBM & co have a couple of spare developers or spare cash to contribute? A major part of the problem is that GPG’s issues aren’t cash or developer time. It’s fundamentally a bad design for cryptographic usage. It’s so busy trying to be a generic Swiss Army knife for every possible user or use case that it’s basically made of developer and user footguns. The way you secure this is by moving to alternative, purpose-built tools. Signal/WhatsApp for messaging, age for file encryption, minisign for signatures, etc.

singpolyma3 10mo ago

AFAICT this is GnuPG specific and not OpenPGP related? Since GnuPG has pulled out of standards compliance anyway there are many better options. Sequoia chameleon even has drop in tooling for most workflows.

rurban 10mo ago
They presented critical parser flaws in all major PGP implementations, not just GNU PGP, also sequoia, minisign and age. But gpg made the worst impression to us. wontfix
- akerl_ 10mo ago
  Since when are age or minisign PGP implementations?
  - some_furry 10mo ago
    The talk title includes "& Friends", for what it's worth.
  - pornel 10mo ago
    They're not, but the flaws they found are independent of PGP. Mainly invalid handling of strings in C and allowing untrusted ANSI codes in terminal output.
- pornel 10mo ago
  Sequoia is mentioned in only one vulnerability for supporting lines much longer than gpg. gpg silently truncates and discards long base64 lines and sequoia does not. So the vulnerability is in ability to feed more data to sequoia which doesn't have the silent data loss of gpg. In all other cases they only used sequoia as a tool to build data for demonstrating gpg vulnerabilities.
  - tptacek 10mo ago
    The vulnerability that opens the talk, where they walk through verifying a Linux ISO's signature and hash and then boot into a malicious image, impacts both GnuPG and Sequoia.

derleyici 10mo ago

Werner Koch from GnuPG recently (2025-12-26) posted this on their blog: https://www.gnupg.org/blog/20251226-cleartext-signatures.html https://www.gnupg.org/blog/20251226-cleartext-signatures.htm... Archive link: https://web.archive.org/web/20251227174414/https://www.gnupg.org/blog/20251226-cleartext-signatures.html https://web.archive.org/web/20251227174414/https://www.gnupg...

woodruffw 10mo ago
This feels pretty unsatisfying: something that’s been “considered harmful” for three decades should be deprecated and then removed in a responsible ecosystem. (PGP/GPG are of course hamstrung by their own decision to be a Swiss Army knife/only loosely coupled to the secure operation itself. So the even more responsible thing to do is to discard them for purposes that they can’t offer security properties for, which is the vast majority of things they get used for.)
- LtWorf 10mo ago
  Well python discarded signing entirely so that's one way to solve it :)
  - woodruffw 10mo ago
    Both CPython and distributions on PyPI are more effectively signed than they were before. (I think you already know this, but want to relitigate something that’s not meaningfully controversial in Python.)
    - LtWorf 10mo ago
      Being signed by some entity which is not the author is hardly more effective. (I think you already know this as well)
      - woodruffw 10mo ago
        It is, in fact, signed by the author. It's just a PKI, so you intermediate trust in the author through an authority. This is exactly analogous to the Web PKI, where you trust CAs to identify individual websites, but the websites themselves control their keypairs. The CA's presence intermediates the trust but does not somehow imply that the CA itself does the signing for TLS traffic.

clacker-o-matic 10mo ago

its back up!

selfbottle 10mo ago

writeups are online :))

somethrowa123 10mo ago

the writeup is now available and the recording lives at https://media.ccc.de/v/39c3-to-sign-or-not-to-sign-practical-vulnerabilities-i https://media.ccc.de/v/39c3-to-sign-or-not-to-sign-practical...

oefrha 10mo ago

Okay, since there’s so much stuff to digest here and apparently there are issues designated as wontfix by GnuPG maintainers, can someone more in the loop tell us whether using gpg signatures on git commits/tags is vulnerable? And is there any better alternative going forward? Like is signing with SSH keys considered more secure now? I certainly want to get rid of gpg from my life if I can, but I also need to make sure commits/tags bearing my name actually come from me.

larusso 10mo ago
I did the switch this year after getting yet another personal computer. I have 4 in total (work laptop, personal sofa laptop, Mac Mini, Linux Tower). I used Yubi keys with gpg and resident ssh keys. All is fine but the configuration needed to get it too work on all the machines. I also tend to forget the finer details and have to relearn the skills of fetching the public keys into the keychain etc. I got rid of this all by moving to 1Password ssh agent and git ssh signing. Removes a lot of headaches from my ssh setup. I still have the yubi key(s) though as a 2nd factor for certain web services. And the gpg agent is still running but only as a fallback. I will turn this off next year.
- hk1337 10mo ago
  > 1Password ssh agent and git ssh signing I’m still working through how to use this but I have it basically setup and it’s great!
- hirako2000 10mo ago
  How is 1password safer than the local keychain?
  - larusso 10mo ago
    The keys never leave the 1Password store. So you don’t have the keys on the local file system. That and that these keys are shared over the cloud was the seller for me. I guess security wise it’s a bit of a downgrade compared to resident keys. But the agent support agent forwarding etc which wasn’t really working with yubi ssh resident keys. Also worth mentioning that I use 1Password. Bitwarden has a similar feature as far as I know. For the ones who want to self host etc might be the even better solution.

SSLy 10mo ago

https://media.ccc.de/v/39c3-to-sign-or-not-to-sign-practical-vulnerabilities-i#t=1 https://media.ccc.de/v/39c3-to-sign-or-not-to-sign-practical...

tptacek 10mo ago

A thru-line of some of the gnarliest vulnerabilities here is PGP's insane packet system, where a PGP message is a practically arbitrary stream of packets, some control and some data, with totally incoherent cryptographic bindings. It's like something in between XMLDSIG (which pulls cryptographic control data out of random places in XML messages according to attacker-controlled tags) and SSL2 (with no coherent authentication of the complete handshake). The attack on detached signatures (attack #1) happens because GnuPG needs to run a complicated state machine that can put processing into multiple different modes, among them three different styles of message signature. In GPG, that whole state machine apparently collapses down to a binary check of "did we see any data so that we'd need to verify a signature?", and you can selectively flip that predicate back and forth by shoving different packets into message stream, even if you've already sent data that needs to be verified. The malleability bug (attack #4) is particularly slick. Again, it's an incoherent state machine issue. GPG can "fail" to process a packet because it's cryptographically invalid. But it can also fail because the message framing itself is corrupted. Those latter non-cryptographic failures are handled by aborting the processing of the message, putting GPG into an unexpected state where it's handling an error and "forgetting" to check the message authenticator. You can CBC-bitflip known headers to force GPG into processing DEFLATE compression, and mangle the message such that handling the message prints the plaintext in its output. The formfeed bug (#3) is downright weird. GnuPG has special handling for `\f`; if it occurs at the end of a line, you can inject arbitrary unsigned data, because of GnuPG's handling of line truncation. Why is this even a feature? Some of these attacks look situational, but that's deceptive, because PGP is (especially in older jankier systems) used as an encryption backend for applications --- Mallory getting Alice to sign or encrypt something on her behalf is an extremely realistic threat model (it's the same threat model as most cryptographic attacks on secure cookies: the app automatically signs stuff for users). There is no reason for a message encryption system to have this kind of complexity. It's a deep architectural flaw in PGP. You want extremely simple, orthogonal features in the format, ideally treating everything as clearly length-delimited opaque binary blobs. Instead you get a Weird Machine, and talks like this one. Amazing work.

oskarw85 10mo ago
Thank you for this excellent explanation!

ekjhgkejhgk 10mo ago

[flagged]

cindyllm 10mo ago

[dead]

IAmLiterallyAB 10mo ago

Another related writeup https://www.latacora.com/blog/2019/07/16/the-pgp-problem/ https://www.latacora.com/blog/2019/07/16/the-pgp-problem/

upofadown 10mo ago
There is some misleading stuff in that article. To save time I made an article to provide my commentary: * https://articles.59.ca/doku.php?id=pgpfan:tpp https://articles.59.ca/doku.php?id=pgpfan:tpp
- jcranmer 10mo ago
  Don't you think it's time to update it, given you start by saying that "If someone, while trying to sell you some high security mechanical system, told you that the system had remained unbreached for the last 20 years you would take that as a compelling argument"? Because you're clearly presenting it as a defense of PGP on a thread from a presentation clearly delineating breaks in it using exactly the kind of complexity that the article you're responding to predicts would cause it to break.
  - upofadown 10mo ago
    The mechanical analogy is particularly interesting here because at least one of the claimed vulnerabilities involves tricking the victim into decrypting an encrypted message for the attacker and then sending it to them. If someone can be tricked into opening a safe to let the burgler rummage around inside then few would consider that a failure of the safe technology. I mean there is still a problem there but it is a different one. I think this supports my contention that we spend much too much time quibbling about cryptographic trivialities when it comes to end to end encrypted messaging. We should spend more time on the usability of such systems.
    - tptacek 10mo ago
      The constraint that you have implicitly applied to cryptosystems forecloses on using GPG as a base layer in other computing systems; in your view, GPG is a "safe", which can only be opened by the owner of the contents to retrieve and remove those contents.

1317 10mo ago

[video]

wkat4242 10mo ago

I don't mind gpg. I still use it a lot especially with the private keys on openpgp smartcards or yubikeys. It's a pretty great ecosystem, most hardware smartcards are surrounded by a lot of black magic and secret handshakes and stuff like pkcs#11 and opensc/openct are much much harder to configure. I use it for many things but not for email. Encrypted backups, password manager, ssh keys. For some there are other hardware options like fido2 but not for all usecases and not the same one for each usecase. So I expect to be using gpg for a long time to come.

acoustics 10mo ago

I don't understand the disappointment expressed here in the maintainers deciding to WONTFIX these security bugs. Isn't this what ffmpeg did recently? They seemed to get a ton of community support in their decision not to fix a vulnerability

some_furry 10mo ago
ffmpeg doesn't have a cargo-cult of self-proclaimed "privacy experts" that tell activists and whistleblowers to use their thing instead of other tools cryptographers actually recommend.
- landr0id 10mo ago
  Yeah, instead they have a cargo-cult of self-proclaimed OSS contribution experts who harass anyone that critiques or challenges ffmpeg's twitter account.

ekjhgkejhgk 10mo ago

Is anyone else worried that a lot of people coming from the Rust world contribute to free software and mindlessly slap on it MIT license because it's "the default license"? (Yes, I've had someone say this to me, no joke) GnuPG for all its flaws has a copyleft license (GPL3) making it difficult to "embrace extend extinguish". If you replace it with a project that becomes more successful but has a less protective (for users) license, "we the people" might lose control of it. Not everything in software is about features.

loop22 10mo ago
I think that's a feature not a bug for upstream projects encouraging these rewrites.
- ekjhgkejhgk 10mo ago
  It's harmful if the license of the rewrites if less protective of users, and then the rewrite ends up being very popular.
  - MobiusHorizons 10mo ago
    Seems like the users are voting with their feet, right? Maybe respect the users wishes and stop preaching what users should be wanting?
    - bfkwlfkjf 10mo ago
      [flagged]
      - MobiusHorizons 10mo ago
        Obviously I am aware that not all user actions represent choices, but the hypothetical being proposed was specifically in the context of good established free software alternatives existing. In that context users switching to software with more permissive licenses would imply a choice on the users part. It is reasonable to assume this choice implies the users value something about the other software more than they value what the GPL incumbent has to offer. Of course such a choice could be motivated by many things like newer features, slick website, the author’s marketing, but whatever the case if the license was not sufficient enticement to stay, this feels significant.

sorz 10mo ago

Lots of issues follow the pattern "ANSI escape code inside untrusted text". It feels like XSS but for terminal.

Valodim 10mo ago

For anyone relatedly wondering about the "schism", i.e. GnuPG abandoning the OpenPGP standard and doing their own self-governed thing, I found this email particularly insightful on the matter: https://lists.gnupg.org/pipermail/gnupg-devel/2025-September/036064.html https://lists.gnupg.org/pipermail/gnupg-devel/2025-September... > As others have pointed out, GnuPG is a C codebase with a long history (going on 28 years). On top of that, it's a codebase that is mostly uncovered by tests, and has no automated CI. If GnuPG were my project, I would also be anxious about each change I make. I believe that because of this the LibrePGP draft errs on the side of making minimal changes, with the unspoken goal of limiting risks of breakage in a brittle codebase with practically no tests. (Maybe the new formats in RFC 9580 are indeed "too radical" of an evolutionary step to safely implement in GnuPG. But that's surely not a failing of RFC 9580.)

upofadown 10mo ago
Here is my take on the OpenPGP standards schism: * https://articles.59.ca/doku.php?id=pgpfan:schism https://articles.59.ca/doku.php?id=pgpfan:schism Nothing has improved and everything has gotten worse since I wrote that. Both factions are sleepwalking into an interoperability disaster. Supporting one faction or the other just means you are part of the problem. The users have to resist being made pawns in this pointless war. >Maybe the new formats in RFC 9580 are indeed "too radical" of an evolutionary step to safely implement in GnuPG. Traditionally the OpenPGP process has been based on minimalism and rejected everything without a strong justification. RFC-9580 is basically everything that was rejected by the LibrePGP faction (GnuPG) in the last attempt to come up with a new standard. It contains a lot of poorly justified stuff and some straight up pointless stuff. So just supporting RFC-9580 is not the answer here. It would require significant cleaning up. But again, just supporting LibrePGP is not the answer either. The process has failed yet again and we need to recognize that.
- Valodim 10mo ago
  Here is the short version from someone who took part in this process: while serving as the editor of the draft, Werner did not let anything into the draft that wasn't his own idea. But for his own ideas, there were cases where a new feature was committed to spec master and released in gnupg within the week. He was impossible to work with over many years, to the point that everyone agreed that the only way forward was to leave gnupg behind. This is a bonkers decision for OpenPGP as an ecosystem, but it was not made in ignorance of the consequences. And as far as I'm aware, even with today's hindsight, noone involved in the process regrets making the decision.

raphinou 10mo ago

I'm working on a multi sig file authentication solution based on minisign. Anyone knows the response of the dev regarding minisign's listed vulnerability? If I'm not mistaken, the response of the authors are not included in the vulnerabilities' descriptions.

jedisct1 10mo ago
Because the authors found out about it by chance on Hacker News. That said, these issues are not a big deal. The first one concerns someone manually reading a signature with cat (which is completely untrusted at that stage, since nothing has been verified), then using the actual tool meant to parse it, and ignoring that tool’s output. cat is a different tool from minisign. If you manually cat a file, it can contain arbitrary characters, not just in the specific location this report focuses on, but anywhere in the file. The second issue is about trusting an untrusted signer who could include control characters in a comment. In that case, a malicious signer could just make the signed file itself malicious as well, so you shouldn’t trust them in the first place. Still, it’s worth fixing. In the Zig implementation of minisign, these characters are escaped when printed. In the C implementation, invalid strings are now rejected at load time.

user3939382 10mo ago

If mass use of GPG benefited Microsoft, Amazon, Google and all the other assholes it would be polished, slick, and part of 9th grade curriculum. They call it “Face ID” that’s the Orwellian shit that makes money so that’s what we get instead. These things take resources, don’t blame the projects.

manuchojose76 10mo ago

[dead]

jwr 10mo ago

It has become fashionable to s*t on GnuPG. I just wish all the crypto experts doing that would point me to an alternative that is functionally equivalent. Something that will encrypt using AES-256 with a passphrase, but also using asymmetric crypto. Oh, and I want my secret keys printable if needed. And I want to store them securely on YubiKeys once generated (https://github.com/drduh/YubiKey-Guide https://github.com/drduh/YubiKey-Guide). I want to be able to encrypt my backups to multiple recipients. And I want the same keys (stored on Yubikeys, remember?) to be usable for SSH authentication, too. And by the way, if your fancy tool is written using the latest language du jour with a runtime that changes every couple of years or so, or requires huge piles of dependencies that break if you even as much as sneeze (python, anyone?), it won't do. BTW, in case someone says "age", I actually followed that advice and set it up just to be there on my systems (managed by ansible). Apart from the fact that it really slowed down my deployments, the thing broke within a year. And I didn't even use it. I just wanted to see how reliable it will be in the most minimal of ways: by having it auto-installed on my systems. If your fancy tool has less than 5 years of proven maintenance record, it won't do. Encryption is for the long term. I want to be able to read my stuff in 15-30 years. So before you go all criticizing GnuPG, please understand that there are reasons why people still use it, and are actually OK with the flaws described.

tptacek 10mo ago
There isn't an alternative that is functionally equivalent because what PGP does is dumb. It's a Swiss Army Knife. Nobody who wants to design an excellent saw sets out to design the Swiss Army Knife saw[†]. Nobody who needs shears professionally buys a Swiss Army Knife for the scissors. The cryptographic requirements of different problems --- backup, package signing, god-help-us secure messaging --- are in tension with each other. No one design adequately covers all the use cases. Trying to cram them all into one tool is a sign that something other than security is the goal. If that's the case, you're live action roleplaying, not protecting people. I'd be interested in whether you could find a cryptographer who disagrees with that. I've asked around! [†] I am aware that SAK nerds love the saw.
- picture 10mo ago

SEJeff 10mo ago

One of my coworkers, Liam, gave this talk. If you like this and want to work with like minded individuals, apply to some of our seceng roles: https://www.asymmetric.re/careers https://www.asymmetric.re/careers

theshrike79 10mo ago

Could someone rewrite GPG in Rust please?

KooBaa 10mo ago

The 12 vulnerabilities mentioned in “gpg fail” are somewhat exaggerated. Here you can find a reply from GnuPG: https://www.openwall.com/lists/oss-security/2025/12/29/9 https://www.openwall.com/lists/oss-security/2025/12/29/9 And btw, it was mentioned in the talk that GnuPG does not sign commits. That’s just wrong. Everything, including the release tarballs, is signed.

annalexandra 10mo ago

[dead]