2017-09-03 5 views
0

I écrit le code ci-dessous pour extraire blob clé publique ECDH:Pourquoi la clé publique blob contient-elle le type de clé et la longueur de la clé dans le format big endian dans .net framework 4.7?

 var curve = ECCurve.NamedCurves.nistP256; 
     ECDiffieHellman ecdh = ECDiffieHellman.Create(curve); 

     var bytes = ecdh.PublicKey.ToByteArray(); 
     Console.WriteLine($"Public Key (byte length with format info): {bytes.Length}"); 

     var hexString = BitConverter.ToString(bytes).Replace("-", string.Empty); 
     Console.WriteLine($"Public Key (hex with format info): {hexString}"); 

Je suis sortie suivante:

  • clé publique (longueur d'octets avec des informations de format): 72

  • clé publique (hex avec des informations format): 45434B3120000000C3F1AC1F3D272BE14A26BE35B1A31F6C969425259162C06BEBE6AE977809984FC509ED5154E1E4782079D4BDDCDA6E083E48D271755267AD765CAD0E66B9FD9F

Les 4 premiers octets (type de clé) sont 45434B31 (au format hexadécimal). Cela semble être dans le grand format d'Endian où this MSDN link indique qu'il devrait être dans le petit format d'Endian, qui dicte que ces 4 octets devraient être 314B4345 (encore, comme montré dans ce lien). Le lien utilise également "magic", au lieu de "key type". Les 4 octets suivants sont 20000000 (au format hexadécimal) semble être dans le petit format endian (comme le dit le lien ci-dessus).

Y a-t-il une explication logique expliquant pourquoi le type de clé est formaté en big endian? Ou est-ce que je manque quelque chose ici?

+0

Little-endian signifie que l'octet le moins significatif (0x45) vient en premier. – wRAR

Répondre

1

Les 4 premiers octets (type de clé) sont 45434B31 (au format hexadécimal).

Ce serait 0x45434B31 (interprétation Big Endian), ou 0x314B4345 (interprétation peu Endian). 0x314B4345 (LE) correspond à l'entrée nistP256 dans votre page liée.

Le titre de votre question indique que vous croyez que la longueur a été stockée en big endian, mais le corps de votre question vous dites qu'il semble être peu endian. LE est correct. 20000000 est 0x00000020 (LE), ou "champs de 32 octets". 32 octets est 256 bits, ce qui correspond à la réponse attendue pour nistP256.


Notez que vous ne voulez vraiment pas utiliser ce format blob. Les courbes NIST P-256, 384 et 521 ont des valeurs "magiques" distinctes, mais les nouvelles courbes supplémentaires de Windows 10 sont toutes signalées sous 0x504B4345 (BCRYPT_ECDH_PUBLIC_GENERIC_MAGIC). Le nom de la courbe doit être porté en externe.

La bonne réponse sur .NET pour l'importation et l'exportation des valeurs de clé est la structure ECParameters via les méthodes ExportParameters et ImportParameters.

+0

Vous avez raison à propos de mon écriture sur la longueur de la clé. Mais pourquoi la documentation dit-elle que la "magie" (type de clé) devrait être en petit boutiste quand la valeur réelle est montrée comme gros boutiste? – Raghu

+0

La documentation montre la valeur en tant que constante numérique. Big/Little Endian concerne le stockage des valeurs. Si (en C) vous avez écrit '* blob = 0x314B4345' sur un système x86/x64 puis inspecter la mémoire, il apparaîtra comme' 45 43 4B 31' – bartonjs

+0

Je serais d'accord avec vous en ce que c'est un problème de stockage normalement. Lorsque j'appelle ToByteArray() et que j'obtiens les octets de résultat, je n'interprète plus les octets (comme cela a déjà été fait pour moi). Donc, je voudrais exepct de voir les premiers octets 8 comme 314B434520000000 (et non 45434B3120000000) par souci de cohérence. Est-ce que j'ai râté quelque chose? – Raghu