DataError: Data provided to an operation does not meet requirements

C’est le nom de la DOMException, DataError, qu’il faut tester ; le texte du message varie selon l’environnement d’exécution. Firefox et Safari affichent la phrase générique ci-dessus ; Chrome laisse souvent le message vide ou indique la raison (« The imported EC key specifies a different curve than requested ») ; Node affiche « Invalid keyData » ou une raison précise, comme « Named curve mismatch ».

WebCrypto crypto.subtle.importKey — browsers & Node

Ce que cela signifie

importKey (ou unwrapKey) a rejeté les octets de la clé : ils ne peuvent pas être analysés selon le format que vous avez déclaré, ou leur contenu contredit les paramètres de l’algorithme (mauvaise courbe, champs JWK incohérents). C’est l’équivalent WebCrypto de « ces octets ne sont pas la clé que vous annoncez ». L’erreur est levée avant la création de tout objet clé.

Pourquoi cela se produit

• Le nom du format ne correspond pas aux octets

  fréquente

  Importer une clé publique avec le format "pkcs8" (conteneur de clé privée) ou une clé privée avec "spki" est l’inversion classique. Les noms sont peu intuitifs : spki = publique, pkcs8 = privée, raw = point EC nu, jwk = objet JSON.

• Le texte PEM n’a pas été converti en binaire

  fréquente

  importKey prend un ArrayBuffer contenant du DER, pas du texte PEM. Passer la chaîne PEM encodée en UTF-8, ou procéder au décodage base64 sans avoir d’abord retiré les lignes BEGIN/END et les sauts de ligne, produit des octets qui échouent à l’analyse structurelle.

• Courbe incohérente entre la clé et l’algorithme

  occasionnelle

  Un SPKI P-256 importé avec namedCurve: "P-384" (Node signale « Named curve mismatch »), ou une JWK dont le crv ne correspond pas à l’algorithme demandé. Les octets sont corrects ; c’est la déclaration qui est fausse. Firefox ne contrôle pas le cas SPKI à l’importation : le même code peut donc passer dans Firefox et échouer dans Chrome, Safari et Node.

• Point brut invalide

  occasionnelle

  Pour le format "raw", les 65 octets doivent être 0x04 ‖ X ‖ Y, avec (X, Y) effectivement sur la courbe ; Chrome, Firefox et Node rejettent un point corrompu à l’importation, alors que le moteur de Safari l’a importé sans broncher lors de notre test. Les points compressés (33 octets avec un préfixe 0x02/0x03) sont un piège de portabilité dans l’autre sens : Chrome, Firefox et Node les acceptent, Safari les rejette avec cette erreur.

Comment corriger l’erreur

1. 1.

   Convertir correctement PEM → ArrayBuffer

   Retirez les lignes d’armure, décodez le corps en base64 et choisissez le format d’après le libellé PEM : PUBLIC KEY → spki, PRIVATE KEY → pkcs8.

   function pemToArrayBuffer(pem) {
     const b64 = pem.replace(/-----[^-]+-----/g, "").replace(/\s+/g, "");
     return Uint8Array.from(atob(b64), (c) => c.charCodeAt(0)).buffer;
   }
   
   const key = await crypto.subtle.importKey(
     "spki", pemToArrayBuffer(publicKeyPem),
     { name: "ECDSA", namedCurve: "P-256" },
     false, ["verify"],
   );

2. 2.

   Privilégier JWK quand la clé est déjà en JSON

   Les points de terminaison JWKS servent déjà des objets prêts pour WebCrypto : aucune conversion binaire, et le crv accompagne la clé.

   const key = await crypto.subtle.importKey(
     "jwk", jwk,
     { name: "ECDSA", namedCurve: jwk.crv },
     false, ["verify"],
   );

3. 3.

   Vérifier ce que sont réellement les octets

   Collez la clé dans le décodeur de certificats ou le vérificateur de signatures ci-dessous : tous deux analysent SPKI/PKCS#8/JWK localement et indiquent la courbe et le type de clé réels, ce qui révèle généralement l’incohérence immédiatement.

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