libgcrypt P256 signature malleability via weak DER enforcement

[NIIBE Yutaka]

Hello,

Jake Ginesin wrote:
> libgcrypt's ECDSA signatures are malleable, as the signature verifier
> accepts malforned DER-encoded signatures.

Thank you for your report.

Let me explain my understandings.

(1) For ECDSA (or public key crypto in general), libgcrypt uses data
format with SEXP.  It's true that SEXP is a kind of relaxed format,
which allows multiple representations.

(2) An application may use different formats (like PGP, CMS, etc.).
>From the viewpoint of libgcrypt, it's a responsibility of an application
to validate data formats/values for its own representation(s).

(3) GnuPG handles CMS by gpgsm with libksba.  Typically, it's libksba
which processes the data to be used by libgcrypt.  It accesses data, and
converts DER encoded value into SEXP so that it can be used by
libgcrypt.

> 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.

Interpreting your words, I created a ticket for libksba.

	https://dev.gnupg.org/T8032

(I checked gpgsm and libksba, and I can't find the input validation of
DER encoded data/integer.)

Please add your comments to the ticket or reply this email, for further
discussion.
--