RSA expliqué en 2026 : guide complet de l'algorithme

RSA est l'algorithme de chiffrement asymétrique historique le plus déployé, inventé en 1977 par Ron Rivest, Adi Shamir et Leonard Adleman au MIT. Sa sécurité repose sur la difficulté mathématique de factoriser le produit de deux grands nombres premiers (le problème RSA). En 2026, RSA reste massivement présent dans l'écosystème (certificats TLS CA racines, SSH keys historiques, JWT signing sur systèmes legacy, PGP classique, code signing) mais est déprécié pour les nouveaux projets au profit de ECC (Elliptic Curve Cryptography, Curve25519/Ed25519/X25519) qui offre la même sécurité avec des clés 10x plus petites et une performance 10-200x supérieure. Les tailles de clés acceptables sont RSA-2048 minimum (déprécié vers 2030-2032), RSA-3072 pour nouveaux projets RSA (112-128 bits de sécurité), RSA-4096 pour long-terme. Les utilisations correctes nécessitent les paddings modernes : RSA-OAEP pour le chiffrement (remplace PKCS#1 v1.5 vulnérable à Bleichenbacher depuis 1998), RSA-PSS pour les signatures. Le risque quantique (Shor's algorithm, 1994) justifie la migration progressive vers algorithmes post-quantum (ML-KEM FIPS 203 + ML-DSA FIPS 204, août 2024) pour données sensibles long-terme. Cet article détaille l'histoire de RSA, le principe mathématique simplifié, la génération de clés, le chiffrement avec padding OAEP, la signature avec PSS, les tailles de clés NIST 2026, la comparaison RSA vs ECC, les attaques historiques (Bleichenbacher, ROCA, Common Modulus, small exponent), la menace quantique Shor, les cas d'usage qui restent pertinents en 2026, et la stratégie de migration vers ECC puis PQC.

Histoire : de MIT à standard mondial

RSA naît au MIT en 1977. Histoire riche en 50 ans.

1977 — Publication du paper

Ron Rivest, Adi Shamir et Leonard Adleman, chercheurs au MIT, publient "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems" dans Communications of the ACM (février 1978). L'article décrit le premier algorithme de cryptographie à clé publique pratique, un an après l'idée théorique de Diffie-Hellman (novembre 1976).

1983-2000 — Brevet et controverse

RSA est breveté aux États-Unis (US Patent 4,405,829) en septembre 1983. Le brevet expire en septembre 2000. Pendant 17 ans, l'usage commercial de RSA aux États-Unis nécessite licence auprès de RSA Security Inc. (entreprise fondée par les 3 inventeurs). Controverses historiques sur la portée et l'application.

Le 6 septembre 2000, deux semaines avant expiration officielle, RSA Security libère l'algorithme dans le domaine public. Adoption massive accélère.

1991 — PGP adopte RSA

Phil Zimmermann choisit RSA pour PGP 1.0 (1991). Controverse RSA brevet vs PGP libre = une des luttes juridiques historiques de la cryptographie.

1993 — PKCS#1 v1.5 standardisé

RSA Laboratories publie PKCS#1 v1.5 en 1993, format standard pour RSA encryption et signatures. Largement déployé malgré découverte ultérieure de faiblesses (Bleichenbacher 1998).

1998 — Bleichenbacher attack

Daniel Bleichenbacher publie "Chosen Ciphertext Attacks Against Protocols Based on the RSA Encryption Standard PKCS #1" au congrès CRYPTO '98. Montre que PKCS#1 v1.5 padding permet de récupérer le plaintext via timing oracle. Impact durable : tous les protocoles utilisant RSA PKCS#1 v1.5 pour chiffrement sont affectés. Variantes (Manger 2001, ROBOT 2017) continuent d'exploiter le pattern.

2001 — PKCS#1 v2.1 avec OAEP et PSS

RSA Labs publie PKCS#1 v2.1 avec les paddings modernes RSA-OAEP (Bellare-Rogaway 1994) et RSA-PSS (Bellare-Rogaway 1996) prouvés sûrs. Standardisation IETF via RFC 3447 (2003).

2007 — PKCS#1 v2.2 (RFC 8017 en 2016)

Mise à jour mineure. RFC 8017 (novembre 2016) reste la référence PKCS#1 en 2026.

2010-2020 — Transition progressive vers ECC

Migration massive vers ECC démarre avec Chrome forçant ECDHE préféré (2011+), Let's Encrypt supportant ECDSA (2018+), OpenSSH moderne préférant Ed25519.

2024 — Standards post-quantum publiés

NIST publie FIPS 203 (ML-KEM, ex-Kyber), FIPS 204 (ML-DSA, ex-Dilithium) en août 2024. RSA commence son déclin long-terme inévitable face au risque quantique.

Principe mathématique simplifié

RSA repose sur la théorie des nombres, spécifiquement la difficulté de factoriser grands nombres premiers. Explication sans plonger dans les maths avancées.

Génération de clé RSA

1. Choisir deux grands nombres premiers p et q (typiquement 1024 bits chacun pour RSA-2048).
2. Calculer modulus n = p × q (la clé publique contient n, ~2048 bits).
3. Calculer fonction d'Euler φ(n) = (p-1)(q-1).
4. Choisir exposant public e (typiquement e=65537, standard).
5. Calculer exposant privé d tel que e × d ≡ 1 (mod φ(n)).
6. Clé publique = (n, e).
7. Clé privée = (n, d) ou équivalent (p, q, d, etc.).

Les nombres p et q doivent être conservés secrets (connaître p et q permet de factoriser n, donc calculer d).

Chiffrement RSA (textbook, non sécurisé)

Pour chiffrer un message m avec la clé publique (n, e) :

c = m^e mod n

Le ciphertext c ne peut être déchiffré que par celui qui possède d :

m = c^d mod n

Le problème : cette version "textbook" est vulnérable à de nombreuses attaques (chosen-ciphertext, small exponent, etc.). Ne jamais utiliser en production.

Chiffrement RSA sécurisé avec OAEP

En pratique, toujours utiliser RSA-OAEP (Optimal Asymmetric Encryption Padding, Bellare-Rogaway 1994) :

1. Padding OAEP applique des transformations au message m (ajout randomness, hash, mixing).
2. Le message paddé est ensuite chiffré par RSA textbook.
3. OAEP est prouvé sûr contre attaques chosen-ciphertext (IND-CCA2 secure).

RSA-OAEP gère un message de taille max environ (n - 2 × hash_output_length - 2) octets. Pour RSA-2048 + SHA-256 : max 190 octets utilisables.

Signature RSA (textbook, non sécurisé)

Pour signer un message m avec la clé privée d :

signature = hash(m)^d mod n

Vérification avec clé publique e :

hash(m) ?= signature^e mod n

Signature RSA sécurisée avec PSS

En pratique : RSA-PSS (Probabilistic Signature Scheme, Bellare-Rogaway 1996) :

• Ajoute un salt aléatoire à chaque signature (signatures non-déterministes).
• Prouvé sûr dans random oracle model.
• Préféré à RSA PKCS#1 v1.5 pour signatures en 2026.

RSA PKCS#1 v1.5 pour signatures reste acceptable (vs chiffrement où il est vulnérable), mais RSA-PSS est la recommandation moderne.

Tailles de clés RSA et niveaux de sécurité

Cible sécurité vs taille de clé selon NIST SP 800-57 (2020, révisé 2024).

Durée de vie des clés RSA

NIST recommande périodes de validité :

• RSA-2048 : acceptable jusqu'à 2030-2032 pour protéger données sensibles aujourd'hui.
• RSA-3072 : acceptable jusqu'à 2040+ pour protéger données long-terme.
• RSA-4096 : acceptable jusqu'à 2050+ classique (mais vulnerable quantique).

Au-delà, migration post-quantum obligatoire pour données long-terme (harvest now decrypt later).

RSA vs ECC : comparaison détaillée

Trois dimensions clés.

Équivalence sécurité

ECC offre la même sécurité avec des clés 10x plus petites.

Performance (benchmarks 2026 sur CPU moderne Intel ou Apple M3)

ECC est 200-800x plus rapide que RSA selon l'opération. Impact critique à grande échelle (serveurs TLS traitant millions de connexions par jour).

Tailles d'artefacts

Pour systèmes contraints (IoT, embedded, smart cards), ECC est le seul choix pratique. Tailles RSA sont prohibitives.

Attaque quantique

RSA et ECC sont tous deux vulnérables aux ordinateurs quantiques via Shor's algorithm. La migration post-quantum affecte les deux familles.

Attaques historiques sur RSA

Six attaques célèbres à connaître pour éviter les pièges.

1. Bleichenbacher 1998 (PKCS#1 v1.5 padding oracle)

Daniel Bleichenbacher découvre en 1998 que PKCS#1 v1.5 padding permet à un attaquant ayant accès à un oracle de décryption (serveur qui révèle si un ciphertext est bien-formé ou pas) de récupérer le plaintext en environ 1 million de requêtes.

Exploits publics :

• 1998 : affect des serveurs SSL/TLS.
• 2001 (Manger) : variante améliorée.
• 2012 (Fischlin) : variante.
• 2017 (ROBOT - Return Of Bleichenbacher's Oracle Threat) : 19 ans après, F5 BIG-IP, Citrix, Cisco encore vulnérables.

Défense : jamais utiliser PKCS#1 v1.5 pour chiffrement. Utiliser RSA-OAEP.

2. ROCA (CVE-2017-15361)

Publiée octobre 2017 par des chercheurs de Masaryk University. Faiblesse dans la génération de clés RSA par bibliothèques RSALib d'Infineon (TPM, smart cards, Yubikey 4 series).

Les clés générées ont une structure mathématique spécifique qui permet leur factorisation en quelques heures via Coppersmith's attack, au lieu des millions d'années de sécurité théorique.

Impact massif :

• Yubikey 4 series rappelés.
• 760 000 cartes d'identité estoniennes impactées, gouvernement force remplacement.
• 400 000 cartes d'identité slovaques impactées.
• Millions de TPM Infineon affectés.

Défense : audit cryptographique des générateurs de clés, standards FIPS 140-3 renforcés.

3. Common Modulus Attack

Si deux utilisateurs partagent le même modulus n mais avec des exposants e différents, et le même message m est chiffré pour les deux, un attaquant peut récupérer m en combinant les deux ciphertexts.

Défense : chaque paire de clés RSA doit avoir un modulus n unique. Jamais partager n entre utilisateurs.

4. Small Exponent Attack (Hastad's attack)

Si un exposant public e est petit (typiquement e=3) et le même message m est chiffré pour e+ destinataires différents (sans padding), l'attaquant peut récupérer m via théorème des restes chinois.

Défense : utiliser e=65537 (standard) ou e grand. Toujours utiliser padding OAEP qui randomise chaque ciphertext.

5. Wiener Attack (small d)

Si l'exposant privé d est trop petit (d < n^0.25 environ), l'attaquant peut le récupérer via fraction continue.

Défense : générer d correctement (suivre standard PKCS#1 v2.2). Les bibliothèques modernes ne produisent pas cette faiblesse.

6. Faulty CRT (Bellcore attack)

Si une erreur matérielle (glitch, injection de faute) se produit pendant la signature RSA utilisant Chinese Remainder Theorem, un attaquant peut factoriser n.

Défense : vérification de signature après génération (détecte les erreurs). Implémentations HSM qualifiées font cela systématiquement.

Menace quantique : Shor's algorithm

Peter Shor publie en 1994 un algorithme quantique qui factorise les entiers en temps polynomial. Impact direct sur RSA.

Principe simplifié

Shor utilise la transformée de Fourier quantique pour trouver la période d'une fonction liée au modulus n. Connaissant cette période, la factorisation de n se fait en temps polynomial.

Conséquence : un ordinateur quantique suffisamment grand peut factoriser RSA-2048 en heures ou jours, vs millions d'années pour un ordinateur classique.

Combien de qubits faut-il ?

Estimations 2023-2024 pour casser RSA-2048 :

• 4 100 qubits logiques stables (qubits sans erreur).
• Environ 20 millions de qubits physiques (qubits réels bruités qu'il faut combiner pour faire des logiques stables) selon le rapport 2023 du Global Risk Institute.

Ordinateurs quantiques actuels (2026) :

• IBM Condor (2023) : 1121 qubits physiques.
• IBM Osprey (2022) : 433 qubits.
• Google Sycamore : 53 qubits.
• Various others : principalement recherche.

Les qubits actuels sont loin de ce qui serait nécessaire (manque d'ordre de magnitude ~4).

Timeline de menace quantique

Estimations varient selon sources (Global Risk Institute, IBM, expert polls). Consensus général : migration post-quantum doit démarrer 2025-2030 pour écosystème complet d'ici 2035-2040.

Risque "Harvest Now Decrypt Later"

Adversaires d'état-nation avancés (Chine, Russie, États-Unis, autres) interceptent et stockent massivement le trafic chiffré RSA/ECDH aujourd'hui. Quand l'ordinateur quantique sera disponible (estimé 2035-2045), ils pourront déchiffrer rétroactivement.

Conséquence : toute donnée sensible long-terme (brevets, recherche, secrets commerciaux, données de santé, informations défense) devrait être protégée dès 2025-2027 par des algorithmes post-quantum (ML-KEM hybride).

Quand utiliser RSA encore en 2026

Cinq cas où RSA reste pertinent.

1. Compatibilité legacy inévitable

Intégration avec ancien partenaire B2B, système legacy qui ne supporte pas ECC. Maintenir RSA-2048 minimum, passer RSA-3072 si possible.

2. Certificats CA racines

Root CAs historiques utilisent souvent RSA-4096 pour stabilité long-terme 20-30 ans. DigiCert, Entrust, GlobalSign maintiennent Root CAs RSA en parallèle de nouvelles ECDSA. Transition progressive.

3. HSM / TPM avec support FIPS 140-2/140-3

Certains HSM ne supportent pas encore Curve25519 avec validation FIPS. RSA-2048+ avec PSS reste standard valide. HSM modernes supportent aussi ECDSA P-256/P-384 validés.

4. Environnements régulés banking legacy

Standards SWIFT, certains systèmes interbancaires historiques, SEPA legacy exigent RSA. Migration progressive en cours mais processus long.

5. Code signing legacy

Certains écosystèmes (Windows Authenticode, Java JAR signing) ont supporté RSA longtemps en standard. Migration vers ECDSA ou post-quantum en cours.

Quand éviter RSA en 2026

Quatre cas où RSA est sous-optimal.

1. Nouveaux projets cloud-native

Microservices internes, APIs modernes, containers signing. Ed25519 + X25519 partout. Pas de justification RSA dans ces stacks modernes.

2. Applications mobiles et IoT

Tailles clés RSA prohibitives, performance médiocre sur CPU contraint. ECC est le seul choix pratique.

3. Volume TLS élevé

Serveurs traitant >10k connexions par seconde : RSA devient goulot CPU. ECDSA P-256 ou Ed25519 libèrent ~200x les ressources pour autant de transactions.

4. Données sensibles long-terme

Si les données doivent rester confidentielles 10-20 ans (santé, défense, R&D), considérer immédiatement hybride post-quantum (X25519MLKEM768) pour résister au futur quantum.

Implémentations correctes 2026

Recommandations pratiques par langage et bibliothèque.

Python avec cryptography

from cryptography.hazmat.primitives import hashes, serialization
from cryptography.hazmat.primitives.asymmetric import rsa, padding
 
# Génération clé RSA-3072 (moderne minimum 2026)
private_key = rsa.generate_private_key(
    public_exponent=65537,
    key_size=3072,  # minimum recommandé 2026
)
public_key = private_key.public_key()
 
# Chiffrement avec RSA-OAEP (obligatoire)
message = b"Secret message"
ciphertext = public_key.encrypt(
    message,
    padding.OAEP(
        mgf=padding.MGF1(algorithm=hashes.SHA256()),
        algorithm=hashes.SHA256(),
        label=None,
    ),
)
 
# Déchiffrement
plaintext = private_key.decrypt(
    ciphertext,
    padding.OAEP(
        mgf=padding.MGF1(algorithm=hashes.SHA256()),
        algorithm=hashes.SHA256(),
        label=None,
    ),
)
 
# Signature avec RSA-PSS (recommandé)
signature = private_key.sign(
    message,
    padding.PSS(
        mgf=padding.MGF1(hashes.SHA256()),
        salt_length=padding.PSS.MAX_LENGTH,
    ),
    hashes.SHA256(),
)
 
# Vérification signature
public_key.verify(
    signature,
    message,
    padding.PSS(
        mgf=padding.MGF1(hashes.SHA256()),
        salt_length=padding.PSS.MAX_LENGTH,
    ),
    hashes.SHA256(),
)

Node.js avec crypto stdlib

const crypto = require('crypto');
 
// Génération paire RSA-3072
const { publicKey, privateKey } = crypto.generateKeyPairSync('rsa', {
  modulusLength: 3072,  // minimum recommandé 2026
  publicExponent: 65537,
  publicKeyEncoding: { type: 'spki', format: 'pem' },
  privateKeyEncoding: { type: 'pkcs8', format: 'pem' },
});
 
// Chiffrement avec RSA-OAEP (obligatoire)
const message = Buffer.from('Secret message');
const encrypted = crypto.publicEncrypt(
  {
    key: publicKey,
    padding: crypto.constants.RSA_PKCS1_OAEP_PADDING,
    oaepHash: 'sha256',
  },
  message
);
 
// Déchiffrement
const decrypted = crypto.privateDecrypt(
  {
    key: privateKey,
    padding: crypto.constants.RSA_PKCS1_OAEP_PADDING,
    oaepHash: 'sha256',
  },
  encrypted
);
 
// Signature avec RSA-PSS
const sign = crypto.createSign('RSA-SHA256');
sign.update(message);
const signature = sign.sign({
  key: privateKey,
  padding: crypto.constants.RSA_PKCS1_PSS_PADDING,
  saltLength: crypto.constants.RSA_PSS_SALTLEN_DIGEST,
});
 
// Vérification
const verify = crypto.createVerify('RSA-SHA256');
verify.update(message);
const isValid = verify.verify(
  {
    key: publicKey,
    padding: crypto.constants.RSA_PKCS1_PSS_PADDING,
    saltLength: crypto.constants.RSA_PSS_SALTLEN_DIGEST,
  },
  signature
);

Go avec crypto/rsa stdlib

package main
 
import (
    "crypto"
    "crypto/rand"
    "crypto/rsa"
    "crypto/sha256"
    "fmt"
)
 
func main() {
    // Génération clé RSA-3072
    privateKey, err := rsa.GenerateKey(rand.Reader, 3072)
    if err != nil {
        panic(err)
    }
    publicKey := &privateKey.PublicKey
    
    message := []byte("Secret message")
    
    // Chiffrement RSA-OAEP
    ciphertext, err := rsa.EncryptOAEP(
        sha256.New(), rand.Reader, publicKey, message, nil,
    )
    if err != nil {
        panic(err)
    }
    
    // Déchiffrement
    plaintext, err := rsa.DecryptOAEP(
        sha256.New(), rand.Reader, privateKey, ciphertext, nil,
    )
    if err != nil {
        panic(err)
    }
    fmt.Printf("Decrypted: %s\n", plaintext)
    
    // Signature RSA-PSS
    hashed := sha256.Sum256(message)
    signature, err := rsa.SignPSS(
        rand.Reader, privateKey, crypto.SHA256, hashed[:], nil,
    )
    if err != nil {
        panic(err)
    }
    
    // Vérification
    err = rsa.VerifyPSS(publicKey, crypto.SHA256, hashed[:], signature, nil)
    if err != nil {
        fmt.Println("Invalid signature")
    } else {
        fmt.Println("Valid signature")
    }
}

Bonnes pratiques transversales

1. Taille minimum RSA-3072 pour nouveaux projets, RSA-2048 uniquement pour legacy.
2. Padding OAEP pour chiffrement, jamais PKCS#1 v1.5 pour encryption.
3. Padding PSS pour signatures, PKCS#1 v1.5 acceptable si legacy imposé.
4. Hash SHA-256 minimum, SHA-384 ou SHA-512 pour alignement niveau sécurité RSA-3072 ou RSA-4096.
5. PRNG cryptographique (os.urandom, crypto.randomBytes, rand.Reader).
6. HSM pour clés critiques : AWS KMS, Azure Key Vault, HashiCorp Vault Transit, YubiHSM.
7. Rotation périodique des clés RSA (2-5 ans selon criticité).

Outils 2026

Génération de clés

• openssl genrsa — standard pour génération CLI.
• ssh-keygen -t rsa -b 3072 — pour clés SSH RSA.
• Bibliothèques cryptography, crypto/rsa Go, node:crypto — génération programmatique.
• AWS KMS CreateKey(KeySpec=RSA_3072) — génération managed sans extraction.

Inspection

# Lire une clé RSA
openssl rsa -in private.key -text -noout
 
# Lire un certificat RSA
openssl x509 -in cert.pem -text -noout
 
# Vérifier la taille de clé
openssl rsa -in private.key -modulus -noout | wc -c

Conversion formats

• PEM (base64) ↔ DER (binary) : openssl rsa -in key.pem -outform DER.
• PKCS#1 ↔ PKCS#8 : openssl pkcs8 -in key.pkcs1 -topk8 -out key.pkcs8.

Audit

• SSL Labs : détecte RSA-1024, RSA avec PKCS#1 v1.5 chiffrement.
• testssl.sh : audit cipher suites RSA.
• sslyze : audit TLS avec focus algorithmes.

Points clés à retenir

• RSA (Rivest-Shamir-Adleman, 1977) est l'algorithme asymétrique historique, sécurité basée sur la difficulté de factoriser grands nombres premiers. Brevet expiré 2000, standards RFC 8017 PKCS#1 v2.2.
• Tailles 2026 : RSA-1024 strictement déprécié (2014), RSA-2048 legacy acceptable jusqu'à 2030-2032, RSA-3072 minimum nouveau projet (128 bits sécurité), RSA-4096 long-terme.
• Paddings modernes obligatoires : RSA-OAEP pour chiffrement (remplace PKCS#1 v1.5 vulnérable Bleichenbacher), RSA-PSS pour signatures.
• Attaques historiques marquantes : Bleichenbacher 1998 (padding oracle PKCS#1 v1.5), ROCA CVE-2017-15361 (Infineon TPM, 760K cartes estoniennes), Common Modulus, Small Exponent, Wiener, Bellcore CRT.
• Migration 2025-2030 recommandée : nouveaux projets en ECC (Ed25519, X25519, 10-200x plus rapide), hybrides post-quantum (X25519MLKEM768) pour données sensibles long-terme.

Pour aller plus loin

• Chiffrement asymétrique expliqué - panorama incluant RSA, ECC et post-quantum.
• Qu'est-ce qu'un certificat TLS - les certificats utilisant RSA ou ECDSA.
• TLS expliqué simplement - comment RSA est utilisé dans le handshake TLS (en déclin vs ECDHE).
• Qu'est-ce que la cryptographie - vue d'ensemble de la discipline dont RSA est une pierre angulaire historique.