libgcrypt P256 signature malleability via weak DER enforcement

[Jeffrey Walton]

On Sat, Jan 10, 2026 at 12:01 AM Jake Ginesin via Gnupg-devel
<gnupg-devel at gnupg.org> wrote:
>
> libgcrypt's ECDSA signatures are malleable, as the signature verifier accepts malforned DER-encoded signatures. We currently fail in three scenarios:

Forgive my ignorance... The DER restriction is usually in effect when
producing ASN.1 encoded objects, like when writing a public key or
producing a signature.

When consuming data, like a signature for verification, I _thought_
BER was the standard.

> 1. Missing leading zero: per X.690 section 8.3.3, integers are two's complement. A positive integer with high bit set requires a leading 0x00 to avoid being interpreted as negative. libgcrypt accepts signatures missing this byte.
>
> 2. Extra leading zeros: per X.690 section 8.3.2, integer encoding must be minimal. libgcrypt accepts r/s values with unnecessary leading zeros.
>
> 3. BER long-form length: per X.690 section 10.1, DER requires the definite length form encoded in the minimum number of octets. libgcrypt accepts BER-style long-form encoding where short-form is required.
>
> The test vectors are available here: https://github.com/C2SP/wycheproof/blob/main/testvectors_v1/ecdsa_secp256k1_sha256_test.json (tcId 6, 8, 84, 128 are relevant for this issue)
>
> Similar issues received CVEs in other libraries (CVE-2020-13822, CVE-2024-42460).

They look like worthless CVEs to me.  They effectively say "this could
be bad if a program fails because of it", but they offer no
substantial proof of such a program.

> Happy to provide my proof-of-concept exploits, Wycheproof-libgcrypt harness, or discuss further.

If you can provide a non-trivial Proof of Concept for a DoS or a wild
memory write, then I would like to see it.

Jeff