First of all, secp128r1 is outdated. Use curves that give better security for today's standard. See safecurves by Daniel J. Bernstein and Tanja Lange.
An Elliptic Curve defined over a field of size q and every element -point- has two coordinates X and Y. The Elliptic Curve Secp128r1 has 2128-297-1 size ℓ, i.e. number of points a little under 2^128. This means that we need 128-bit representation.
The public key which is also a point on the curve has two coordinates, therefore, we need to store two 128-bit.
If we look at the equation of the elliptic curve Y2 = X3 + aX + b where
a = FFFFFFFD FFFFFFFF FFFFFFFF FFFFFF
b = E87579C1 1079F43D D824993C 2CEE5E
if we know X from the equation we can find Y. Since we are working in a field the Y can have at most two square roots. Y2 will have y or -y as the square root. This knowledge can be used to compress the representation of a point and it is called point compression. Just x coordinate and one bit to select y or -y. Now look at the base point (see Certicom recommendation)
base point = 03 161FF752 8B899B2D 0C28607C A52C5B86
= 04 161FF752 8B899B2D 0C28607C A52C5B86 CF5AC839 5BAFEB13 C02DA292 DDED7A83
The first octet determines the structure
04 means there is no compression03 means there is a compression and select y as positive02 means there is a compression and select y as negative
Now turn into OP's parameters;
pub:
04:
04:ce:24:34:d4:cb:f2:58:94:2f:8a:5f:06:d7:3f:ed: -->X
5a:50:ef:fb:cc:b7:49:62:16:62:9e:aa:d5:30:a8:a5 -->Y
first octet 04 means there is no compression. The first line is the X coordinate and the second line is the Y coordinate of your public key.
What about the private key n? It is just a scalar -integer- between 0<=n<=ℓ
priv:
00:9f:bf:2b:bd:06:86:3a:a1:bc:7c:3e:90:57:40:f4:bc
Therefore, the above number - not point - is your private key.
You can also use some web tools to extract this information.
Note: please don't expose your private key.
BEGIN PRIVATE KEY marks the PKCS#8 private key format that OpenSSL has started using recently, while PuTTY only expects the 'traditional' / 'PEM' BEGIN RSA PRIVATE KEY format.
Feed the key through openssl rsa to convert it to the old format.
Both keys start with MII… because that's just how an ASN.1 sequence starts, when encoded in Base64, but PKCS#8 additionally has the key type inside, instead of relying on the PEM "BEGIN…" header. You can see the differences using openssl asn1parse.
Best Answer
Bare keys do not have "key IDs". They're just series of numbers.
If the key belongs to an X.509 certificate, then the certificate's fingerprint (a SHA-1 hash of the DER-encoded cert) will be used for identification:
openssl x509 -outform der | openssl sha1, oropenssl x509 -noout -fingerprint.Otherwise (if it's just a bare public/private keypair), the SHA-1 hash of the public key is used sometimes (again, DER encoding), but I don't know of any standard for it. You can extract the public key with
openssl rsar -pubout -outform der, again piping toopenssl sha1if that's what your program requires.The "key pair IDs" used by CloudFront are serial numbers of the database entry with that key. The same key, uploaded twice, will have different IDs; I just tested it.