EccPublicBlob
maps to BCRYPT_ECCPUBLIC_BLOB format type, not X.509 SubjectPublicKeyInfo.
If all of your keys are on secp256r1/NIST P-256 then there's a pretty straightforward hacky approach.
You may have noticed that all of your keys start with MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE
. We'll see why shortly.
Convert
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEaq6djyzkpHdX7kt8DsSt6IuSoXjp
WVlLfnZPoLaGKc/2BSfYQuFIO2hfgueQINJN3ZdujYXfUJ7Who+XkcJqHQ==
to bytes (or, here, hex):
30 59 30 13 06 07 2A 86 48 CE 3D 02 01 06 08 2A
86 48 CE 3D 03 01 07 03 42 00 04 6A AE 9D 8F 2C
E4 A4 77 57 EE 4B 7C 0E C4 AD E8 8B 92 A1 78 E9
59 59 4B 7E 76 4F A0 B6 86 29 CF F6 05 27 D8 42
E1 48 3B 68 5F 82 E7 90 20 D2 4D DD 97 6E 8D 85
DF 50 9E D6 86 8F 97 91 C2 6A 1D
This is a DER encoded X.509 SubjectPublicKeyInfo blob.
Using our DER-fu we see
// SubjectPublicKeyInfo
30 59 // SEQUENCE, 0x59 == 89 bytes of payload
// AlgorithmIdentifier
30 13 // SEQUENCE, 0x13 == 19 bytes of payload
// AlgorithmIdentifier.algorithm
06 07 2A 86 48 CE 3D 02 01 // OBJECT ID 1.2.840.10045.2.1 (id-ecPublicKey)
// AlgorithmIdentifier.parameters
06 08 2A 86 48 CE 3D 03 01 07 // OBJECT ID 1.2.840.10045.3.1.7 (secp256r1)
// SubjectPublicKeyInfo.publicKey
03 42 00 // BIT STRING, 0x42 == 66 (65) payload bytes, 0 unused bits
// "the public key"
04
92F809EAC73630CD000055096D5383FE2DF860927C8A77AA4CDF83323A48E6AE
DF40D3C4BFDCB6CFF79C3E5F2A3EEB3C7E54B888B38EC5DC06A05D6653D9707C
Since the algorithm identifier is id-ecPublicKey
the parameters is an OID identifying the curve (in this case, secp256r1 / NIST P-256). And "the public key" is of a format from SEC 1 v2.0 (2.3.4 Octet-String-to-Elliptic-Curve-Point Conversion).
The most common encoding is type 04
, uncompressed key. (0x04 followed by Qx padded to the necessary length followed by Qy padded to the necessary length).
So, for all points encoded with type 04 on secp256r1 the byte pattern starts with
30 59 30 13 06 07 2A 86 48 CE 3D 02 01 06 08 2A
86 48 CE 3D 03 01 07 03 42 00 04
which happens to align to a common base64 prefix of MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE
.
What CNG wants is [32-bit identifier][32-bit little-endian length][padded Qx][padded Qy].
So the super-duper hacky version is:
private static readonly byte[] s_secp256r1Prefix =
Convert.FromBase64String("MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE");
// For ECDH instead of ECDSA, change 0x53 to 0x4B.
private static readonly byte[] s_cngBlobPrefix = { 0x45, 0x43, 0x53, 0x31, 0x20, 0, 0, 0 };
private static CngKey ImportECDsa256PublicKey(string base64)
{
byte[] subjectPublicKeyInfo = Convert.FromBase64String(base64);
if (subjectPublicKeyInfo.Length != 91)
throw new InvalidOperationException();
byte[] prefix = s_secp256r1Prefix;
if (!subjectPublicKeyInfo.Take(prefix.Length).SequenceEqual(prefix))
throw new InvalidOperationException();
byte[] cngBlob = new byte[s_cngBlobPrefix.Length + 64];
Buffer.BlockCopy(s_cngBlobPrefix, 0, cngBlob, 0, s_cngBlobPrefix.Length);
Buffer.BlockCopy(
subjectPublicKeyInfo,
s_secp256r1Prefix.Length,
cngBlob,
s_cngBlobPrefix.Length,
64);
return CngKey.Import(cngBlob, CngKeyBlobFormat.EccPublicBlob);
}
To support other curves you need to change the first 4 bytes of the CNG blob to the correct "Magic" value, and change the 5th byte to be the correct length. And, of course, different SubjectPublicKeyInfo prefixes, and 64 won't be the public key coordinate length (64 == 256 / 8 * 2). But all of that is left as an exercise to the reader.
See C# and PHP ECDH not matching for the reverse.