Chiffrement / déchiffrement RSA

Deux nombres premiers et une porte dérobée. Une clé RSA commence par deux grands nombres premiers aléatoires p et q ; leur produit n (le module, d’où le « clé de 2048 bits ») est publié dans la clé publique avec un exposant e (presque toujours 65537). La clé privée est le couple d, l’inverse modulaire de e, calculé à partir de p et q — avec en plus des raccourcis dérivés des nombres premiers qui accélèrent les opérations privées d’un facteur 4.

Chiffrer et signer, c’est la même exponentiation. Chiffrer un bloc de message m revient à calculer m^e mod n ; déchiffrer, c’est c^d mod n. Signer un bloc préformaté avec l’exposant privé et le vérifier avec l’exposant public est la même opération dans l’autre sens. Tout le reste de cette page — OAEP, PSS, PKCS#1 — concerne la mise en forme de ce bloc, afin que l’exponentiation brute ne soit jamais exposée.

Pourquoi c’est lent. Une opération RSA sur une clé de 2048 bits coûte de l’ordre d’un million de fois plus de calcul que le chiffrement d’un bloc avec AES. C’est pourquoi TLS n’utilise RSA (ou ECC) que pour convenir d’une clé AES aléatoire, puis passe à AES. La même règle s’applique à tout ce que vous construisez : RSA pour la clé, AES pour les données.

Taille de clé. La longueur du module est le réglage de sécurité : 1024 bits est « cassé par la politique » (la factorisation est à portée des États), 2048 bits ≈ 112 bits de sécurité symétrique, 3072 bits ≈ 128 bits, 15360 bits équivaudraient à une clé symétrique de 256 bits. Remarque post-quantique : l’algorithme de Shor casse RSA purement et simplement sur un grand ordinateur quantique — une raison de plus de limiter la durée de vie des clés.

Le problème de RSA brut. RSA « de manuel » (m^e mod n sur le message brut) est déterministe et malléable : des messages identiques se chiffrent de la même façon, un attaquant peut multiplier un chiffré par le chiffrement de 2 pour doubler le message clair, et les messages courts tombent par attaque « rencontre au milieu ». Il ne doit jamais être utilisé directement.

Ce que fait OAEP. OAEP (PKCS#1 v2, RFC 8017) mélange le message avec une graine aléatoire via un réseau de Feistel fondé sur un hachage, avant l’exponentiation. Résultat : le chiffrement est randomisé (un même texte clair donne un chiffré différent à chaque fois — lancez l’exemple OAEP deux fois et comparez), toute altération est détectée au déchiffrement, et le message doit tenir dans le module avec de la place pour le hachage — la limite k−2·hashLen−2 indiquée plus haut.

L’étiquette. Une chaîne publique facultative liée au remplissage. Les deux côtés doivent fournir exactement la même étiquette, sinon le déchiffrement échoue — comme l’AAD d’AES-GCM, elle permet de lier le chiffré à un contexte (un nom de fichier, un identifiant d’algorithme). Vide, c’est normal.

Le chiffrement PKCS#1 v1.5 est volontairement absent. Ce remplissage, datant de 1993, n’offre aucune intégrité et laisse fuir de l’information par le comportement sur erreur de déchiffrement (l’attaque de Bleichenbacher de 1998 transforme un oracle de remplissage en déchiffrement complet avec quelques millions de chiffrés forgés ; elle casse encore de vrais systèmes sous le nom de ROBOT, en 2017). WebCrypto refuse de l’implémenter ; cette page aussi.

Signer = hacher, puis remplir, puis exponentier. Les deux schémas hachent le message (SHA-256/384/512 ici), mettent l’empreinte en forme dans un bloc et appliquent l’exposant privé. La vérification remet le bloc en forme avec la clé publique et compare. La différence réside dans la mise en forme :

Lequel choisir. Pour les nouvelles conceptions : PSS. Pour l’interopérabilité avec des certificats existants, des JWT (RS256) ou d’anciens correspondants : v1.5. Les deux sont sûrs en tant que schémas de signature — l’histoire du désastre v1.5 concerne le *chiffrement*, une construction différente malgré le nom proche.

Un PEM n’est que du DER encapsulé en base64. Un fichier PEM est une étiquette suivie du base64 d’une structure DER (ASN.1 binaire). L’étiquette indique quelle structure — et c’est toute la différence entre les quatre formats générés par cette page :

Même clé, enveloppes différentes. Les quatre zones ci-dessus, après la génération, contiennent la même paire de clés — SPKI et PKCS#1 public contiennent les mêmes n et e ; PKCS#8 et PKCS#1 privé contiennent les mêmes valeurs privées. Cette page convertit entre eux sans perte dans le navigateur (son autotest vérifie les allers-retours). Confondre les formats est la cause la plus fréquente des erreurs « clé invalide » lorsqu’on colle des clés d’un outil à l’autre.

Les PEM chiffrés (-----BEGIN ENCRYPTED PRIVATE KEY-----) sont du PKCS#8 avec une couche de chiffrement fondée sur un mot de passe. Cette page ne les accepte pas — déchiffrez-les d’abord hors ligne (openssl pkcs8 -in enc.pem -out plain.pem).

• Chiffrer des données volumineuses avec RSA. Au-delà de la limite de taille stricte d’OAEP, c’est absurdement lent. Le schéma est le suivant : générer une clé AES aléatoire, chiffrer cette clé avec RSA-OAEP, chiffrer les données avec AES-GCM, puis envoyer les deux parties.
• Livrer la clé privée parce que « c’est un test ». Les clés d’exemple intégrées aux vecteurs de cette page sont publiées volontairement — elles ne peuvent signer que des données de test. Vos clés, elles, ne sont pas comme cela.
• Vérifier avec la clé privée. Cela « marche » en général mathématiquement, et certains outils le permettent, mais distribuer une clé privée aux vérificateurs annule tout le modèle. Vérifiez avec la clé publique (cette page l’impose).
• Comparer les signatures octet pour octet pour vérifier du code. PSS (et OAEP) sont randomisés : deux exécutions correctes produisent des sorties différentes. Comparez en vérifiant, non en égalité — seules les signatures v1.5 sont déterministes.
• Des clés de 1024 bits « parce qu’elles sont plus rapides ». Elles sont aussi à portée d’une factorisation bien financée. L’argument de la vitesse a disparu avec le chiffrement hybride : RSA ne s’exécute qu’une fois par session, et non par octet.
• Coder en dur une longueur de sel différente de la longueur du hachage pour PSS. Le vérificateur doit être d’accord ; la longueur du hachage (le choix de cette page et le -sigopt rsa_pss_saltlen:32 d’OpenSSL) est la valeur par défaut interopérable.

Pourquoi mon déchiffrement a-t-il échoué avec « mauvaise clé, mauvais hachage ou chiffré altéré » ? Le déchiffrement OAEP échoue si l’une de ces conditions est vraie : ce n’est pas la clé privée correspondante, le hachage diffère du côté chiffrement, l’étiquette diffère, ou un octet du chiffré a changé. Le message d’erreur est volontairement identique dans tous les cas — révéler quelle vérification a échoué constituerait en soi une fuite d’oracle de remplissage.

Peut-on obtenir la clé publique à partir de la clé privée ? Oui — les formats privés contiennent aussi n et e. Cette page affiche les deux après la génération ; OpenSSL le fait avec openssl pkey -in priv.pem -pubout.

Pourquoi 65537 comme exposant ? C’est un nombre premier, qui ne comporte que deux bits à 1 (exponentiation rapide), et il est assez grand pour éviter les attaques à faible exposant qui touchent e=3. C’est le choix standard depuis les années 1990 ; un exposant « bizarre » signale en général une clé faible ou non standard.

RSA est-il mort à cause des ordinateurs quantiques ? Pas encore — aucune machine ne peut exécuter l’algorithme de Shor sur un module de 2048 bits. Mais les données devant rester secrètes au-delà des années 2030 font déjà l’objet d’une migration ; les schémas hybrides post-quantiques sont la réponse d’ingénierie.

Et openssl rsautl ? C’est l’ancêtre déprécié de pkeyutl. Il utilise par défaut le remplissage de chiffrement v1.5 — une raison de plus de l’avoir retiré.