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 <[email protected]> wrote: > On Sat, Jan 10, 2026 at 12:01 AM Jake Ginesin via Gnupg-devel > <[email protected]> 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 >
_______________________________________________ Gnupg-devel mailing list [email protected] https://lists.gnupg.org/mailman/listinfo/gnupg-devel
