Somewhat reminded of @jonah@neat.computer's general recommendation against GPG (for other reasons than what this talk is about)
post
For example, one of the first vulnerabilities I found, that was used for the introduction hook in the 39c3 talk, remains unpatched to this day. Instead of being fixed with code, Werner Koch - the main developer of GnuPG - published a blog post declaring the widely-used feature being "harmful"; while they had weeks in advance, they published this on day one of 39c3, not even giving us time to respond.
what the actual fuck
Alright, so just because a plain text signature is along with content, doesn't mean that the content is signed.
Then how do you check that the content is signed by the plain-text signature given with it?
I thought that the signature means that either a whole copy of the text is encrypted or a hash of the text is encrypted using the private key, which would mean that spoofing the sign would require solving complexity equal to either of:
- Finding another string that gives the same hash
- Finding the private key and signing a new hash with it
What am I missing?
Is there another thing to use? At least for the flow(s) of "encrypt, transfer, decrypt" or "sign, transfer, verify" for binary files. BSD licensed, preferably.
EDIT: minisign was mentioned on the talk... not in the most positive way but would still trust (after they get their shit together of course); however would never trust "age" with what they did
however would never trust "age" with what they did
What happened with age (or its devs?) that made you not trust it?
(I actually managed to watch basically the same talk at a different event on the site pgp.fail, whoops)
For me, I feel like the mistake mentioned was the most dead obvious one. Prefixing a plugin name from the file with a path then literally running the executable named. At the end of the talk, an age dev bought the researchers with stickers on camera.
Yeah, GPG is a dumpster fire. It’s security theatre at its finest.
Please bear with my dumb ass. if validating a certificate / signature is risking an RCE, does that essentially make this a planet-wide potential supply chain hack (wherever gnupg is used, at least?)
I'm probably having a brainfart (watched the video during insomnia), but re: the section 12m 10s into the video, can someone please clarify why "the instructions are dangerously wrong"?
I understand it relates to the earlier demo in which those instructions gave the illusion of "verifying" an ISO that was in fact malicious. But:
- why did those instructions fail to genuinely verify the ISO?
- what would the correct instructions have been?
Cleatext signing (having the signature and data in the same file) is broken in many ways. It is possible to put unsigned data at the top of the file in a way that sha256sum will use it. Watch the 39c3 GPG talk if your interested in the gory details.
The solution is to use detached signatures (checksum.txt and checksum.txt.gpg to verify that). This makes sure that all of checksum.txt is actually covered by the signature.
cc @modem_down@thebrainbin.org
or, binary signatures, [which I prefer: compressionable], as textfiles are insecure formats.
I prefer a headed, mided, and tailed verification, similar to MPEG keyframing, for constant stream verification.
idk about the specific formats, but i don't think you can say that in general. what are those two formats and why does it make a difference in this case?
- what binary signatures offer:
- smaller sizes
- ability to compression
- the actually signature
- confidentiality
-
File headers^def^, miding^def^, tailing^def^.
i don’t think you can say that in general
What is your academic literacy please?
Cite your papers please.
or gen z:
Drop your academic flex.
What grade you at?
papers pls🙏

no, i mean, you say text files are insecure and you prefer binary.
while it is true that processing text files needs additional code (validating/converting charsets/encoding), which increases the number of potential attack vectors, security threats introduced by this are not a fault of them being text, but of the parser code.
at the end of the day the attacker just switches from text editor to hex editor to prepare a malicious file.
I was never talking about vectorization, but regular file integrity. Textfiles have no error correctiveness. Yet a binary can be.
Either can be edited and vectorized. Heck the point of this talk is manipulating expectations, as sha256sum isn't file verifier.
yeah, but nobody stops you from adding error correctiveness. you could for example just put the whole thing three times with a seperator.
however there's also an important point for text files: you can post them wherever you can write text messages. being able to digitally sign them even adds to your freedom, as you can post anonymously and your readers are able to verify it's from the same source. like you could post your heated political manifesto or cousin incest smut on 4chan or some darknet forum and if you later make a part 2, ppl will be able to tell you apart from imposters.
Lexi Groves is quoting Fedora’s own mailing list irt social engineering. Both Fedora’s instructions are wrong, and the method to properly verify ISO, that to be brutal, should have been outdated decades ago, is “dangerously wrong.” It's a nice gibe.
Wearing a dog collar for a highly technical live presentation of a critical security feature requires a degree of personal confidence I can only admire.
GnuPG is one of those tools I never got around to use. How could something designed for human communication be so utterly cumbersome and confusing ?
I use it for git commit signing.
How could something designed for human communication be so utterly cumbersome and confusing ?
Several reasons, I guess?
1. The PGP (later, OpenPGP) protocol.
The proprietary PGP software, which was the initial implementation of the PGP protocol(s) also suffered from usability problems:
-
- Whitten, A., and Tygar, J. D. Usability of Security: a case study
-
- Whitten, A., and Tygar, J. D. Why Johnny Can’t Encrypt: A Usability Evaluation of PGP 5.0
-
- Atwater, E., Bocovich, C., Hengartner, U., Lank, E., & Goldberg, I. Leading Johnny to Water: Designing for Usability and Trust
-
- Ruoti, S., Andersen, J., Zappala, D., & Seamons, K. Why Johnny still, still can't encrypt: Evaluating the usability of a modern PGP client
2. GnuPG maintainers are implicitly using asymptotic software versioning
Donald Knuth was probably the most notable proponent of the idea that software packages should increasingly tend toward stability, with fewer and fewer patches needed. He used explicitly asymptotic version numbering for TeX and Metafont.
Some of the quotes in OP's video make imply GnuPG's maintainers are implicitly following a similar approach, e.g. the section about "Sequoia's need for churn".
With encryption software, there is an especially strong argument for being conservative about changes. Patches may have unforeseen consequences, adding subtle vulnerabilities.
However, the downside of this, as the gpg.fail team pointed out, is that it biases the GnuPG maintainers towards excessive rejection of patches. Especially patches that would improve usability. Arguably, TeX suffered from a similar bias; hence the development of LaTeX and newer TeX front-ends to improve usability.
3. Changing the interface would be effortful
Improving GnuPG's interface would require quite a lot of work in itself, both to the codebase and the documentation.
Releasing a version with those changes would also require fielding a lot of support queries for many years, because decades of software manuals all over the web were written for the traditional GnuPG interface, and aren't going to be updated overnight. Some of those manuals will surely never get updated, because they are no longer maintained even though they are still online and still used.
I can sympathise with the GnuPG maintainers for finding this daunting. But the improvements are needed. Thankfully, developers of tools like minisign, age, and sequoia are taking on much of this work; it's just a pity that the work had to be done in this fragmented way through third-party efforts, instead of in GnuPG itself.
Oh boy, I tend to hate videos, but this was amazing. GPG is big trouble. I've had issues with it before but now it's solidified. I'm not ready to use Sequoia and I'm not keen on Rust culture, but something has to be done. I confess to having thought about rewriting GPG in Haskell or Ada or even Rocq, but only at the level of daydreaming.
Haskell
I'm learning OCaml right now and it's been pretty dang awesome so far.
I'm doing Advent of Code 2025 and have made it to day 7 part 2. I've never done an AoC where my first attempt to run the code was correct on both the sample input and real input so many times in a row. I'm in love with this language.
OCaml is great, and there's an "extreme" version of it called Rocq (formerly Coq, the French word for rooster), that lets you literally prove correctness of your code: https://softwarefoundations.cis.upenn.edu/
Implemented in OCaml, interesting. 😁
Seems like it's mostly used academically though?
all 13 comments