The signature format for ECDSA signatures can be encoded using ASN.1 integers according to X9.62 or it can comprise of two integers with the same size as the key size.

In case the X9.62 format is used is it mandatory to use DER encoding (distinguished encoding rules) of the result, or is BER encoding (basic encoding rules) also acceptable?

  • 1
    $\begingroup$ I think it is DER, but X9.62 is behind a pay-wall. $\endgroup$
    – Maarten Bodewes
    Commented Apr 8, 2015 at 22:12
  • $\begingroup$ The SEC1 document just uses DER as example and specifies only ASN.1 - that's still not very conclusive. DER may be the de facto standard. $\endgroup$
    – Maarten Bodewes
    Commented Apr 9, 2015 at 15:05
  • 2
    $\begingroup$ FWIW, OpenSSL recently started checking signatures (including ECDSA) for strict DER because of CVE-2014-8275, and this broke BitCoin-core for (some?) signature(s?) in the blockchain: bitcoin.stackexchange.com/a/35845 . $\endgroup$ Commented May 9, 2015 at 18:11

2 Answers 2


Annex E of X9.62-2005 says:

Annex E provides the syntax for elliptic curve cryptography, including domain parameters, keys and signatures, according to Abstract Syntax Notation One (ASN.1). Although it is not required that elliptic curve domain parameters, keys, and signatures, be represented with ASN.1 syntax, if they are so represented, then their syntax shall be as defined here. Though it is likely that these ASN.1 definitions will be encoded using the Distinguished Encoding Rules (DER), other encoding rules may also be used.

RFC 3279, section 2.2.3 mandates use of ASN.1 to represent signatures, but, surprisingly, says nothing about encoding rules (whereas it explicitly requires DER for public keys).

Some cryptographic libraries insist on strict DER. Project Wycheproof contains some test vectors that check that (the reason which is given is: "to limit signature malleability"). OpenSSL is one such library: after decoding the incoming signature, it reencodes it with strict DER rules and checks that it obtains the exact same sequence of bytes. Apparently, this is due to a "vulnerability" known as CVE-2014-8275, where some systems implement blacklist on certificates by fingerprint, i.e. hash of the whole certificate (and not just the internal to-be-signed). In my opinion, blacklist systems do not offer good security and it was pretty daft to use the fingerprints for that, but apparently the OpenSSL developers thought that they needed to enforce strict DER encoding of both (EC)DSA signatures, and the outer layer of the certificate itself.

Other libraries accept variants. For instance, BearSSL requires the lengths to be explicit, but not necessarily minimal (i.e. some extra leading bytes of value 0x00 are accepted for the two INTEGER values).

From these data points, it seems that non-strict-DER encodings of signatures are nominally acceptable, as per the relevant standards, but they won't be accepted everywhere. Thus, in practice, any ECDSA library should ensure that the signatures it produces follow strict DER rules.


According to Section 6 of X9.62-1998, any encoding may be used:

While it is likely that these ASN.1 definitions will be encoded using the Distinguished Encoding Rules (DER), other encoding rules may also be used.

  • $\begingroup$ Ah, that means it is up to the protocol to specify the encoding. I will try and make sure that they do. Could you add the X9.62 version you are referring to? Thanks! $\endgroup$
    – Maarten Bodewes
    Commented Jun 13, 2018 at 20:03
  • 1
    $\begingroup$ I've added it, it's the 1998 version. I wonder if the 2005 version is any different... $\endgroup$
    – Conrado
    Commented Jun 13, 2018 at 20:16
  • $\begingroup$ By 1998 version you mean this one? Working Draft ANS X9.62-1998 $\endgroup$
    – pintor
    Commented Jun 14, 2018 at 12:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.