[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<SYCPR01MB3661EE9E2D62A122A271AE98EEBCA@SYCPR01MB3661.ausprd01.prod.outlook.com>
Date: Tue, 30 Dec 2025 11:30:21 +0000
From: Peter Gutmann <pgut001@...auckland.ac.nz>
To: Demi Marie Obenour <demiobenour@...il.com>,
"oss-security@...ts.openwall.com" <oss-security@...ts.openwall.com>
Subject: Re: Many vulnerabilities in GnuPG
Demi Marie Obenour writes:
>Can we agree to use OpenSSH signatures ASAP?
PGP signatures are fine, for authenticating binaries we just need to use them
in a way where there's only one simple, unambiguous, and minimal-attack-
surface way to apply them, as well as a means of having them work over longer
time periods (see below). The alternative is to try to boil the ocean, which
would take a Heartbleed-style catastrophe to motivate.
>Interesting! Which ones don't work?
I'm using it to generate test data which will no doubt trigger odd behaviour
in some cases, and didn't record info about individual problems, just "type
this command to get this output" once I figured out what was required. An
example is:
gpg -b -z 0 --openpgp --homedir . -o signed4.pgp test.txt
(the --openpgp is for a GPG bug, without it it'll generate v3 sigs as if
--force-v3-sigs had been specified).
but for most of them all I've recorded is just whatever magic incantation
eventually worked to generate the required test data.
>Is that what gpgv and sqv are?
It depends on how much of the rest of GPG is still present. If it's just a
stripped-down front-end to the whole thing then it may still be subject to the
same vulns.
>I think the hard part of doing this isn't the signature handling itself, but
>rather the incredibly complex web of trust.
Does anything actually use the cobweb of trust, or do you just assume the key
you've got is good because doing anything else is too hard? Certainly for
authenticating Linux installs and updates the practice seems to be "grab the
key from this source via TLS, swear a lot because it's KEYEXPIRED, spend ages
Googling how to get the latest key, realise you have to install intermediate
updates to work your way up to what's current but the only remaining source
for those is a server in Botswana and all the apt options have changed and you
need to read a garbled blog post someone wrote at 3am when they ran into the
[ 25 more lines of pain snipped ]
just run with --allow-unauthenticated and ensuing zero security so you can
finally update your stuff before you die of old age". That's one thing
Microsoft did well with Authenticode, you don't get all your updates blocked
because your valid keys instantly became invalid after some timer ticked past
midnight.
>>I've actually done something like this myself, wrote simple apps pgpencrypt
>>and pgpdecrypt (size around 50kB)
>
>Are these available anywhere?
They're just some very quick things I threw together ten or more years ago,
motivated by:
/* Used to decrypt files that the four assorted command-line versions of PGP
can't handle */
(this was before GPG became the de facto universal standard). I can send you
the code privately if you like, but it probably won't be very useful.
>Yeah, that's *embarrassing*.
I wouldn't say it's embarrassing, more that it's a confirmation of Shamir's
Law, "crypto is bypassed, not attacked". To find the biggest holes in a
crypto app you need a pentester, not a cryptographer.
Peter.
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
