RSA-2048 vs RSA-4096 : taille, vitesse, échéance de 2030

RSA-2048 vs RSA-4096, c’est la question de taille de clé la plus fréquente en matière de PKI. RSA-2048 est le minimum autorisé pour les certificats de confiance publique et se situe au niveau de sécurité de 112 bits du NIST ; RSA-4096 se situe bien au-delà de 128 bits. Le coût d’une clé plus grande se retrouve dans le temps de signature, le temps de génération de clés et chaque signature transmise sur le réseau : la bonne réponse dépend donc de la fréquence à laquelle une clé signe et de la durée pendant laquelle elle doit rester digne de confiance.

Vue d’ensemble

Mesures effectuées avec openssl speed rsa2048 rsa3072 rsa4096 sur un cœur d’un Apple M4 Max.

Marge de sécurité

La sécurité de RSA repose sur la difficulté de factoriser le module avec le crible algébrique général (GNFS), dont le coût croît de façon sous-exponentielle avec la taille de clé : c’est pourquoi les clés RSA doivent grandir bien plus vite que les clés sur courbe elliptique. La publication NIST SP 800-57 Part 1 fait correspondre RSA à 2048 bits à une sécurité de 112 bits, 3072 bits à 128 et 7680 à 192 ; elle ne donne aucune ligne pour 4096 bits, qui se situe entre 128 et 192. Le plus grand des nombres du challenge RSA factorisés publiquement compte 829 bits (RSA-250, 2020), bien loin de 2048.

L’échéance qui compte davantage est quantique. L’algorithme de Shor factorise les trois tailles en temps polynomial sur un grand ordinateur quantique tolérant aux fautes, et doubler la clé double à peu près le nombre de qubits nécessaires et allonge modérément le temps d’exécution ; cela ne change pas l’issue. Selon l’estimation de Craig Gidney (2025), factoriser RSA-2048 prendrait moins d’une semaine avec moins d’un million de qubits bruités. Le NIST IR 8547 (un projet initial soumis à consultation publique) propose donc la même date de fin, 2035, pour toutes les tailles de RSA, RSA-2048 étant en outre déprécié après 2030 en raison de son niveau classique de 112 bits. RSA-4096 élargit votre marge classique ; il ne repousse pas votre échéance post-quantique.

Performances

Le coût des opérations à clé privée croît à peu près comme le cube de la taille du module, celui des opérations à clé publique comme son carré :

openssl speed -seconds 2 rsa2048 rsa3072 rsa4096

                   sign    verify    encrypt   decrypt   sign/s verify/s  encr./s  decr./s
rsa  2048 bits 0.000334s 0.000009s 0.000009s 0.000339s   2994.9 114178.1 108513.6   2950.3
rsa  3072 bits 0.000957s 0.000019s 0.000019s 0.000965s   1044.7  53948.7  52312.0   1036.7
rsa  4096 bits 0.002117s 0.000032s 0.000032s 0.002121s    472.4  31522.3  30870.7    471.6

Pour un serveur TLS qui signe une fois par handshake complet, passer de 2048 à 4096 multiplie ce coût par six environ. Pour une AC racine qui signe quelques certificats intermédiaires par décennie, le coût est sans importance. La génération de clés ralentit aussi fortement, car elle doit trouver deux grands nombres premiers : environ 26 ms en moyenne pour 2048 bits sur cette machine, contre un quart de seconde pour 4096, avec une longue traîne, ce qui compte sur les petits appareils et dans les tests qui génèrent des clés à répétition.

La vérification reste peu coûteuse à toutes les tailles, car l’exposant public est petit (65 537) : c’est pourquoi RSA garde sa place dans des chaînes de certificats vérifiées des milliards de fois.

Limites matérielles et protocolaires

Les limites de taille viennent de l’environnement plus que de RSA lui-même :

• Cartes à puce et jetons matériels : de nombreuses cartes PIV et d’anciens jetons de sécurité ne prennent en charge que RSA-2048 ; les appareils plus récents ajoutent 3072 et 4096. Vérifiez avant de commander du matériel.
• HSM et KMS cloud : les trois tailles sont standard (AWS KMS propose RSA_2048, RSA_3072 et RSA_4096), mais la tarification à l’opération et les limites de débit rendent 4096 nettement plus coûteux à grande échelle.
• DNS : une clé DKIM de 4096 bits occupe 736 caractères base64 et doit être découpée en plusieurs chaînes TXT ; certains fournisseurs DNS et d’anciens résolveurs gèrent mal les enregistrements longs. Les zones DNSSEC qui utilisent RSA-4096 produisent de grandes réponses qui peuvent nécessiter TCP.
• Chaînes de certificats : chaque certificat RSA-4096 ajoute environ 512 octets de signature et 550 octets de clé, contre quelques centaines d’octets pour ECDSA, ce qui compte pour les clients aux ressources limitées.

Lequel choisir, et quand

• Nouveaux certificats de serveur TLS : ECDSA P-256 en priorité ; s’il faut du RSA, RSA-2048 est encore accepté par tous les clients et toutes les AC, mais RSA-3072 offre une marge au-delà de 2030.
• AC racines et AC intermédiaires à longue durée de vie : RSA-4096 (ou ECDSA P-384) ; le coût de signature est négligeable et les durées de vie sont longues. L’ISRG Root X1 de Let’s Encrypt est en RSA-4096, tandis que ses AC intermédiaires RSA sont en RSA-2048.
• Signature de JWT (RS256) : RSA-2048 est courant et autorisé (la RFC 7518 exige au moins 2048 bits), RSA-3072 pour les nouvelles clés ; envisagez plutôt ES256.
• Clés SSH : préférez Ed25519 ; en RSA, au moins 3072.
• Clés de signature de code et de documents : RSA-3072 ou 4096, selon l’offre de l’AC et la durée de vie attendue de la signature, avec un horodatage en plus.
• Matériel contraint : ce qu’il prend en charge, généralement RSA-2048, avec un plan de remplacement documenté.

Notes de migration

Changer de taille de clé RSA implique une nouvelle paire de clés et, pour les certificats, un nouveau certificat.

1. Inventoriez les clés par taille : certificats (openssl x509 -noout -text), JWKS (longueur de n), clés SSH (ssh-keygen -l), enregistrements DKIM et descripteurs de clés des HSM. Les clés RSA-2048 dont la durée de vie dépasse 2030 sont les premières à remplacer.
2. Générez les nouvelles clés sur place : openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072, ou l’équivalent du HSM ; évitez d’exporter des clés pour en changer la taille.
3. Faites coexister anciennes et nouvelles clés : publiez les deux dans le JWKS avec des valeurs kid distinctes, ajoutez le nouveau sélecteur DKIM avant de basculer, servez les deux clés d’hôte SSH pendant la transition.
4. Testez les systèmes consommateurs avec la clé plus grande : les tampons de taille fixe, les limites des enregistrements DNS et les piles TLS embarquées sont les causes d’échec habituelles.
5. Profitez de la rotation pour reconsidérer l’algorithme : si tous les consommateurs prennent en charge ECDSA ou EdDSA, abandonner complètement RSA est généralement le meilleur investissement, et les signatures post-quantiques exigeront une nouvelle rotation avant 2035.

Références

• NIST SP 800-57 Part 1 Rev. 5, tableau 2
• NIST IR 8547, projet initial soumis à consultation publique
• FIPS 186-5 §5, RSA
• RFC 8017, PKCS #1 v2.2
• RFC 7518 §3.3, taille de clé RSA minimale pour JWS
• Gidney (2025), factoriser RSA-2048 avec moins d’un million de qubits bruités
• Baseline Requirements du CA/Browser Forum, §6.1.5