<div dir="ltr"><div id="gmail-:19j"><div class="gmail-wl4W9b"></div></div><div class="gmail-"><div class="gmail-aHl" id="gmail-avWBGd-125"></div><div id="gmail-:17u" tabindex="-1"></div><div class="gmail-ii gmail-gt" id="gmail-:19g"><div class="gmail-a3s gmail-aiL" id="gmail-:19h"><div id="gmail-avWBGd-128"><div dir="ltr"><div>Hi,<br><br></div><div>libgcrypt's
 ECDSA signatures are malleable, as the signature verifier accepts 
malforned DER-encoded signatures. We currently fail in three scenarios:<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></div><div>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></div><div>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.</div><div><br></div><div>The test vectors are available here: <a href="https://github.com/C2SP/wycheproof/blob/main/testvectors_v1/ecdsa_secp256k1_sha256_test.json" 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)</div><div><br></div><div>Similar issues received CVEs in other libraries (CVE-2020-13822, CVE-2024-42460).<br><br></div><div>Happy to provide my proof-of-concept exploits, Wycheproof-libgcrypt harness, or discuss further.<br><br></div><div>Thanks,<br>Jake<br></div><div><a href="https://jakegines.in" target="_blank">https://jakegines.in</a></div></div></div></div></div></div><br></div>