Signature (cryptographique)

Une signature cryptographique est une courte chaîne d’octets qui prouve qu’un message spécifique a été produit par quelqu’un en possession d’une clé privée, sans révéler cette clé privée. La vérification de la signature ne nécessite que la clé publique correspondante (pour les algorithmes asymétriques) ou le secret partagé (pour les symétriques).

Le flux asymétrique de base (avec RSA, ECDSA ou Ed25519) :

1. Le signataire hache le message (typiquement SHA-256).
2. Le signataire chiffre le hachage avec sa clé privée. Résultat : la signature.
3. Le vérificateur hache le message reçu avec la même fonction de hachage.
4. Le vérificateur déchiffre la signature avec la clé publique. Résultat : un hachage.
5. Si les deux hachages correspondent, la signature est valide et le message n’a pas été falsifié.

Les signatures symétriques (HMAC) utilisent un secret partagé plutôt qu’une paire de clés. Le signataire et le vérificateur ont tous deux le secret ; les deux calculent HMAC(secret, message) et comparent. Plus rapide qu’asymétrique ; utile seulement lorsque les parties se font déjà confiance (on ne veut pas HMAC pour une vérification par des tiers, car quiconque détient le secret peut forger des signatures).

Où les signatures apparaissent dans la pile de travail : les jetons JWT (le troisième segment), les chaînes de certificats TLS, la signature de code (notarisation Apple, Authenticode Windows), les commits et tags Git (signés GPG), les transactions Bitcoin, la distribution de paquets logiciels (gestionnaires de paquets Linux, formules Homebrew). Chaque contexte associe la signature à un algorithme spécifique et à une gestion des clés ; le primitif sous-jacent est le même.

Signatures post-quantiques et la migration à venir : RSA, ECDSA et Ed25519 sont tous vulnérables à l’algorithme de Shor sur un ordinateur quantique suffisamment grand. Le programme de cryptographie post-quantique du NIST a sélectionné trois schémas de signature en 2024 — ML-DSA (Dilithium), SLH-DSA (SPHINCS+) et FN-DSA (Falcon) — comme remplacements standardisés. Des machines quantiques réelles suffisamment grandes pour casser RSA 2048 bits n’existent pas encore, mais les systèmes cryptographiques à longue durée de vie (certificats racine, clés de signature de code pour les logiciels archivés, sauvegardes chiffrées) migrent préventivement. Les signatures hybrides (classiques + post-quantiques) sont la stratégie de transition typique. Référence : NIST — Standardisation de la cryptographie post-quantique.

Exemple concret

Signer le message "transfer $100 to alice" avec une clé Ed25519. Première étape : hacher le message avec SHA-512, produisant un condensé de 64 octets. Deuxième étape : l’algorithme Ed25519 combine ce condensé avec le scalaire de la clé privée de 32 octets via la génération de nonce déterministe (RFC 8032), produisant une signature de 64 octets (R, s). Troisième étape : quiconque possède la clé publique de 32 octets peut vérifier en recalculant le point de courbe et en vérifiant que l’équation sB = R + H(R, A, M) · A est satisfaite. La signature est courte (64 octets) et la vérification est rapide (~50 µs sur un processeur moderne). Surtout, Ed25519 est déterministe — signer deux fois le même message avec la même clé produit des octets identiques.

Quand et pourquoi cela est important

L’utilisation incorrecte des signatures est la vulnérabilité cryptographique la plus courante après le hachage des mots de passe. Les erreurs classiques : signer un blob JSON dont la forme canonique est ambiguë (réorganiser les clés modifie les octets et casse la signature, ou pire, permet à un attaquant de créer deux messages sémantiquement différents avec les mêmes octets), utiliser un nonce ECDSA déterministe répété sur deux messages (ce qui divulgue la clé privée — c’est ainsi que la clé maître de la PlayStation 3 a été extraite en 2010), et accepter des signatures sans vérifier que le champ d’algorithme correspond au champ attendu (la classe de vulnérabilité « alg : none » dans les premières bibliothèques JWT). Les règles défensives : fixer l’algorithme au niveau du vérificateur, canonicaliser le message avant le hachage (utiliser COSE/JOSE plutôt que JSON ad hoc), préférer Ed25519 à ECDSA pour le nouveau code, et stocker les clés privées dans des HSM ou des enclaves matérielles lorsque le modèle de menace le justifie. Référence : RFC 8032 — Algorithme de signature numérique sur courbes d’Edwards (EdDSA).