# SHA-256 private/public coordinates to the PEM format

I feel that my question might display a bit of ignorance. I have been searching for answers, but have had no luck--perhaps my assumptions are wrong. I apologize if that is the case.

Context: I have a microcontroller communicating with a server. Every frame is signed using a private key from an RSA/SHA-256 public/private key pair. The pair is generated externally with OpenSSL, and the public key is in the PEM format, which is something like this (it is a not a used key):

-----BEGIN PUBLIC KEY-----
GZspxrVU+2ZbkDej5KNzGXu5lJdBzATU/h/S4Y2DgwaaN0tRMxX4QeN7x90qmdkO
oUQggpbv7rvju3idBp0fDcV6M56mnkw+EeyeNjDsRqoUVD/zlQdEUUcC00iItu8N
0GH08Ex8ubBhXQ7XAgMBAAE=
-----END PUBLIC KEY-----


My issue: Due to performance problems on the microcontroller, we had to use an external chip (for instance, ATECC608A) for all of these cryptographic processes. Also, it will be useful for production because this chip can generate its own private/public keys SHA-256 keys. When generating the SHA-256 private key, the chip returns me the public key. However, it does not return me a public key in the .pem format, but, according to the datasheet, it returns me the coordinates X and Y of the public key, which are 64 bytes.

My questions:

1. My first assumption that might be mistaken is this: I assume that a SHA256 pair is the same thing as RSA-SHA256. I know that there are many variants of the SHA256 algorithm, but based on what I've read, the RSA is the standard variant. So I am assuming that RSA-SHA256 is the same thing as SHA256. Am I right?

2. Assuming I have RSA-SHA-256, how can I convert these coordinates to .pem? On the server-side, I was using the .pem public key of the device to verify the signature. Now I am only able to share some coordinates of the public key. Is it possible to convert from coordinates to .pem? Or am I just misunderstanding a bunch of different concepts?

What you are sharing is indeed (lapo.it ASN.1 decoder) a 1023 bit public RSA key. RSA keys can be used for multiple things such as signature generation. In that case the signature algorithm may use SHA-256 to hash the message, but the key itself doesn't care about the hash function used (you won't see it in the structure in the link).

"private/public keys SHA-256 keys."

SHA-256 is a hash algorithm; it doesn't use any keys and certainly not a key pair.

OpenSSL command line only indicates the hash algorithm, but in that case it just assumes PKCS#1 v1.5 compatible RSA signature generation / verification if you use an RSA private or public key respectively; possibly other API's or command lines do the same.

However it returns me not a public key in a .pem format but, according to the datasheet, it returns me the coordinates X and Y of the public key, which are 64 bytes.

X and Y coordinates are not components of an RSA public key. Together they are usually indicating a point on an elliptic curve though. What you are likely getting is a flat representation of EC public key (usually indicated as variable name $$W$$). In that case they public key may consist of 2 times 32 bytes (i.e. two statically sized unsigned big integer values).

My first wrong assumption can be the fact that I am assuming that a SHA256 pair is the same thing as RSA-SHA256. I know that there are many variants of SHA256 algorithm, but from what I've read the RSA is the standard variant. So I am assuming that RSA-SHA256 is the same thing as SHA256. Am I right?

So no, there is no such thing as a SHA-256 pair. More likely it is a P-256 (or, alternatively named secp256r1) public key. Here P-256 and secp256r1 indicate the curve's domain parameters by name, i.e. a named curve.

Assuming I have the RSA-SHA-256, how can I convert these coordinates to .pem? On the server side, I was using the .pem public key of the device to verify the signature. Now I am only able to share some coordinates of the public key? It is possible to convert from coordinates to .pem? Or am I just misunderstanding a bunch of different concepts?

That's better asked at StackOverflow indicating the exact runtime & libraries that you plan to use.

The steps are:

1. put the numbers into the X9.62 structure;
2. put those into a SubjectPublicKeyInfo ASN.1 structure while indicating elliptic curve cryptography as algorithm and the domain parameters by OID;
3. DER encode above structure;
4. perform the PEM encoding to apply the "ASCII armor", i.e. make it text.

Yeah, I know, outside of your experience field, sorry.

• A 1023 bit RSA public key. I hope somebody made a typo when generating that one... Jan 29 at 11:53
• Ok. I learned a lot with a few words. And I confirm that the generated public key is based on P256 prime curve, I've read the datasheet with different eyes now. So I guess I'll have to change the server keys and algorithm or figure it out a way to store RSA keys on the crypto chip. Thanks a lot for your lesson! Jan 29 at 15:34
• You're welcome. BTW, it's P-256 with a dash, just like SHA-256. Sometimes programmers don't think that dashes are all that useful, but let's keep to the term as defined in the standard, makes life easier when e.g. searching for it. Jan 29 at 16:02
• You don't mean X9.42; that was classic/integer/modp DH. X9.62 is ECDSA and X9.63 is ECDH; both use a publickey=ECpoint format that is NOT ASN.1 and has fixedlength unsigned field(s) for the coordinate(s), although it is embedded in the X.509 SubjectPublicKeyInfo which is ASN.1 and the curve is defined (usually by an OID, although other forms exist) in the ASN.1 part specifically in the parameters part of the AlgorithmIdentifier Jan 30 at 1:05
• Thanks, I always confuse the two standards. I guess I need to take another look at ECDSA certificates again. I'm now repeating DH comes before ECDH a thousand times in my head - just 10 times used to be enough :) Jan 30 at 15:37