RSA-2048 après 2030 : ce que propose le projet NIST IR 8547

NIST IR 8547 est un projet initial soumis à consultation publique (initial public draft), publié le 12 novembre 2024 et toujours à l'état de projet en septembre 2026. Il propose de déprécier, après 2030, les algorithmes à clé publique vulnérables au quantique offrant une sécurité de 112 bits, RSA-2048 en étant l'exemple type, et d'interdire tous les algorithmes à clé publique vulnérables au quantique après 2035. Ces deux dates sont des propositions figurant dans un projet, et non des exigences finalisées du NIST, même si elles sont souvent citées comme si elles étaient déjà en vigueur.

Ce qu'est NIST IR 8547

NIST IR 8547 a été publié sous forme de projet initial soumis à consultation publique le 12 novembre 2024 (csrc.nist.gov/pubs/ir/8547/ipd). Un projet initial est la première version diffusée pour recueillir les commentaires du public. Il peut être révisé, réorganisé ou voir ses dates ajustées avant la parution d'une éventuelle version finale. En septembre 2026, aucune version finale n'a été publiée.

Il doit être lu conjointement avec NIST SP 800-131A Rev. 3, qui est lui aussi un projet initial soumis à consultation publique (21 octobre 2024, csrc.nist.gov/pubs/sp/800/131/a/r3/ipd). SP 800-131A est la publication qui porte les règles de transition des algorithmes pour l'usage fédéral américain, et ces règles se répercutent sur ce que les modules cryptographiques validés sont autorisés à faire : c'est pourquoi éditeurs et auditeurs suivent de près les deux documents. Tous deux sont des projets. Aucun n'est une loi, et aucun ne s'impose à lui seul à une entreprise privée.

Déprécié et interdit sont des termes techniques précis

Dans le vocabulaire de transition du NIST, ces deux mots ne sont pas synonymes. Déprécié (deprecated) signifie qu'un algorithme reste approuvé mais que son usage est déconseillé et comporte un risque reconnu. Interdit (disallowed) signifie qu'il n'est plus approuvé pour l'usage décrit. Le projet propose le premier statut après 2030 et le second après 2035, et il définit les termes qu'il emploie : lisez le projet lui-même avant de citer une définition dans une politique interne.

Pourquoi le seuil de 112 bits tombe sur RSA-2048

Le projet raisonne en niveaux de sécurité plutôt qu'en tailles de clé, et RSA-2048 est l'exemple qu'il donne pour le niveau de 112 bits. La conséquence pratique est qu'une transition formulée ainsi va bien au-delà de RSA. ECDSA, EdDSA, ECDH, Diffie-Hellman sur corps finis et DSA sont tous cassés par l'algorithme de Shor sur un ordinateur quantique suffisamment puissant, quelle que soit la taille de clé. DSA n'est d'ailleurs déjà plus approuvé pour la génération de signatures selon FIPS 186-5, qui n'autorise que la vérification des signatures existantes.

Une clé RSA plus longue n'est pas une migration

Passer de RSA-2048 à un module plus grand augmente le niveau de sécurité classique, et c'est la raison pour laquelle le BSI TR-02102-1 demande un RSA d'au moins 3000 bits. Cela ne change rien face à l'algorithme de Shor. La réponse quantique est une autre famille d'algorithmes : ML-KEM (mécanisme d'encapsulation de clé, normalisé dans FIPS 203 le 13 août 2024) pour l'établissement de clé, et ML-DSA ou SLH-DSA pour les signatures. Consultez la page ML-KEM pour les jeux de paramètres normalisés et les groupes TLS qui les portent.

L'ordre des travaux compte ici. Harvest now, decrypt later (HNDL, « collecter maintenant, déchiffrer plus tard ») signifie qu'un adversaire enregistre aujourd'hui du trafic chiffré pour le déchiffrer plus tard : les sessions enregistrées ne sont protégées que par l'échange de clés. C'est pourquoi l'échange de clés hybride passe en premier, et pourquoi les certificats et les signatures peuvent migrer ensuite. Un parc qui signe encore avec des certificats RSA-2048 mais négocie un groupe hybride ML-KEM est en meilleure position que l'inverse.

Comment le projet se compare au BSI, à l'UE et aux autres

La fenêtre 2030 à 2035 n'est pas propre au NIST, mais la portée juridique de chaque document diffère nettement. Le tableau ci-dessous range chaque source dans sa propre catégorie. La liste complète et datée, avec les sources primaires de chaque jalon, figure dans notre article de référence sur les échéances de migration post-quantique.

Deux points méritent d'être énoncés clairement. Premièrement, les seules obligations fermement datées de ce tableau s'appliquent aux agences fédérales américaines ; le BSI TR-02102-1 est une directive technique (le document lui-même), et la feuille de route de l'UE constitue des orientations coordonnées adressées aux États membres. L'ANSSI indique que ses recommandations PQC ne sont pas encore des obligations réglementaires en dehors de son périmètre réglementé (qualification de produits et certains opérateurs régulés), où l'hybridation est obligatoire ; elle vise à exiger la PQC pour les produits entrant en qualification à partir de 2027 et considère qu'après 2030, acheter des produits sans PQC ne sera pas raisonnable, ce qui relève de la recommandation. Deuxièmement, tous ces textes convergent vers les deux mêmes premières étapes, l'inventaire et l'échange de clés hybride : c'est pourquoi le sort du projet ne change pas ce qu'il faut faire dès maintenant.

Que faire tant que le projet reste un projet

Cet article est fourni à titre d'information et ne constitue pas un conseil juridique. La séquence ci-dessous relève du travail d'ingénierie ordinaire, et elle reste la même que la version finale de NIST IR 8547 maintienne, décale ou assouplisse les dates proposées.

1. Savoir où se trouve RSA-2048. Inventoriez les clés, certificats et configurations TLS, avec taille de clé, algorithme de signature, propriétaire et date d'expiration. L'exigence 12.3.3 de PCI DSS v4.0.1 impose que les suites de chiffrement et protocoles utilisés soient documentés et revus au moins tous les 12 mois, y compris une stratégie documentée face à l'évolution anticipée des vulnérabilités cryptographiques ; elle est obligatoire depuis le 31 mars 2025.
2. Rédiger la clause d'agilité, pas l'algorithme. Le RTS DORA, Règlement délégué (UE) 2024/1774 de la Commission, Art. 6, exige littéralement une politique de chiffrement et de contrôles cryptographiques comprenant des dispositions pour mettre à jour ou changer de technologie cryptographique en fonction des évolutions de la cryptanalyse, et l'Art. 7 exige une gestion des clés sur l'ensemble de leur cycle de vie ainsi qu'un registre des certificats pour les actifs TIC soutenant des fonctions critiques ou importantes. Consultez la page DORA pour le périmètre exact. Notre interprétation, et non une exigence littérale : une politique qui désigne un déclencheur de revue (par exemple la publication d'un document de transition final du NIST) permet plus facilement de satisfaire l'Art. 6 qu'une politique qui cite RSA-2048 et une date.
3. Activer l'échange de clés hybride là où les sessions sont enregistrées. En priorité la terminaison TLS et VPN exposée au public, puisque c'est la cible de HNDL.
4. Limiter consciemment la durée de vie des certificats. Un certificat RSA-2048 émis aujourd'hui ne devrait pas être prévu pour rester valide au-delà de la fenêtre qui importe à votre secteur.

Commencez par des vérifications en lecture seule. Ces commandes indiquent ce qui est réellement déployé plutôt que ce qu'affirme la documentation :

openssl x509 -in server.crt -noout -subject -enddate
openssl x509 -in server.crt -noout -text | grep -E "Public-Key|Signature Algorithm"
openssl s_client -connect example.com:443 -tls1_3 -groups X25519MLKEM768 </dev/null

Les groupes TLS ML-KEM nécessitent OpenSSL 3.5 ou une version ultérieure : un client plus ancien rejettera donc le nom du groupe, et non le serveur. Lorsque vous passerez aux modifications de configuration, conservez un repli classique (listez X25519 après X25519MLKEM768) et testez en préproduction avant la production.

Étape suivante : mesurer, puis planifier

Avant de citer une date issue d'un projet dans une note au conseil d'administration, vérifiez les faits sur votre propre périmètre : vos serveurs négocient-ils déjà un groupe hybride ML-KEM, quelles versions de TLS acceptent-ils, et quelles tailles de clé et quels algorithmes de signature figurent dans la chaîne de certificats. Vous pouvez analyser votre domaine avec PQC Status gratuitement, puis utiliser le résultat comme première ligne de l'inventaire décrit ci-dessus. Une analyse décrit uniquement la configuration TLS visible de l'extérieur : ce n'est ni une certification ni une attestation de conformité.