1
$\begingroup$

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:

308201333081EC06072A8648CE3D0201
3081E0020101302C06072A8648CE3D01
01022100A9FB57DBA1EEA9BC3E660A90
9D838D726E3BF623D52620282013481D
1F6E5377304404207D5A0975FC2C3057
EEF67530417AFFE7FB8055C126DC5C6C
E94A4B44F330B5D9042026DC5C6CE94A
4B44F330B5D9BBD77CBF958416295CF7
E1CE6BCCDC18FF8C07B60441048BD2AE
B9CB7E57CB2C4B482FFC81B7AFB9DE27
E1E3BD23C23A4453BD9ACE3262547EF8
35C3DAC4FD97F8461A14611DC9C27745
132DED8E545C1D54C72F046997022100
A9FB57DBA1EEA9BC3E660A909D838D71
8C397AA3B561A6F7901E0E82974856A7
0201010342000448E231AF19DF341C82
63521A9436ACBCA5ACB7E3C56A63187B
F22539BE8242FF82F5521F619977FEE1
3457490123F04915671C7AF755E98465
FD20AECAAF7F58

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
Improve this question
$\endgroup$
2

1 Answer 1

Reset to default
1
$\begingroup$

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.

Improve this answer
$\endgroup$
6
  • $\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. 6.1.2.3 : "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
    Commented 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 ♦
    Commented Nov 24, 2017 at 12:57
  • $\begingroup$ Active Authentication actually (icao.int/publications/Documents/9303_p11_cons_en.pdf). Sec. 6.1.2.3 is for Acive Authentication specifically. $\endgroup$
    – tzippy
    Commented 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 ♦
    Commented 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
    Commented 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.