Contexte et historique
Depuis 2016, les auteurs de la communauté cryptographique recommandent d’ajouter les algorithmes post‑quantique (PQ) aux protocoles basés sur les courbes elliptiques (ECC) plutôt que de les remplacer entièrement. L’auteur du billet rappelle ses prises de position publiques : recommandation ECC+PQ en 2016, critique du concours NIST PQ en 2018, et mise en garde contre le remplacement complet d’ECC en 2024. En juin 2026, il publie une étude quantifiant le nombre de clés ML‑DSA susceptibles d’être compromises à cause de bugs logiciels, et souligne que le même phénomène est amplifié pour ML‑KEM, dont le volume de clés est nettement supérieur.
Bilan des vulnérabilités logicielles
Le texte recense plusieurs incidents concrets. Depuis 2017, le code de référence de Dilithium (ML‑DSA) a présenté un bug majeur, tandis que les implémentations officielles de Kyber/ML‑KEM ont subi deux fuites de timing – KyberSlash1 et KyberSlash2 – détectées entre 2017 et fin 2023. En 2024, une nouvelle fuite nommée Clangover a été révélée, liée à l’interaction entre le code ML‑KEM et les optimisations du compilateur Clang. Le 24 juin 2026, alors qu’un vote était organisé pour supprimer ECC, le jour suivant le CVE‑2026‑6330 a été publié, signalant une faille dans WolfSSL liée à ML‑KEM. D’autres CVE en 2026 concernent libcrux, libgcrypt, RustCrypto et WolfSSL, montrant que les bibliothèques majeures sont déjà touchées.
Les tests SUPERCOP, appliqués à 5 036 implémentations couvrant 1 475 primitives (en moyenne quelques implémentations par primitive), détectent de nombreux défauts. Cependant, la plupart des bibliothèques de production ne soumettent pas leurs implémentations à ces tests et utilisent des suites de validation nettement plus laxistes. La fréquence des vulnérabilités est élevée : 1 sur 8 des failles signalées dans les bibliothèques cryptographiques est directement liée à un problème de mise en œuvre, et les bugs de timing sont souvent exploitables.
Analyse de l’impact de la suppression d’ECC
Supprimer la couche ECC élimine le seul mécanisme de secours en cas de compromission d’un algorithme PQ. Les attaques qui exploitent un bug dans ML‑DSA ou ML‑KEM deviennent alors catastrophiques, car aucune clé alternative ne peut être utilisée sans interrompre le service. Le nombre de clés ML‑KEM en circulation dépasse largement celui des clés ML‑DSA, ce qui multiplie le vecteur d’exposition. De plus, la vérification formelle, bien que théoriquement capable de couvrir l’ensemble du code, nécessite près de trois ans d’effort collectif et ne garantit pas la correction de routines critiques comme le rejet‑sampling AVX2. En pratique, la plupart des implémentations restent non vérifiées, augmentant la probabilité de bugs non détectés.
Perspectives et recommandations
Face à ces constats, la stratégie la plus prudente consiste à conserver la couche ECC tout en intégrant les algorithmes PQ, afin de limiter l’impact d’un éventuel bug PQ. Les acteurs doivent renforcer leurs processus de test : étendre l’usage de SUPERCOP à toutes les implémentations, automatiser la détection de fuites de timing et investir dans la vérification formelle ciblée sur les parties les plus sensibles. Enfin, la communauté doit publier rapidement les correctifs dès la découverte de vulnérabilités, comme le montre la réaction aux KyberSlash et aux CVE récents, afin de réduire la fenêtre d’exploitation. Ces mesures permettent de profiter des avantages de la cryptographie post‑quantique sans sacrifier la résilience offerte par l’ECC.
