Les entrées sont la clé publique, le message (ou son condensat), la signature et l’algorithme avec ses paramètres ; la sortie vaut « valide » ou « invalide ». Un vérificateur strict rejette aussi les entrées mal formées : DER non minimal, r ou s hors de 1…n−1, un S EdDSA qui n’est pas inférieur à l’ordre du groupe, des signatures brutes de mauvaise longueur, des points qui ne sont pas sur la courbe et des clés du mauvais type.
La plupart des erreurs « invalid signature » en production ne sont pas cryptographiques : d’autres octets ont été signés (JSON resérialisé, espaces ou fins de ligne modifiés, saut de ligne final manquant), une autre fonction de hachage a été utilisée, une signature DER est arrivée à un vérificateur qui attend le format brut ou inversement, la courbe ou la longueur du sel PSS diffère, ou la mauvaise clé a été choisie. Vérifiez chaque entrée séparément ; le vérificateur de signatures indique la courbe, la fonction de hachage et l’encodage qu’il a utilisés.
Règles de sécurité qui préviennent de vraies failles : fixez l’algorithme côté vérificateur au lieu de le lire dans le message (alg du JWT, RFC 8725 §3.1) ; vérifiez avant d’analyser la charge utile ou d’agir en fonction de son contenu ; vérifiez le lien entre clé et identité (validation du chemin de certification, kid du JWKS, known_hosts) ; et, pour les systèmes à consensus, figez un seul ensemble de règles de vérification, car les bibliothèques divergent sur des cas limites comme les vérifications EdDSA avec cofacteur.