ToolActToolAct

Outil de Chiffrement et Déchiffrement RSA

Chiffrement RSA asymétrique en ligne avec génération de paire de clés, chiffrement par clé publique et déchiffrement par clé privée

Gestion des clés

Clé publique
Clé privée
Entrée
Caractères: 0
Octets: 0
Sortie
Caractères: 0
Octets: 0

Qu'est-ce que le chiffrement RSA ?

RSA (Rivest-Shamir-Adleman) est le premier algorithme de chiffrement asymétrique largement utilisé, inventé en 1977 par trois mathématiciens du MIT. Contrairement aux algorithmes symétriques comme AES, RSA utilise une paire de clés : une clé publique pour chiffrer et une clé privée pour déchiffrer. La clé publique peut être partagée ouvertement tandis que la clé privée doit rester secrète. La sécurité de RSA repose sur la difficulté mathématique de la factorisation de grands entiers. Des clés de 2048 bits ou plus sont recommandées. RSA est utilisé dans les poignées de main HTTPS/TLS, les signatures numériques, le chiffrement d'e-mails (PGP/GPG) et les transactions blockchain. Cet outil utilise l'API Web Crypto native du navigateur.

Comment utiliser

Mode d'emploi

  1. Sélectionnez la taille de clé (2048 bits ou plus recommandé)
  2. Sélectionnez le schéma de remplissage (OAEP recommandé pour une meilleure sécurité)
  3. Sélectionnez l'algorithme de hachage (SHA-256 recommandé)
  4. Cliquez sur « Générer la paire de clés » pour créer les clés publique et privée
  5. Pour le chiffrement : collez la clé publique dans la zone prévue, saisissez le texte en clair ; le texte chiffré est généré automatiquement
  6. Pour le déchiffrement : collez la clé privée dans la zone prévue, saisissez le texte chiffré ; le texte en clair est généré automatiquement
  7. Copiez les résultats ou cliquez sur « Inverser » pour échanger l'entrée et la sortie

Guide des paramètres

  • Utilisez RSA-OAEP avec SHA-256 ou supérieur pour les nouveaux tests de chiffrement ; PKCS#1 v1.5 ne doit servir qu'à la compatibilité avec les anciens systèmes
  • RSA ne peut chiffrer que de petits volumes. Pour des données plus volumineuses, chiffrez une clé AES aléatoire avec RSA et utilisez AES pour le contenu réel
  • Ne partagez jamais les clés privées dans les discussions, tickets, captures d'écran ou journaux partagés. Les clés publiques peuvent être diffusées, mais les clés privées doivent rester secrètes

Cas d’utilisation

Générer des paires de clés RSA-OAEP dans le navigateurChoisissez une longueur de module de 512, 1024, 2048, 3072 ou 4096 bits et un algorithme de hachage SHA-1, SHA-256, SHA-384 ou SHA-512, puis générez des clés publique et privée exportables en PEM via Web Crypto. La paire de clés reste dans l’onglet du navigateur et est exportée en blocs PEM SPKI (publique) et PKCS#8 (privée) — pratique pour concevoir un test d’interopérabilité sans provisionner un serveur de clés.
Chiffrer et déchiffrer de courts payloads texteCollez une clé publique pour chiffrer du texte en clair en Base64 ou hexadécimal, ou collez une clé privée pour déchiffrer le texte chiffré dans le format sélectionné. Les compteurs d’octets en entrée et en sortie aident à identifier les problèmes de taille de payload, car RSA-OAEP(SHA-256) sur une clé 2048 bits ne peut encapsuler qu’environ 190 octets de texte en clair. La clé privée et le message restent dans l’onglet local pendant toute l’opération.
Tester la gestion des clés sans outils externesCopiez les blocs PEM publique ou privée, échangez les panneaux lors de l’expérimentation et basculez le mode chiffrement/déchiffrement tout en restant sur une seule page. Utile pour apprendre la sémantique RSA-OAEP, vérifier l’interopérabilité avec openssl et les prototypes locaux où le matériel clé ne doit pas quitter la machine.
Choisir le hachage OAEP pour les vérifications d’interopérabilitéBasculez entre SHA-1, SHA-256, SHA-384 et SHA-512 dans les paramètres OAEP pour correspondre au hachage utilisé par l’application pair. Un hachage incompatible provoque un échec de déchiffrement avec un « OperationError » générique de Web Crypto ; vérifier l’appariement ici fait gagner du temps de débogage lors du câblage des clés entre le crypto de Node, le cryptography de Python ou les services javax.crypto de Java.
Identifier les limites de taille de payload avant le chiffrementRSA-OAEP ne peut chiffrer que les messages plus courts que le module de la clé moins 2*hashLen - 2 octets de remplissage, les tentatives sur des blocs de plusieurs kilo-octets lèveront donc un InvalidAccessError. Utilisez le compteur d’octets d’entrée et la longueur de sortie du texte chiffré (qui égale le module de la clé en octets pour OAEP) pour confirmer que le test reste sous la limite, puis passez les gros volumes à AES avec des clés de session encapsulées par RSA.

Principe technique

RSA est le système cryptographique à clé publique Rivest-Shamir-Adleman de 1977. La génération de clés choisit deux grands nombres premiers aléatoires p et q, définit le module n = p · q, calcule l'indicatrice d'Euler φ(n) = (p-1)(q-1), choisit un exposant public e premier avec φ(n) (e = 65537 = 2^16 + 1 est le choix par défaut de facto car son faible poids de Hamming accélère l'exponentiation modulaire), et dérive l'exposant privé d ≡ e^-1 (mod φ(n)) via l'algorithme d'Euclide étendu. Le chiffrement est c = m^e mod n ; le déchiffrement est m = c^d mod n. La sécurité repose sur la difficulté conjecturée de la factorisation de n en p et q pour n suffisamment grand. Le RSA brut est déterministe et malléable, donc tout déploiement réel enveloppe le message dans un schéma de remplissage. RSA-OAEP, défini dans RFC 8017 (PKCS#1 v2.2) avec une fonction de génération de masque MGF1 sur SHA-256 (ou SHA-1/384/512), fournit une sécurité sémantique : le même texte clair produit un texte chiffré différent à chaque appel, et la vérification d'intégrité du remplissage bloque les attaques par texte chiffré choisi. L'ancien remplissage PKCS#1 v1.5 reste courant pour la rétrocompatibilité mais est vulnérable à l'attaque par oracle de Bleichenbacher (un million de messages). Pour les signatures, RSASSA-PSS est préféré à PKCS#1 v1.5 sign pour les mêmes raisons. Le choix de la taille de clé est contraint à la fois par les performances et les derniers records de factorisation. Le NIST SP 800-57 impose ≥ 2048 bits aujourd'hui et ≥ 3072 bits après 2030. La cryptographie sur courbe elliptique atteint la sécurité équivalente à RSA 3072 avec seulement 256 bits (NIST P-256, Curve25519), ce qui explique pourquoi la plupart des nouveaux déploiements TLS préfèrent ECDHE + ECDSA. RSA-OAEP sur une clé 2048 bits ne peut envelopper au maximum que ⌊taille_clé/8⌋ − 2·taille_hash − 2 octets de texte clair (≈ 190 octets pour SHA-256), donc les systèmes de production n'utilisent RSA que pour envelopper une clé de session symétrique fraîche et laissent AES-GCM transporter la charge utile — le schéma hybride derrière chaque poignée de main TLS. Dans le navigateur, l'API Web Crypto (window.crypto.subtle) gère la génération, l'importation, le chiffrement et le déchiffrement de clés avec PEM/DER (SPKI pour la clé publique, PKCS#8 pour la clé privée) ou JWK comme formats d'échange.

  • Mathématiques : choisir les premiers p, q ; n = p·q ; φ(n) = (p-1)(q-1) ; choisir e (typiquement 65537 = 2^16+1) ; calculer d = e^-1 mod φ(n) ; chiffrer c = m^e mod n ; déchiffrer m = c^d mod n.
  • Remplissage : RSA-OAEP selon RFC 8017 (PKCS#1 v2.2) avec MGF1+SHA-256 pour le nouveau code ; PKCS#1 v1.5 uniquement pour l'interopérabilité legacy, sujet à Bleichenbacher (CVE-2017-13099 et al).
  • Tailles de clé : NIST SP 800-57 fixe le minimum à 2048 bits aujourd'hui et 3072 bits à partir de 2030 ; le RSA 1024 bits est considéré cassé et le RSA 4096 bits coûte nettement plus de CPU.
  • Limite de charge utile : RSA-OAEP peut envelopper au maximum ⌊k/8⌋ − 2·taille_hash − 2 octets (≈ 190 octets pour 2048 bits + SHA-256) ; les données plus volumineuses utilisent RSA pour envelopper une clé de session AES-GCM.
  • Force comparable : RSA 3072 ≈ ECC 256 (NIST P-256 ou Curve25519) à environ 128 bits de sécurité symétrique ; ECC l'emporte sur la taille de clé et la vitesse de signature, RSA l'emporte sur la vérification.
  • API navigateur et formats : window.crypto.subtle.generateKey('RSA-OAEP') ; export en SPKI PEM (publique) et PKCS#8 PEM (privée), ou JWK ; les clés privées ne doivent jamais quitter l'environnement local en texte clair.

Exemples

Chiffrement de base

1. Générer une paire de clés 2048 bits
2. Copier la clé publique
3. Saisir le texte clair : Hello, RSA!
4. Sélectionner OAEP + SHA-256
5. Sortie : texte chiffré encodé en Base64

RFC : RFC 8017 (PKCS#1 v2.2) définit le schéma de chiffrement RSAES-OAEP

Flux de travail typique

Expéditeur :
1. Obtenir la clé publique du destinataire
2. Chiffrer le message avec la clé publique
3. Envoyer le texte chiffré

Destinataire :
1. Déchiffrer avec la clé privée
2. Lire le message original

Note : le chiffrement RSA assure la confidentialité ; pour l'authenticité, le combiner avec des signatures RSA (RSASSA-PSS dans la RFC 8017)

Chiffrement hybride (RSA + AES)

RSA est destiné aux petites données (comme les clés de session)
Pour de grandes données, utiliser le chiffrement hybride :
1. Générer une clé AES-256 aléatoire
2. RSA chiffre la clé AES (max ~190 octets avec OAEP-SHA256)
3. AES-GCM chiffre les données réelles
4. Envoyer la clé chiffrée RSA + texte chiffré AES + IV + tag d'authentification

Cela combine la distribution de clés de RSA avec la rapidité d'AES et constitue le schéma standard dans TLS, PGP et S/MIME.
RFC : la section 7.1 de la RFC 8017 traite de RSAES-OAEP pour l'encapsulation de clés

FAQ

Quelle taille de clé dois-je générer ?

RSA-2048 est le minimum pratique aujourd'hui et c'est ce que les certificats TLS utilisent depuis des années. RSA-3072 est la valeur par défaut prudente actuelle selon NIST SP 800-57. RSA-4096 est excessif pour la plupart des usages (beaucoup plus lent) mais approprié pour les clés de signature de longue durée. RSA-1024 est cassé par convention et ne devrait être généré pour rien de nouveau.

Clé publique vs clé privée — laquelle chiffre et laquelle déchiffre ?

Pour la confidentialité : chiffrez avec la clé publique, déchiffrez avec la clé privée. N'importe qui peut chiffrer un message à votre intention ; seul le détenteur de la clé privée peut le lire. Pour les signatures, c'est l'inverse : signez avec la clé privée, vérifiez avec la clé publique.

Pourquoi le chiffrement du même texte deux fois donne-t-il un texte chiffré différent ?

RSA-OAEP (le schéma de remplissage recommandé) ajoute du caractère aléatoire de sorte que des textes en clair identiques produisent des textes chiffrés différents. C'est intentionnel — cela empêche les attaques par texte chiffré choisi. RSA sans remplissage (RSA classique) est déterministe et non sécurisé ; ne l'utilisez pas.

Pourquoi RSA est-il tellement plus lent qu'AES ?

RSA effectue une exponentiation modulaire sur de grands entiers ; AES effectue des opérations bit à bit de taille fixe sur un petit bloc. Un chiffrement RSA 2048 bits est des milliers de fois plus lent qu'un chiffrement AES-128. En pratique, vous utilisez RSA uniquement pour envelopper une petite clé de session AES, puis chiffrez la charge utile réelle avec AES.

Quelle est la quantité maximale de données que je peux chiffrer avec une seule clé RSA ?

RSA-OAEP avec SHA-256 laisse environ (taille_clé_en_bits / 8 - 66) octets disponibles par chiffrement : 190 octets pour une clé 2048 bits, 318 octets pour 3072, 446 octets pour 4096. Pour chiffrer plus, chiffrez une clé AES avec RSA et les données avec AES.

La génération de clés est-elle aléatoire et locale ?

Oui. La génération de clés utilise crypto.subtle.generateKey de la Web Crypto API, qui s'amorce à partir du CSPRNG du système d'exploitation. Les clés ne quittent jamais votre navigateur. Actualisez la page pour supprimer une clé et en générer une nouvelle ; ne collez pas une clé privée de production dans une page web.

RSA est-il résistant au quantique ?

Non. Un ordinateur quantique suffisamment puissant exécutant l'algorithme de Shor casse RSA pour toute taille de clé pratique. NIST a normalisé des alternatives post-quantiques (ML-KEM, ML-DSA en 2024). Pour les données qui doivent rester confidentielles pendant des décennies, planifiez une migration ; pour les sessions TLS de courte durée, RSA reste acceptable.