x509: unsupported elliptic curve

Reproduit avec Go 1.26. Les fonctions d’analyse des clés privées signalent la même limite en d’autres termes : ParseECPrivateKey renvoie « x509: unknown elliptic curve », ParsePKCS8PrivateKey « x509: failed to parse EC private key embedded in PKCS#8: x509: unknown elliptic curve ».

Go crypto/x509 — ParsePKIXPublicKey / ParseCertificate

Ce que cela signifie

La structure de la clé ou du certificat s’analyse sans problème, mais l’OID de sa courbe ne fait pas partie de ceux que la bibliothèque standard de Go prend en charge : crypto/x509 ne gère que les courbes NIST P-224, P-256, P-384 et P-521. En pratique, cette erreur concerne presque toujours une seule courbe : secp256k1, celle de Bitcoin et d’Ethereum, délibérément laissée hors de la bibliothèque standard. L’équipe Go fournit les courbes NIST avec des implémentations en temps constant et laisse tout le reste aux paquets tiers.

Pourquoi cela se produit

• Clés secp256k1 passées aux fonctions d’analyse de la bibliothèque standard

  fréquente

  Les clés générées avec openssl ecparam -name secp256k1 (ou exportées depuis des outils blockchain) portent l’OID 1.3.132.0.10. Le paquet x509 de Go reconnaît dans cet OID une clé EC, mais ne dispose d’aucune implémentation de cette courbe et s’arrête là.

• Brainpool, GOST ou autres courbes nationales

  occasionnelle

  Les certificats sur les courbes européennes Brainpool et d’autres courbes non NIST apparaissent dans certains écosystèmes gouvernementaux et bancaires ; la bibliothèque standard les traite exactement comme secp256k1 : enveloppe analysable, courbe non prise en charge.

• Anciennes courbes de petite taille

  rare

  L’ancien matériel cryptographique sur des courbes de la classe secp160/192 n’est pas pris en charge et se révèle en outre cryptographiquement insuffisant aujourd’hui ; la réponse est la migration, pas l’analyse.

Comment corriger l’erreur

1. 1.

   Analyser secp256k1 avec une bibliothèque dédiée

   Extrayez vous-même le point brut (ou à partir de la structure SEC1) et transmettez-le à une implémentation secp256k1 maintenue, comme celle de dcrd.

   import (
       "github.com/decred/dcrd/dcrec/secp256k1/v4"
       "github.com/decred/dcrd/dcrec/secp256k1/v4/ecdsa"
   )
   
   pub, err := secp256k1.ParsePubKey(pointBytes)  // 33/65-byte SEC1 point
   ok := ecdsa.VerifySignature(...)               // via the package's ecdsa subpackage

2. 2.

   Ou migrer la charge de travail vers P-256

   Si rien dans le système n’exige secp256k1 (aucune interopérabilité blockchain), régénérez les clés sur une courbe prise en charge par la bibliothèque standard : toute la chaîne d’outils s’en trouve simplifiée.

   openssl ecparam -name prime256v1 -genkey -noout -out key.pem
   openssl pkey -in key.pem -pubout -out pub.pem

3. 3.

   Vérifier quelle courbe la clé ou le certificat utilise réellement

   Avant de recourir à une bibliothèque, lisez l’OID de la courbe dans le fichier : 1.3.132.0.10 correspond à secp256k1, 1.2.840.10045.3.1.7 à P-256. Cela permet aussi de repérer les fichiers mal étiquetés, dont la courbe n’est pas celle qu’annoncent le nom du fichier ou la documentation.

   openssl ec -in key.pem -noout -text | grep -A1 "ASN1 OID"
   openssl x509 -in cert.pem -noout -text | grep -iA2 "public key algorithm"

← Parcourir toute la base de données des erreurs de signature