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
