Leonard Adleman et RSA : comment Internet a appris à faire confiance

Pourquoi RSA compte pour la confiance quotidienne sur Internet

Quand on dit qu'on « fait confiance » à un site ou à un service en ligne, on entend généralement trois choses pratiques :

• Confidentialité : des inconnus ne peuvent pas lire vos messages, mots de passe ou informations de paiement pendant qu'ils traversent Internet.
• Identité : vous parlez bien à votre banque (ou ce magasin), pas à un imposteur.
• Intégrité : ce que vous recevez n'a pas été modifié en douce — que ce soit une page de connexion, une demande de virement ou une mise à jour logicielle.

RSA est devenu célèbre parce qu'il a aidé à rendre ces promesses possibles à l'échelle d'Internet.

Les systèmes quotidiens que RSA a aidé à rendre possibles

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 :

• HTTPS protège de nombreuses connexions entre votre navigateur et un site (l'idée du « cadenas »).
• La banque en ligne est passée de « peut-être évitez » à quelque chose sur lequel des millions de personnes comptent.
• Les logiciels signés et les mises à jour prouvent qu'ils proviennent de l'éditeur réel et n'ont pas été altérés.

Le fil conducteur est la confiance sans avoir à connaître personnellement (ou à partager des secrets à l'avance avec) chaque serveur ou éditeur.

Ce que vous trouverez dans ce guide

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.

L'idée clé : deux clés, deux rôles

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.

Le rôle de Leonard Adleman dans la percée RSA

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.

Ce qu'Adleman a apporté à l'équipe

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.

Où RSA se situe dans l'histoire de la cryptographie

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'impact durable

L'influence de RSA va au-delà d'un seul algorithme. Il a rendu deux essentiels d'Internet réalisables à grande échelle :

• Le chiffrement, pour protéger les données en transit
• Les signatures numériques, pour vérifier l'authenticité des logiciels et messages

Ces idées sont à la base de la normalisation de HTTPS, de la banque en ligne et des mises à jour logicielles signées.

Le problème central résolu par RSA : communiquer en sécurité sans secrets partagés

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.

Pourquoi les secrets partagés ne scale pas

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.

Deux inconnus, une conversation sûre

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.

« Chiffrez-le simplement » ne suffit pas

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 :

• Confidentialité : des tiers ne peuvent pas lire les données.
• Authenticité : vous pouvez vérifier l'identité de votre interlocuteur (et que les messages n'ont pas été modifiés).

RSA a aidé à rendre les deux possibles, jetant les bases de la confiance en ligne à grande échelle.

Bases de la cryptographie à clé publique (sans jargon)

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.

Clé publique vs clé privée (en termes simples)

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.

Deux fonctions principales : chiffrement et signatures numériques

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 :

• que cela a été signé par le détenteur de la clé privée
• que cela n'a pas été modifié depuis la signature

Pourquoi ça marche (sans équations)

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.

Comment RSA fonctionne, à grand trait

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.

L'idée d'une fonction unilatérale avec trappe

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.

Pourquoi la factorisation compte

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.

Le flux de base

1. Générer les clés : votre appareil crée une paire appariée : une clé publique et une clé privée.
2. Publier la clé publique : elle peut être partagée publiquement — sur un site, dans un certificat, ou dans une application.
3. Protéger la clé privée : elle doit rester secrète ; si elle fuit, le verrou est cassé.

Un détail pratique qu'on oublie souvent

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.

Chiffrement vs signatures numériques : deux rôles distincts

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.

Trois objectifs : confidentialité, intégrité, authenticité

• Confidentialité : « seule la personne prévue peut lire ».
• Intégrité : « cela n'a pas été modifié en chemin ».
• Authenticité : « cela vient bien de qui il prétend venir ».

Le chiffrement cible surtout la confidentialité. Les signatures numériques ciblent l'intégrité et l'authenticité.

RSA pour le chiffrement : protéger un message (ou, plus souvent, une clé)

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.

RSA pour les signatures : prouver l'origine et l'intégrité

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 :

• Vient‑ce du détenteur de la clé privée ? (authenticité)
• A‑t‑il été modifié depuis la signature ? (intégrité)

Pourquoi les signatures comptent dans la vie réelle

Les signatures numériques apparaissent dans des moments d'« approbation » quotidiens :

• Validation de transactions : une banque peut signer des messages pour que votre application fasse confiance aux instructions reçues.
• Téléchargements : un installateur signé aide votre ordinateur à vérifier qu'il vient du véritable éditeur.
• Mises à jour : des mises à jour signées empêchent un attaquant de remplacer une version par une version malveillante, même s'il peut altérer le canal de livraison.

Le chiffrement garde les secrets ; les signatures conservent la confiance.

RSA et HTTPS : que se passe-t-il quand vous voyez le cadenas

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.

Un aperçu simplifié de la poignée de main TLS (ce que fait réellement votre navigateur)

Quand vous visitez un site HTTPS, votre navigateur et le serveur réalisent une conversation d'initialisation appelée handshake TLS :

• Le serveur envoie un certificat. Il contient la clé publique du site et le nom de domaine revendiqué.
• Votre navigateur vérifie l'identité. Il s'assure que le certificat est valide pour ce domaine, non expiré et signé par une Autorité de Certification de confiance.
• Ils créent des clés de session. Une fois le navigateur convaincu qu'il parle au bon interlocuteur, les deux parties conviennent de clés symétriques temporaires pour la session.

La place de RSA

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.

Pourquoi vos données ne sont pas chiffrées avec RSA en continu

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.

Comment HTTPS avec RSA a rendu la banque en ligne pratique

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.

Ce dont les banques avaient besoin

Une session bancaire doit protéger à la fois :

• Les connexions : vos mots de passe et autres secrets ne doivent pas être exposés en transit.
• Les transactions : montants et comptes de destination doivent arriver tels quels.
• Les données personnelles : coordonnées et messages ne doivent pas être lisibles par des observateurs.

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.

Comment HTTPS a rendu la confiance suffisante

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 :

• Les attaquants ne peuvent pas lire votre trafic (plus d'interception facile de mots de passe).
• Les attaquants ne peuvent pas altérer silencieusement les requêtes (pas de « transformer 50 € en 5 000 € » en vol).

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é.

Pourquoi l'identité compte autant que le chiffrement

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.

Couches supplémentaires (utiles, pas des remplacements)

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.

Distribution sécurisée de logiciels : pourquoi les mises à jour signées comptent

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.

L'attaque simple : remplacer le paquet

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.

Signature de code : prouver qui l'a construit (et qu'il n'a pas été modifié)

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.

Ce que cela signifie pour les utilisateurs

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.

Certificats et PKI : comment les clés publiques deviennent dignes de confiance

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é.

Autorités de Certification : des connecteurs de confiance, pas de la magie

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.

Expiration et révocation : que faire quand les choses changent

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.

Conseils pratiques de gestion 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.

Limites, risques et idées reçues courantes sur RSA

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.

Modes d'échec communs (ce qui casse réellement)

Parmi les schémas qui reviennent souvent :

• Clés faibles : utiliser des clés RSA trop courtes ou des paramètres obsolètes réduit le coût d'une attaque.
• Mauvaise conservation des clés : clés privées laissées sur un serveur compromis, copiées dans des sauvegardes ou commitées dans un repo peuvent être volées sans casser la cryptographie.
• Phishing et compromission des postes : si un attaquant trompe une personne pour approuver une connexion ou installe un malware, RSA ne peut rien faire ; le chiffrement ne répare pas un terminal piraté.
• Mauvaise émission de certificats : si une AC délivre un mauvais certificat, des utilisateurs peuvent être redirigés vers un attaquant tout en voyant un HTTPS « valide ».

Pourquoi la longueur et l'aléa des clés comptent

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.

RSA n'est pas « trop lent », mais il est utilisé sélectivement

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.

Le plus grand malentendu : « RSA seul me rend sûr »

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 aujourd'hui : où il est encore pertinent et ce qu'on lui préfère parfois

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.

Pourquoi on évolue au-delà de RSA

La cryptographie évolue pour des raisons similaires à d'autres technologies de sécurité :

• Vitesse et efficacité : les opérations RSA peuvent être relativement lentes et nécessiter de grandes clés. Des méthodes plus récentes offrent la même sécurité avec des clés plus petites et des handshakes plus rapides.
• Nouveaux menaces et marges de sécurité : à mesure que la recherche progresse, la communauté revoit ce qui est le plus sûr et le plus simple à déployer correctement.
• Conceptions mieux adaptées à l'usage moderne : le web a besoin aujourd'hui de connexions rapides, de bonnes performances sur mobile et de services à grande échelle — ce qui favorise des algorithmes mieux adaptés.

Ce qu'on utilise souvent à la place ou en complément de RSA

Vous verrez couramment, dans TLS et les applications modernes :

• ECDSA et Ed25519 pour les signatures numériques (authentification). Elles sont généralement plus rapides et utilisent des clés plus petites que RSA.
• ECDH pour l'échange de clés (convenir d'un secret partagé pour démarrer une session chiffrée). C'est une des raisons pour lesquelles de nombreuses connexions HTTPS n'utilisent plus RSA pour l'étape principale d'établissement du secret.

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.

RSA est-il obsolète ?

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.