Leonard Adleman a contribué à créer RSA, un système à clé publique qui a rendu possibles HTTPS, la banque en ligne et les mises à jour signées. Découvrez son fonctionnement et pourquoi c'est important.
Quand on dit qu'on « fait confiance » à un site ou à un service en ligne, on entend généralement trois choses pratiques :
RSA est devenu célèbre parce qu'il a aidé à rendre ces promesses possibles à l'échelle d'Internet.
Vous avez ressenti l'impact de RSA même si vous n'avez jamais entendu son nom. Il est étroitement lié à la façon dont :
Le fil conducteur est la confiance sans avoir à connaître personnellement (ou à partager des secrets à l'avance avec) chaque serveur ou éditeur.
Cet article garde les explications simples : pas de mathématiques lourdes et pas besoin de formation en informatique. Nous nous concentrerons sur le point de vue « pourquoi ça marche » au quotidien.
RSA a popularisé une approche puissante : au lieu d'un secret partagé, on utilise une clé publique à diffuser et une clé privée à garder secrète. Cette séparation permet de protéger la confidentialité et de prouver l'identité entre des parties qui ne se connaissent pas à l'avance.
Leonard Adleman est le « A » de RSA, aux côtés de Ron Rivest et Adi Shamir. Alors que Rivest et Shamir sont souvent crédités pour la construction de base, la contribution d'Adleman a été essentielle : il a aidé à transformer le système en quelque chose non seulement ingénieux, mais convaincant — un algorithme que la communauté pouvait analyser, tester et en qui elle pouvait avoir confiance.
Une grande part du rôle d'Adleman a été de soumettre l'idée à des tests exigeants. En cryptographie, un schéma n'est pas précieux parce qu'il semble plausible ; il l'est parce qu'il résiste à des attaques et à un examen approfondi. Adleman a travaillé à la validation, affiné les hypothèses et contribué à la formulation initiale expliquant pourquoi RSA devrait être difficile à casser.
Tout aussi important, il a aidé à traduire « ça pourrait marcher » en « voici un cryptosystème que d'autres peuvent évaluer ». Cette clarté — rendre la conception compréhensible pour la communauté de recherche — a été cruciale pour l'adoption.
Avant RSA, la communication sécurisée dépendait généralement du partage préalable d'une clé secrète. Cette approche fonctionne dans des groupes fermés, mais ne scale pas quand des inconnus doivent communiquer en toute sécurité (par exemple, un acheteur et un site rencontrés pour la première fois).
RSA a changé cette histoire en popularisant un système à clé publique pratique : vous pouvez publier une clé pour que d'autres l'utilisent, tout en gardant une clé privée secrète.
L'influence de RSA va au-delà d'un seul algorithme. Il a rendu deux essentiels d'Internet réalisables à grande échelle :
Ces idées sont à la base de la normalisation de HTTPS, de la banque en ligne et des mises à jour logicielles signées.
Avant RSA, la communication sécurisée signifiait surtout chiffrement par secret partagé : les deux parties devaient posséder la même clé secrète à l'avance. Cela marche pour un petit groupe, mais c'est impraticable pour un service public utilisé par des millions.
Si chaque client doit avoir une clé secrète unique pour parler à une banque, la banque doit en générer, livrer, stocker, faire tourner et protéger un nombre énorme de secrets. Le plus compliqué n'est pas la mathématique — c'est la coordination.
Comment livrer la clé en toute sécurité au départ ? L'envoyer par courrier est lent et risqué. La dire au téléphone peut être intercepté ou manipulé. L'envoyer sur Internet ruine l'objectif, puisque le canal est précisément ce que vous voulez sécuriser.
Imaginez deux inconnus — vous et un magasin en ligne — qui ne se sont jamais rencontrés. Vous voulez envoyer un paiement en toute sécurité. Avec le chiffrement par secret partagé, vous auriez besoin d'une clé privée que vous connaissez déjà tous les deux. Mais vous ne la connaissez pas.
La percée de RSA est d'autoriser une communication sécurisée sans partage préalable d'un secret. À la place, vous publiez une clé (clé publique) que n'importe qui peut utiliser pour protéger un message à votre intention, et vous gardez une clé privée que vous seul détenez.
Même si vous pouvez chiffrer des messages, il faut aussi savoir à qui vous chiffrez. Sinon, un attaquant peut usurper la banque ou le magasin, vous tromper pour utiliser sa clé et lire ou altérer silencieusement tout.
C'est pourquoi la communication sécurisée a besoin de deux propriétés :
RSA a aidé à rendre les deux possibles, jetant les bases de la confiance en ligne à grande échelle.
La cryptographie à clé publique est une idée simple aux grandes conséquences : vous pouvez verrouiller quelque chose pour quelqu'un sans avoir convenu d'un secret partagé au préalable. C'est le changement fondamental que RSA a rendu pratique.
Considérez une clé publique comme un verrou que vous êtes heureux de distribuer à tous. Les gens peuvent l'utiliser pour protéger un message pour vous — ou (dans les systèmes de signature) pour vérifier qu'un contenu provient bien de vous.
Une clé privée est la seule chose que vous devez garder pour vous. C'est la clé qui ouvre ce qui a été verrouillé avec votre clé publique, et c'est aussi ce qui permet de créer des signatures que seul le propriétaire peut produire.
Ensemble, la clé publique et la clé privée forment une paire de clés : elles sont liées mathématiquement, mais non interchangeables. Partager la clé publique est sûr car la connaître ne donne pas de moyen pratique de retrouver la clé privée.
Chiffrement concerne la confidentialité. Si quelqu'un chiffre un message avec votre clé publique, seule votre clé privée pourra le déchiffrer.
Signatures numériques concernent la confiance et l'intégrité. Si vous signez quelque chose avec votre clé privée, toute personne disposant de votre clé publique peut vérifier :
La sécurité n'est pas magique — elle repose sur des problèmes mathématiques difficiles à inverser. Cette propriété « facile dans un sens, difficile dans l'autre » rend le partage de la clé publique sûr tout en gardant la clé privée puissante.
RSA repose sur une asymétrie simple : il est facile d'effectuer le calcul « sens avant », mais extrêmement difficile de l'inverser sans un secret spécial.
Imaginez RSA comme un cadenas mathématique. Tout le monde peut utiliser la clé publique pour verrouiller un message. Mais seul celui qui possède la clé privée peut le déverrouiller.
Cela devient possible grâce à une relation soigneusement choisie entre les deux clés. Elles sont générées ensemble ; bien qu'elles soient liées, on ne peut pas raisonnablement déduire la clé privée en regardant seulement la clé publique.
De façon générale, RSA s'appuie sur le fait que multiplier de grands nombres premiers est facile, tandis que retrouver ces facteurs premiers (factoriser) est extrêmement difficile quand les nombres sont énormes.
Pour de petits nombres, la factorisation est rapide. Pour les tailles réelles des clés RSA (des milliers de bits), les meilleures méthodes nécessitent toujours un temps et une puissance de calcul impraticables. Cette difficulté empêche les attaquants de reconstruire la clé privée.
RSA n'est généralement pas utilisé pour chiffrer des fichiers volumineux ou de longs messages directement. On l'utilise plutôt pour protéger de petits secrets — notamment une clé de session aléatoire. Cette clé de session chiffre ensuite les données réelles avec un chiffrement symétrique plus rapide, mieux adapté au trafic en volume.
RSA est célèbre parce qu'il peut remplir deux fonctions liées mais différentes : chiffrement et signatures numériques. Les confondre cause souvent de la confusion.
Le chiffrement cible surtout la confidentialité. Les signatures numériques ciblent l'intégrité et l'authenticité.
Avec le chiffrement RSA, quelqu'un utilise votre clé publique pour verrouiller quelque chose afin que seule votre clé privée puisse le déverrouiller.
En pratique, RSA protège souvent une clé de session aléatoire, qui chiffre ensuite les données en masse de façon efficace.
Avec les signatures RSA, la direction s'inverse : l'envoyeur utilise sa clé privée pour créer une signature, et quiconque possède la clé publique peut vérifier :
Les signatures numériques apparaissent dans des moments d'« approbation » quotidiens :
Le chiffrement garde les secrets ; les signatures conservent la confiance.
Le cadenas de votre navigateur est un raccourci : votre connexion à ce site est chiffrée et (généralement) authentifiée. Cela signifie que d'autres personnes sur le réseau — par exemple quelqu'un sur un Wi‑Fi public — ne peuvent pas lire ou modifier silencieusement les échanges entre votre navigateur et le site.
Il ne signifie pas que le site est « sûr » au sens large. Le cadenas ne vous dit pas si un magasin est honnête, si un téléchargement est un logiciel malveillant, ou si vous avez saisi le bon nom de domaine. Il ne garantit pas non plus que le site protégera vos données une fois reçues sur leurs serveurs.
Quand vous visitez un site HTTPS, votre navigateur et le serveur réalisent une conversation d'initialisation appelée handshake TLS :
Historiquement, RSA servait souvent à échanger la clé de session (le navigateur chiffrant un secret avec la clé publique RSA du serveur). Dans les configurations TLS modernes, RSA est principalement utilisé pour l'authentification via signatures, tandis que l'accord de clés se fait souvent par d'autres méthodes.
RSA est excellent pour établir la confiance et protéger de petits éléments pendant l'initialisation, mais il est lent comparé au chiffrement symétrique. Après le handshake, HTTPS passe à des algorithmes symétriques rapides pour les pages, connexions et transactions bancaires.
La banque en ligne promet qu'on peut se connecter, consulter des soldes et transférer de l'argent sans que quelqu'un d'autre n'apprenne vos identifiants ni n'altère vos opérations.
Une session bancaire doit protéger à la fois :
Sans HTTPS, toute personne sur le même Wi‑Fi, un routeur compromis ou un opérateur malveillant pourrait potentiellement écouter ou altérer le trafic.
HTTPS (via TLS) sécurise la connexion : les données entre votre navigateur et la banque sont chiffrées et vérifiées pour l'intégrité. Concrètement :
Le rôle historique de RSA a été crucial pour résoudre le problème du « premier contact » : établir une session sécurisée sur un réseau non sécurisé.
Le chiffrement seul ne suffit pas si vous chiffrez vers la mauvaise partie. La banque en ligne ne fonctionne que si votre navigateur peut vérifier qu'il parle à la vraie banque, et non à un site imposteur ou à un man‑in‑the‑middle.
Les banques ajoutent encore MFA, vérifications d'appareil et détections de fraude. Elles réduisent les dégâts quand des identifiants sont volés — mais elles ne remplacent pas HTTPS. Elles fonctionnent comme des filets de sécurité au‑dessus d'une connexion déjà privée et résistante aux altérations.
Les mises à jour logicielles posent autant un problème de confiance que technique. Même si une application est bien écrite, un attaquant peut cibler la distribution — remplacer un installateur légitime par un fichier modifié, ou glisser une mise à jour trafiquée entre l'éditeur et l'utilisateur. Sans moyen fiable d'authentifier le téléchargement, « mise à jour disponible » devient une porte d'entrée facile.
Si les mises à jour ne sont protégées que par un lien de téléchargement, un attaquant qui compromet un miroir, détourne une connexion réseau ou trompe un utilisateur avec une page imitant le site peut servir un fichier différent portant le même nom. L'utilisateur l'installe normalement et le dommage peut être silencieux : malware intégré, portes dérobées ajoutées, ou paramètres de sécurité affaiblis.
La signature de code utilise la cryptographie à clé publique (RSA dans de nombreux systèmes) pour attacher une signature numérique à un installateur ou paquet de mise à jour.
L'éditeur signe le logiciel avec une clé privée. Votre appareil (ou système d'exploitation) vérifie cette signature avec la clé publique de l'éditeur — souvent fournie via une chaîne de certificats. Si un seul octet est altéré, la vérification échoue. Ainsi, la confiance passe de « d'où ai-je téléchargé ? » à « puis‑je vérifier qui a créé ceci et qu'il est intact ? »
Dans les pipelines modernes, ces idées s'étendent aux appels d'API, aux artefacts de build et aux déploiements. Par exemple, des plateformes comme Koder.ai (plateforme vibe-coding pour livrer web, backend et applis mobiles depuis une interface de chat) reposent toujours sur les mêmes fondations : HTTPS/TLS pour les données en transit, gestion soignée des certificats pour les domaines personnalisés, et flux de travail pratiques de type snapshot/restore pour réduire les risques lors des déploiements.
Les mises à jour signées réduisent les opportunités de manipulation non détectée. Les utilisateurs obtiennent des avertissements clairs en cas d'anomalie, et les systèmes d'update automatiques peuvent rejeter un fichier altéré avant exécution. Ce n'est pas une garantie d'absence de bugs, mais une défense puissante contre l'usurpation et la compromission de la chaîne d'approvisionnement.
Pour approfondir comment signatures, certificats et vérification s'articulent, voir /blog/code-signing-basics.
Si RSA vous donne une clé publique, une question naturelle suit : à qui appartient cette clé ?
Un certificat est la réponse d'Internet. C'est un petit fichier signé qui relie une clé publique à une identité — comme un nom de domaine (example.com), une organisation, ou un éditeur logiciel. Pensez‑y comme à une carte d'identité pour une clé : elle dit « cette clé appartient à ce nom », et inclut des détails comme le propriétaire, la clé publique et les dates de validité.
Les certificats ont de la valeur parce qu'ils sont signés par quelqu'un d'autre. Ce « quelqu'un » est souvent une Autorité de Certification (AC).
Une AC est un tiers qui vérifie certaines preuves (du contrôle de domaine à des vérifications plus approfondies) puis signe le certificat. Votre navigateur ou système d'exploitation embarque une liste d'AC de confiance. Quand vous visitez un site HTTPS, votre appareil utilise cette liste pour décider s'il accepte la revendication du certificat.
Ce système n'est pas parfait : les AC peuvent se tromper ou être compromises. Mais il crée une chaîne de confiance pratique à l'échelle mondiale.
Les certificats expirent volontairement. Des durées courtes limitent les dégâts si une clé est volée et encouragent une maintenance régulière.
Les certificats peuvent aussi être révoqués avant leur expiration. La révocation sert à dire « ne faites plus confiance à ce certificat », par exemple si une clé privée a pu fuiter ou si le certificat a été émis par erreur. Les appareils peuvent vérifier l'état de révocation (avec des degrés de fiabilité variables), d'où l'importance de la bonne hygiène des clés.
Gardez votre clé privée privée : stockez‑la dans un stockage sécurisé, limitez les accès et évitez de la copier entre systèmes inutilement.
Faites des rotations de clés quand c'est nécessaire — après un incident, lors de mises à jour planifiées, ou selon les politiques. Suivez les dates d'expiration pour que les renouvellements ne deviennent pas des urgences de dernière minute.
RSA est une idée fondamentale, mais ce n'est pas un bouclier magique. La plupart des compromissions réelles ne surviennent pas parce que quelqu'un a « cassé RSA » ; elles surviennent parce que les systèmes autour de RSA échouent.
Parmi les schémas qui reviennent souvent :
La sécurité de RSA dépend de clés suffisamment longues et véritablement imprévisibles. Un bon générateur d'aléa est essentiel : si la génération de clés utilise une source aléatoire faible, des attaquants peuvent parfois reproduire ou restreindre les clés possibles. De même, la taille de la clé compte car les progrès en puissance de calcul et en mathématiques réduisent graduellement la marge de sécurité des clés petites.
Les opérations RSA sont plus lourdes que certaines alternatives modernes, c'est pourquoi les protocoles l'utilisent parcimonieusement — souvent pour l'authentification ou l'échange d'un secret temporaire, puis basculent vers du chiffrement symétrique pour les données en masse.
La sécurité est une défense en profondeur : protégez les clés privées (de préférence avec du matériel), surveillez l'émission de certificats, appliquez des correctifs, utilisez des authentifications résistantes au phishing et prévoyez la rotation sûre des clés. RSA est un outil de la chaîne, pas la chaîne entière.
RSA reste l'un des outils cryptographiques les plus largement supportés sur Internet. Même si un service ne « préfère » plus RSA, il conserve souvent la compatibilité pour l'héritage : appareils anciens, systèmes d'entreprise de longue durée et infrastructures de certificats existantes.
La cryptographie évolue pour des raisons similaires à d'autres technologies de sécurité :
Vous verrez couramment, dans TLS et les applications modernes :
En clair : RSA peut faire chiffrement et signatures, mais les systèmes modernes préfèrent souvent employer la meilleure méthode pour chaque tâche.
Non. RSA est toujours largement pris en charge et reste un choix valide dans de nombreux cas, surtout quand la compatibilité est critique ou que des pratiques de gestion des clés existantes y sont liées. Le meilleur choix dépend du support des appareils, des besoins de performance, des exigences de conformité et de la manière dont les clés sont stockées et renouvelées.
Si vous voulez voir comment ces choix apparaissent dans de vraies connexions HTTPS, la suite recommandée est : /blog/ssl-tls-explained.
RSA a rendu pratique la confiance à l'échelle d'Internet en permettant la cryptographie à clé publique, qui fournit :
Ces briques sont centrales pour HTTPS, la banque en ligne et les mises à jour logicielles signées.
Leonard Adleman a aidé à transformer RSA d'une idée astucieuse en un cryptosystème que d'autres pouvaient analyser et auquel ils pouvaient faire confiance. Concrètement, il a testé les hypothèses, affiné la présentation et renforcé l'argument selon lequel casser RSA devrait être difficile dans des modèles d'attaque réalistes.
Une clé publique est destinée à être partagée ; on l'utilise pour chiffrer quelque chose pour vous ou pour vérifier vos signatures.
Une clé privée doit rester secrète ; elle sert à déchiffrer ce qui a été chiffré pour vous (dans les usages RSA pour le chiffrement) et à créer des signatures que vous seul pouvez produire.
Si la clé privée fuit, des attaquants peuvent vous usurper et/ou déchiffrer des secrets selon l'usage de la clé.
La sécurité de RSA repose (à haut niveau) sur un problème mathématique unidirectionnel : multiplier de grands nombres premiers est facile, mais factoriser le nombre résultant en ses premiers est extrêmement difficile à des tailles réelles de clés.
Les clés publique et privée sont liées mathématiquement, mais la relation est conçue pour que la clé publique n'expose pas la clé privée de façon pratique.
Ils répondent à des objectifs de confiance différents :
Règle pratique : le chiffrement protège les secrets ; la signature prouve qui a envoyé quelque chose et que cela n'a pas été altéré.
Dans un flux HTTPS simplifié :
RSA peut être utilisé pour l'authentification (signatures), et historiquement a aussi servi à protéger le secret de session initial dans certaines configurations.
Non. Le cadenas indique principalement que la connexion est chiffrée et (généralement) authentifiée.
Il ne garantit pas :
Considérez HTTPS comme une couche de sécurité transport nécessaire, mais pas un verdict de confiance complet.
Un certificat lie une clé publique à une identité (comme un nom de domaine). Les navigateurs font confiance à ce lien parce qu'une Autorité de Certification (AC) signe le certificat, et les navigateurs/OS embarquent une liste d'AC de confiance.
Si vous déployez des services, prévoyez :
Les mises à jour signées permettent à votre appareil de vérifier deux choses :
Cela défend contre les attaques de type « échange du paquet » (miroirs compromis, réseaux détournés, pages de téléchargement imitées). Pour un approfondissement, voir /blog/code-signing-basics.
Les défaillances réelles sont surtout opérationnelles, pas mathématiques :
Mesures pratiques : stocker les clés privées en sécurité (idéalement matériellement), suivre les expirations, faire des rotations de clés planifiées et surveiller l'émission de certificats.
