I have an ECDSA Public Key in DER Format. I viewed the file in an ASN1 Editor and there's the OID 1.2.840.10045.1.1 whose superior (1.2.840.10045.1) is ecdsa-with-SHA1. So I thought that SHA1 is used here. But it turns out that a signature generated with the corresponding private key could only be verified with openssl when I used EVP_sha256().

How do I get this information about which hash algorithm is used from the whole key? This is the whole key:


EDIT: This is a signature in plain format, verifiable with the public key posted above:

93 ea c4 0a 7e 26 04 dc b9 a1 05 34 b1 52 57 2a
0e 1a c8 d2 d5 fc 96 e5 95 c2 45 3d 71 c7 82 8a
0c ac 72 96 01 8c ef 87 b6 9c e2 55 74 e6 de 2d
c6 a3 5c f0 c6 5e 72 27 3a 30 e0 50 33 16 ed 2d

1 Answer 1


For the public key there is no hash defined. The hash is a configuration option for the signature generation algorithm but it would work for any EC key.

And your information about the key is, for that reason, also incorrect. SHA-1 is maybe mentioned by a tool, but the OID you gave can be written out in long-form (ASN.1 notation) as:

{iso(1) member-body(2) us(840) ansi-x962(10045) fieldType(1) prime-field(1)}

... there is no SHA-1 in there.

So basically the signature generation is dependent on the application you used to produce the signature.

If it is configurable then the hash algorithm should be included with the signature - not with the key. It would of course be advisable to validate that the signature and hash algorithm are within a pre-configured range if they are configurable: you do not want to verify MD-5 / SHA-1 based signatures anymore.

Note that ECDSA directly use the hash without padding (possibly even using fewer bits than is in the hash). No hash algorithm indication is (or can be) used within the signature format itself. The padding of RSA signatures generally contain a hash identifier that can be viewed modular exponentiation with the RSA public key.

  • $\begingroup$ Thanks for elaborating. The Signature is generated on a chip, I dont have influence on the config, however there's a specification in the Document "ICAO9303" part11 sec. : "A hash algorithm, whose output length is of the same length or shorter than the length of the ECDSA key in use, SHALL be used". As I understand this, the signature SHALL be generated with an algorithm that produces a hash that is of the same length as the EC public key whis is used to verify the signature? $\endgroup$
    – tzippy
    Nov 24, 2017 at 12:50
  • $\begingroup$ ECDSA is used in several parts of the ICAO spec; which part are you referring to? Chip Authentication, Terminal Authentication? Sorry, I don't have the ISO spec here. $\endgroup$
    – Maarten Bodewes
    Nov 24, 2017 at 12:57
  • $\begingroup$ Active Authentication actually (icao.int/publications/Documents/9303_p11_cons_en.pdf). Sec. is for Acive Authentication specifically. $\endgroup$
    – tzippy
    Nov 24, 2017 at 12:59
  • $\begingroup$ Bugger, I don't even remember how this was done and, to be honest, if the signature format was ever correctly specified. Note that ICAO specs do not always make complete sense - especially when it comes to AA, which, to be honest, was a mess to begin with (ISO/IEC 9797 signatures, really?). If the algorithm is anywhere it is in a SecurityInfo object, but I doubt it. Note that this is also a problem for the RSA signatures where the hash is within the signature but the standard requires that the verifier is pre-configured with it. $\endgroup$
    – Maarten Bodewes
    Nov 24, 2017 at 13:18
  • $\begingroup$ Maarten, thanks so far. As the ICAO doc specifies, the chip should use a hash algo producing an output of same length or shorter than the ECDSA key. The signature I posted is verifiable with EVP_sha1() as input paramter to EVP_DigestVerifyInit. However the hash length of SHA1 is 20 bytes and the EC key is 128 bytes in length. Another passport has the same length EC Key (128 bytes) and produces signatures also of the same length. But they require EVP_sha256() to be verified. I dont quite get that. $\endgroup$
    – tzippy
    Nov 24, 2017 at 13:22

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.