Les clés publiques post-quantiques : taille, performance et contraintes d’implémentation
L’un des chocs culturels les plus importants lors de la découverte des algorithmes post-quantiques est la taille des clés et des signatures. Habitués aux 32 octets d’une clé publique Ed25519 ou aux 64 octets d’une signature ECDSA, les ingénieurs tombent des nues en découvrant qu’une clé publique ML-DSA-65 fait 1 952 octets et qu’une signature SPHINCS+-256 peut dépasser 49 000 octets. Ces dimensions ne sont pas anodines : elles impactent les protocoles, les performances réseau, la mémoire et les interfaces utilisateur.
📊 Rappel de l’ordre de grandeur : Une clé publique RSA-2048 fait 256 octets. Une clé publique ML-KEM-768 fait 1 184 octets — soit 4,6 fois plus. Une signature ML-DSA-65 fait 3 309 octets contre 64 octets pour Ed25519 — soit 52 fois plus grande. Ces différences ont des conséquences concrètes sur toute l’architecture.
Tableau comparatif complet des tailles
| Algorithme | Type | Clé publique | Clé privée | Signature/Ciphertext | Niveau NIST |
|---|---|---|---|---|---|
| RSA-2048 (référence) | KEM + Sign | 256 o | 1 218 o | 256 o | — |
| ECC P-256 / Ed25519 (référence) | Sign | 32-64 o | 32 o | 64 o | — |
| ML-KEM-512 (Kyber-512) | KEM | 800 o | 1 632 o | 768 o | 1 |
| ML-KEM-768 (Kyber-768) | KEM | 1 184 o | 2 400 o | 1 088 o | 3 |
| ML-KEM-1024 (Kyber-1024) | KEM | 1 568 o | 3 168 o | 1 568 o | 5 |
| ML-DSA-44 (Dilithium-2) | Sign | 1 312 o | 2 528 o | 2 420 o | 2 |
| ML-DSA-65 (Dilithium-3) | Sign | 1 952 o | 4 000 o | 3 293 o | 3 |
| ML-DSA-87 (Dilithium-5) | Sign | 2 592 o | 4 864 o | 4 595 o | 5 |
| FALCON-512 | Sign | 897 o | 1 281 o | ~666 o (var) | 1 |
| FALCON-1024 | Sign | 1 793 o | 2 305 o | ~1 280 o (var) | 5 |
| SLH-DSA-128s (SPHINCS+) | Sign | 32 o | 64 o | 7 856 o | 1 |
| SLH-DSA-256s (SPHINCS+) | Sign | 64 o | 128 o | 29 792 o | 5 |
Impact sur les protocoles réseau
Certificats X.509 et TLS
Un certificat TLS classique (RSA-2048 + signature CA RSA) fait environ 1,5 Ko. Un certificat X.509 avec ML-DSA-65 dépasse 4 Ko pour la clé publique et la signature. Si la chaîne de certification inclut une CA intermédiaire PQC, le total peut dépasser 10 Ko — contre 4 à 5 Ko actuellement. Cela nécessite souvent plusieurs fragments TCP lors du handshake TLS, augmentant légèrement la latence sur les connexions à haute latence.
DNS et DNSSEC
DNSSEC utilise des signatures RSA ou ECDSA dans les enregistrements DNS. La migration vers ML-DSA ferait exploser la taille des réponses DNS signées au-delà de ce que le protocole UDP standard (512 octets sans extension) peut gérer. DNSSEC PQC nécessitera systématiquement le recours à EDNS0 et TCP, avec des impacts sur les performances des résolveurs récursifs. C’est l’un des protocoles les plus complexes à migrer.
Emails S/MIME et PGP
Les certificats S/MIME PQC augmenteront significativement la taille des emails signés. Pour PGP/GPG, les clés publiques ML-DSA devront être distribuées et stockées dans les keyservers — avec un impact sur les performances de téléchargement des keyservers publics et une augmentation des empreintes mémoire des keyrings.
Benchmarks de performance (ARM Cortex-A72, référence)
| Algorithme | Génération clés | Sign/Encap | Verify/Decap |
|---|---|---|---|
| Ed25519 (référence) | 0.05 ms | 0.08 ms | 0.15 ms |
| ML-KEM-768 | 0.08 ms | 0.09 ms | 0.07 ms |
| ML-DSA-65 | 0.15 ms | 0.18 ms | 0.07 ms |
| FALCON-512 | 8.2 ms (FFT) | 2.1 ms | 0.05 ms |
| SLH-DSA-128s | 2.8 ms | 410 ms | 1.2 ms |
| SLH-DSA-128f (fast) | 0.15 ms | 8.2 ms | 1.8 ms |
SPHINCS+ (SLH-DSA) en mode « small » (s) génère des signatures lentes — plusieurs centaines de millisecondes — ce qui le réserve aux usages où la fréquence de signature est faible (firmware OTA, certificats de longue durée). En mode « fast » (f), la signature est plus rapide au prix de signatures plus grandes.
Stratégies d’optimisation pour les contraintes de taille
Compression et mise en cache des clés publiques
Plusieurs protocoles permettent de référencer une clé publique précédemment transmise plutôt que de la réenvoyer à chaque connexion. Dans TLS 1.3, le mécanisme de session resumption (0-RTT) évite de renégocier les clés à chaque connexion. Pour les API REST avec de nombreuses connexions fréquentes, ce type d’optimisation est crucial.
Choix du niveau de sécurité adapté
Ne pas systématiquement choisir le niveau de sécurité le plus élevé. ML-KEM-768 (niveau 3, ~AES-192) est suffisant pour la grande majorité des usages et représente un bon compromis taille/sécurité. ML-KEM-1024 (niveau 5) n’est nécessaire que pour des données avec des exigences de confidentialité extrêmes sur 30+ ans.
Architecture hybride pour le stockage de clés
Dans les systèmes de gestion des identités (IAM, PKI), stocker les clés PQC nécessite de revoir les schémas de bases de données conçus pour des clés RSA de taille fixe. Prévoyez des champs de taille variable et vérifiez que les limites de taille des colonnes dans vos bases de données permettent les nouvelles clés.
FAQ — Clés post-quantiques et implémentation
SPHINCS+ a de très petites clés publiques (32 octets) mais de très grandes signatures. Quand l’utiliser ?
SPHINCS+ est idéal pour des usages avec peu de signatures et où la taille de la clé publique doit rester minimale : racines de PKI, certificats racine, signatures de firmware. Son avantage majeur est sa sécurité basée uniquement sur des fonctions de hachage — la base de sécurité la plus conservatrice possible. Pour des applications signant des millions de documents par jour, ML-DSA est préférable.
Les nouveaux algorithmes PQC sont-ils plus lents que RSA ?
Dans la plupart des cas, non. ML-KEM est comparable voire plus rapide que ECDH pour l’échange de clés. ML-DSA est plus lent que Ed25519 mais reste très rapide en valeur absolue (moins de 0,2ms par opération sur CPU moderne). FALCON génère des clés lentement mais vérifie très rapidement. L’impact performance principal est la bande passante, pas le CPU.
Comment gérer les limites de taille dans les protocoles legacy ?
Pour les protocoles avec des contraintes strictes de taille (DNSSEC UDP, BLE, LoRaWAN), FALCON offre les signatures les plus compactes parmi les candidats NIST. Pour les protocoles où la taille des messages est fixée par le standard (cartes EMV, NFC), une refonte du protocole sera nécessaire — ce travail est en cours dans les consortiums sectoriels (EMVCo, GlobalPlatform).
Conclusion : concevoir pour la nouvelle réalité des tailles PQC
La migration post-quantique impose une révision de nombreuses hypothèses sur les tailles des objets cryptographiques. Les développeurs, architectes et administrateurs doivent anticiper des certificats 3 à 5 fois plus grands, des signatures 10 à 50 fois plus volumineuses selon l’algorithme, et adapter buffers, bases de données, protocoles et interfaces en conséquence. Cette adaptation technique, bien que non triviale, est parfaitement maîtrisable. L’enjeu est d’intégrer ces contraintes dès la phase de conception plutôt que de les découvrir en production.
Dans une stratégie de cybersécurité moderne, la transition vers la cryptographie post-quantique devient un enjeu critique pour les entreprises. Les organisations doivent anticiper ces évolutions afin de garantir la sécurité de leurs systèmes face aux futures menaces.
Pour approfondir ces sujets, consultez nos ressources sur : la cybersécurité post-quantique, les stratégies d’audit de sécurité, ainsi que les mécanismes de migration cryptographique.