# Finding public key out of ECDSA certificate

I got an ECDSA certificate and now I'm trying to find out the public key. I'm not very familiar with this topic, so I hope you bear my (maybe silly question).

The reason I'm doing this is, because my task is to test the encryption part of a software. Well, actually it doesn't work fine, so the first thing I need to find out is, whether the issue is in the program, or I am the issue.

So I used an ASN1 decoder to read my test-certificate, which told me, that the curve prime256v1 is used and that my public key is

03 42 00 04 B4 60 C8 AA 5C 2A 63 20 84 79 D4 E7 73 53 67 A4 9D B9 D0 9D 56 B1 03 14 D9 65 9B 2D 04 76 CC 0E F9 79 AB C3 E5 75 72 25 33 6C 05 FF 40 BA 55 36 45 76 62 F1 5A 52 6F 57 E8 AB 0E E0 84 DF 39 3F

If I understood things right, the first octet 03 isn't interesting for me. The second octet 42 tells me, that the key consists out of 66 octets. Now we come to the interesting part; The 00 04 tells me, that I'm lucky and no point compression is used, which means, that the abscissa and ordinate Key are easy to find out.

Because of my prime number (related to my prime256v1) I know, that length of X and Y Key is 32 octets. So I take the first 32 octets to form the X-Key and the last 32 to form the Y Key, so

X_Key = B4 60 C8 >AA 5C 2A 63 20 84 79 D4 E7 73 53 67 A4 9D B9 D0 9D 56 B1 03 14 D9 65 9B 2D 04 76 CC 0E

Y_Key = F9 79 AB C3 E5 75 72 25 33 6C 05 FF 40 BA 55 36 45 76 62 F1 5A 52 6F 57 E8 AB 0E E0 84 DF 39 3F

Because my program requires 36 octets for X- and Y-Key, I add 4 leading zeros to get my result.

I would appreciate, if anyone of you can check the way I painted here and tell me whether I made some mistakes or not.

Thank you very much!

The 00 04 tells me, that I'm lucky and no point compression is used, which means, that the abscissa and ordinate Key are easy to find out.

Nope. The 00 tells you that no bits are unused from the bytes making up the ASN.1 BIT STRING, which is indicated by the first 03 valued byte.'

04 does of course indicate an uncompressed point, so your end result would still be correct.

Because of my prime number (related to my prime256v1) I know, that length of X and Y Key is 32 octets. So I take the first 32 octets to form the X-Key and the last 32 to form the Y Key

Officially the order of the curve determines the key size. Often there is no difference though. The name of the curve also contains a strong hint about the key size. The public key is however within $0$ and $P - 1$ inclusive (see comment of Poncho below).

Because my program requires 36 octets for X- and Y-Key, I add 4 leading zeros to get my result.

That should be OK, if the result is indeed interpreted as big endian (network order) value. It beats me why you need to add 4 additional zeros (to the left, I presume), but that might be a hardware implementation issue.

• Hi and thank you for your quick response! Ok, that means that my X and Y key seem to be fine, which is great. To explain your doubts; The main part of the present code is to prepare the key for other third party code, which seem to require this 36 octet format. Thank you for your help and best regards! – FFF_2016 Aug 19 '16 at 7:00
• Well, I don't expect a 256 + 32 = 288 bit curve, so that's my best guess anyway. Don't forget to accept the answer if it answers your question! – Maarten Bodewes Aug 19 '16 at 8:58
• 'the order of the curve determines the key size': correction: since we're talking about a public key here (and so what we have is an encoded EC point), both X and Y are values between 0 and P-1; and hence it's the field size (P) that's important; not the subgroup order. Yes, prime256v1 has cofactor 1, and so the distinction isn't important in this case, however let's be precise here. – poncho Sep 17 '16 at 17:50
• @poncho Thanks, fixed, let me know if there are other issues! – Maarten Bodewes Sep 17 '16 at 18:40