On 12/29/25 19:57, Peter Gutmann wrote: > Stephan Verbücheln writes: > >> The overall status is not good though. > > I'm more concerned about a slightly different aspect, that two researchers > (apparently) walked up to GPG and quickly found a pile of bugs, many relating > to authentication [0]. OpenPGP sigs are the de facto universal standard for > authenticating code and binaries in the non-Windows world, the equivalent of > Windows Authenticode, and GPG is the tool that's used for that. The one with > all the bugs in its authentication handling.
I agree. Can we agree to use OpenSSH signatures ASAP? Those actually are decently designed, though I do wish that they had the ability to include structured metadata. One could abuse the "reserved" field for this, though. Of course, it should only be parsed after verifying the signature. > There are two issues that cause this, the first being that GPG is staggeringly > complex. It's not a sign-and-encrypt app any more but an entire suite that > runs daemons/services, spawns off subprograms, creates and uses a ton of files > in its own proprietary data formats, and has a million command-line options > that change across releases (I use it for generating OpenPGP test vectors so I > get to try lots of options that, by the looks of it, no-one else uses because > some of them function other than expected or not at all). Interesting! Which ones don't work? > The second one is the format, best summed up by Thomas Ptacek's comment at > https://news.ycombinator.com/item?id=46404339 which begins: > > 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). > > For an example of this, consider compressed signed data, so you've got an EDI > transaction that you want to compress (it's a large blob of fixed-format text) > and then sign. With CMS (Cryptographic Message Syntax) you get: > > Sign( Compress( Message ) ) > > With OpenPGP it's a crapshoot. You'd expect something like the above but what > GPG does is: > > Compress( One-pass Sig || Message || Signature ) > > which is valid but pretty unexpected. And then any application needs to have > complex and awkward logic to process these things as per tptacek's comment. Sequoia actually uses a full parser generator (LALRPOP) to deal with this.That is the only reasonable approach I know of. Incidentally, this should also be able to handle CMS just fine. The only caveat is the parser needs to be able to tell the lexer to return a single token for a certificate or CRL, and that requires an ugly lexer hack that depends on the parser not reading too many tokens ahead of time. > To appreciate just how bad it really is, grab a copy of RFC 9580 and see how > long it takes you to write down the sequence of fields (not packets, fields) > that you'd expect to see in a message encrypted with RSA and signed with > Ed25519 (to grab the two opposite ends of the cryptographic spectrum) as well > as the cryptographic bindings between them, i.e. which bits get hashed/signed/ > processed, and also provide a confidence level in your work. I suspect most > people won't even get to that, the answer would be "I can't figure it out". > > A solution for mission-critical use like authenticating downloaded binaries > would be to do two things: > > 1. Create an app that does just that and nothing else: Here is a blob of data, > here is a detached signature, is it valid for the data? Is that what gpgv and sqv are? I think the hard part of doing this isn't the signature handling itself, but rather the incredibly complex web of trust. Detached signatures seem to be the only semi-reasonable part of OpenPGP. > 2. Define a fixed format for Authenticode-style signatures in OpenPGP form > that allows one and only one agglutination of OpenPGP packets and fields in > packets that are considered a valid signature. I actually did that myself as part of <https://github.com/QubesOS/qubes-rpm-oxide>. The OpenPGP parser built in to RPM wasn't something I wanted to expose to untrusted input, and the RPM version in Qubes OS dom0 was end of life. I added a validator that checked for the only expected format: one signature packet. I haven't looked much into how OpenPGP encryption works and I agree that it's a much worse mess. > I've actually done something like this myself, wrote simple apps pgpencrypt > and pgpdecrypt (size around 50kB) that do exactly what the name says and > nothing else so I don't have to remember a million command-line options and > deal with a pile of files and settings. It's just "pgpencrypt file", and > there's little facility to perform attacks like in the talk because there's no > extra capabilities there to attack. Are these available anywhere? (snip) > [0] The talk doesn't cover how much effort was involved, the speakers mention > they're not cryptographers but pen-testers so no crypto knowledge was > required. Yeah, that's *embarrassing*. -- Sincerely, Demi Marie Obenour (she/her/hers)
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
