Vérificateur de signature Ed25519 | Vérifie les signatures EdDSA du RFC 8032 dans le navigateur
Colle une clé publique Ed25519, le message et la signature : l'API Web Crypto du navigateur exécute la vérification EdDSA du RFC 8032 et indique si la signature est valide pour cette clé et ce message. Trois encodages (hex, base64, base64url) permettent de coller des valeurs issues de JWT, de clés SSH ou de transactions blockchain telles quelles.
💡 À propos de cet outil
Ed25519 est l'EdDSA sur la forme d'Edwards tordue de Curve25519. Ses clés publiques de 32 octets et ses signatures de 64 octets, ajoutées à une vérification rapide, en ont fait le choix par défaut un peu partout : l'algorithme EdDSA des JWT, les clés ssh-ed25519 d'OpenSSH, ou la signature de transactions sur Solana, Cosmos et NEAR.
Les questions de débogage reviennent toujours. Le serveur a-t-il vraiment signé cette charge utile ? La clé est arrivée en base64 mais la documentation parle de hex — laquelle est correcte ? Une mise à jour de bibliothèque a discrètement changé la sortie et verify renvoie désormais faux. L'objectif est d'isoler le problème sans écrire un script Node ou un extrait Python à la volée.
L'outil décode chaque entrée en Uint8Array selon son format, contrôle les longueurs (32 octets pour la clé, 64 pour la signature), importe la clé avec crypto.subtle.importKey puis appelle crypto.subtle.verify. Chaque champ possède son propre sélecteur, donc une clé en hex avec une signature en base64 ne pose aucun souci. La clé, le message et la signature restent dans ton navigateur et ne sont jamais envoyés à un serveur.
🧐 Questions fréquentes
Ai-je besoin de la clé privée ? Non. La vérification ne nécessite que la clé publique. Il n'y a ni champ de clé privée ni fonction de signature : cet outil vérifie, il ne crée pas de nouvelles signatures.
Dois-je coller un message déjà haché ? Non. Ed25519 (PureEdDSA) hache le message entier en interne lors de la signature et de la vérification ; colle donc le message brut tel qu'il a été signé. Un condensé pré-calculé donnera Invalide.
Que se passe-t-il si je choisis le mauvais encodage ? Si une valeur ne se décode pas, une erreur rouge s'affiche, et si la clé ou la signature ne fait pas 32 / 64 octets, un avertissement de longueur apparaît. Revérifie le sélecteur de format de chaque champ (hex, base64 ou base64url).
Mon navigateur indique qu'Ed25519 n'est pas pris en charge.
Web Crypto Ed25519 est disponible dans Chrome 137+, Safari 17+ et Firefox 130+. Sur des moteurs plus anciens, crypto.subtle.importKey échoue, et l'outil signale l'absence de prise en charge. Essaie un navigateur à jour.
Peut-il vérifier des signatures Ed448 ou secp256k1 ? Non. Cet outil est réservé à Ed25519. Les signatures sur d'autres courbes sont hors périmètre.
📚 Le saviez-vous
L'une des raisons du succès rapide d'Ed25519 est la signature déterministe. ECDSA exige un nonce aléatoire neuf à chaque signature, et des nonces biaisés ou réutilisés ont déjà révélé des clés privées lors d'incidents réels. Ed25519 dérive cette valeur de la clé privée et du message : la même clé et le même message produisent toujours la même signature, et toute cette famille de bogues disparaît.
Le nombre « 25519 » vient du nombre premier 2²⁵⁵ − 19, qui nomme aussi Curve25519. Une clé publique tient en 32 octets parce qu'un point de la courbe se compresse en une seule coordonnée plus un bit de signe : la mathématique élégante derrière le fait qu'une clé ssh-ed25519 tienne sur une seule ligne.