<div dir="ltr"><div><div>Hey Jeff,<br><br></div>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]<br><br></div><div>Thanks,<br></div><div>Jake<br><a href="https://jakegines.in">https://jakegines.in</a> </div><div><br></div><div>References:<br></div><div>[1] <a href="https://fstar-lang.org/papers/asn1star.pdf">https://fstar-lang.org/papers/asn1star.pdf</a><br>[2] <a href="https://www.andrew.cmu.edu/user/bparno/papers/verdict-x509.pdf">https://www.andrew.cmu.edu/user/bparno/papers/verdict-x509.pdf</a><br>[3] <a href="https://arxiv.org/pdf/1403.6676">https://arxiv.org/pdf/1403.6676</a></div><div>[3] <a href="https://github.com/JakeGinesin/gcrypt-p256-malleability-poc">https://github.com/JakeGinesin/gcrypt-p256-malleability-poc</a></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, Jan 14, 2026 at 4:53 PM Jeffrey Walton <<a href="mailto:noloader@gmail.com">noloader@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sat, Jan 10, 2026 at 12:01 AM Jake Ginesin via Gnupg-devel<br>
<<a href="mailto:gnupg-devel@gnupg.org" target="_blank">gnupg-devel@gnupg.org</a>> wrote:<br>
><br>
> libgcrypt's ECDSA signatures are malleable, as the signature verifier accepts malforned DER-encoded signatures. We currently fail in three scenarios:<br>
<br>
Forgive my ignorance... The DER restriction is usually in effect when<br>
producing ASN.1 encoded objects, like when writing a public key or<br>
producing a signature.<br>
<br>
When consuming data, like a signature for verification, I _thought_<br>
BER was the standard.<br>
<br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> The test vectors are available here: <a href="https://github.com/C2SP/wycheproof/blob/main/testvectors_v1/ecdsa_secp256k1_sha256_test.json" rel="noreferrer" target="_blank">https://github.com/C2SP/wycheproof/blob/main/testvectors_v1/ecdsa_secp256k1_sha256_test.json</a> (tcId 6, 8, 84, 128 are relevant for this issue)<br>
><br>
> Similar issues received CVEs in other libraries (CVE-2020-13822, CVE-2024-42460).<br>
<br>
They look like worthless CVEs to me.  They effectively say "this could<br>
be bad if a program fails because of it", but they offer no<br>
substantial proof of such a program.<br>
<br>
> Happy to provide my proof-of-concept exploits, Wycheproof-libgcrypt harness, or discuss further.<br>
<br>
If you can provide a non-trivial Proof of Concept for a DoS or a wild<br>
memory write, then I would like to see it.<br>
<br>
Jeff<br>
</blockquote></div>