# BER or DER X9.62 for ECDSA signature

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?

• I think it is DER, but X9.62 is behind a pay-wall. – Maarten Bodewes Apr 8 '15 at 22:12
• 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. – Maarten Bodewes Apr 9 '15 at 15:05
• 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 . – dave_thompson_085 May 9 '15 at 18:11

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.

• 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! – Maarten Bodewes Jun 13 '18 at 20:03
• I've added it, it's the 1998 version. I wonder if the 2005 version is any different... – Conrado Jun 13 '18 at 20:16
• By 1998 version you mean this one? Working Draft ANS X9.62-1998 – pintor Jun 14 '18 at 12:33
• Dang, now I can just add a bounty of 200 which is overdoing it. Apologies, you were first but the answer by Thomas is much more extensive. And yes, it's still the same in the newer 2005 version it seems. – Maarten Bodewes Jun 14 '18 at 23:35
• @MaartenBodewes no problem, Thomas deserves it! – Conrado Jun 15 '18 at 11:32