libgcrypt P256 signature malleability via weak DER enforcement

[Jake Ginesin]

Hey Jeff,

Thanks for your response. For some concrete examples, it is my
understanding that non-malleability in DER parsing is important for X.509
certificate validation [1,2] and preventing transaction malleability [3].
Also, I went ahead and publicized my proof-of-concept for the first point
in this thread's initial email. [4]

Thanks,
Jake
https://jakegines.in

References:
[1] https://fstar-lang.org/papers/asn1star.pdf
[2] https://www.andrew.cmu.edu/user/bparno/papers/verdict-x509.pdf
[3] https://arxiv.org/pdf/1403.6676
[3] https://github.com/JakeGinesin/gcrypt-p256-malleability-poc

On Wed, Jan 14, 2026 at 4:53 PM Jeffrey Walton <noloader at gmail.com> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260114/d61d92d5/attachment-0001.html>