Re: v5 vs v6 consequences

Andrew Gallagher via Gnupg-devel <[email protected]> Mon, 15 Sep 2025 11:00:15 +0100
Newsgroups	gmane.comp.encryption.gpg.devel
Message-ID	<[email protected]>
On 15 Sep 2025, at 03:28, Jacob Bachmeyer <[email protected]> wrote:
> 
> On 9/14/25 02:27, Andrew Gallagher via Gnupg-devel wrote:
>> [...] A few other implementations had support for v5 keys since before the schism, but all except gnupg agreed to move to v6 once the issues with v5 signatures became known.
> [*sigh*]
> 
> What are the issues with v5 signatures?
> 

The issue is that they are convertible to v3 signatures over different data (see e.g. https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/130). The likelihood of exploitation is nonzero, and so most implementers agreed that it was better to modify the wire format. GnuPG disagreed with the modified (now v6) signature format because it didn’t sign over the literal data metadata by default (file name, file type and file modification date), which v5 signatures do - although the librepgp spec also defines a more generic method of signing over the file metadata using any signature version, but GnuPG has not implemented it. Ironically, it has since emerged that the way v5 signatures sign over the metadata is also flawed (although not exploitable in practice).

The fundamental issue leading to both flaws in the v5 signature design arises from the fact that *PGP stores metadata in a "trailer" at the end of the data stream being signed over, rather than prefixing it. This means that standard computer-science tricks to prevent ambiguity, such as prefixing data fields with their lengths, or always storing values at a fixed offset from the start of the data stream, are not effective in pgp trailers. Instead, values must be stored at a fixed offset from *the end* of the data stream - and v5 signatures violate this principle in more than one place. What makes it worse is that v4 signatures contain fixed values at certain offsets that make no sense unless you understand that they exist purely to avoid aliasing between v4 and v3. GnuPG was part of the design team for v4 signatures, so should have been well aware of this. But by changing the size of one field and introducing a novel field for the metadata, v5 signatures no longer store these anti-aliasing fixed values at the correct offsets. The fact that these errors are not easily exploitable appears to be by pure accident, not by design.

To be blunt, this is why we have standards processes for security protocols. The more eyes on the document, the more people thinking about the design process, the more likely that such mistakes will get caught early. One of the reasons given by GnuPG for why they continued with the v5 signature format is that the v5 signature verification code had already been shipped in production. But this was GnuPG’s choice, and a self-inflicted problem. Dissenting voices were locked out of the design process, and when they did eventually scrutinise the details it was too late.

Security is a collective process.

A

_______________________________________________
Gnupg-devel mailing list
[email protected]
https://lists.gnupg.org/mailman/listinfo/gnupg-devel
signature.asc (application/pgp-signature, 833 B)