Tim Hudson, président d’OpenSSL Corporation – Série d’interviews

Tim Hudson est co‑auteur de SSLeay et l’un des organisateurs de la OpenSSL Conference, Prague du 13 au 15 octobre 2026. Il possède plus de 30 ans d’expérience en sécurité des systèmes et des réseaux et est président d’OpenSSL Corporation ainsi que directeur technique chez Cryptsoft Pty Ltd. Depuis 1995, son travail comprend la co‑fondation de SSLeay avec Eric Young, la bibliothèque cryptographique qui est devenue la OpenSSL Library, la co‑fondation du centre de développement RSA Security Australia, la contribution aux changements de la réglementation américaine sur l’exportation du chiffrement, la direction de plus de 30 validations FIPS 140, la coprésidence des comités techniques OASIS KMIP et SAM, et des interventions lors de conférences majeures de sécurité, dont RSA Conference, AusCERT, ICMC, LinuxConf et la OpenSSL Conference.

OpenSSL est un projet collaboratif mondial à source ouverte qui développe et maintient la OpenSSL Library, l’une des bibliothèques cryptographiques les plus largement utilisées au monde. Utilisée sur les systèmes d’exploitation, les plateformes cloud, les logiciels d’entreprise et les appareils connectés, la OpenSSL Library contribue chaque jour à protéger des milliards d’interactions en ligne sécurisées. Grâce à la OpenSSL Foundation et à OpenSSL Corporation, le projet s’engage à faire progresser la cryptographie de confiance, à soutenir le développement durable de l’open source et à renforcer la sécurité d’Internet.

Vous avez co‑fondé SSLeay avec Eric Young en 1995 après avoir constaté le besoin d’une implémentation SSL non américaine, et ce travail est finalement devenu la base d’OpenSSL. Quel problème cherchiez‑vous à résoudre à l’origine, et aviez‑vous à l’époque la moindre idée que la technologie pourrait devenir un élément aussi fondamental de la sécurisation d’Internet ?

Le problème était tout à fait concret, et c’était d’abord un problème commercial avant d’être autre chose. J’étais chez Mincom à Brisbane, et nous avions des clients qui devaient sécuriser leurs communications. Il n’existait aucune façon d’acheter cette capacité. Les contrôles américains à l’exportation du chiffrement signifiaient que les produits américains ne pouvaient pas nous être fournis du tout ou étaient livrés avec des tailles de clé tellement limitées que les déployer aurait été malhonnête. Ce n’était pas une objection philosophique à la politique d’exportation. C’était un problème d’ingénierie où le composant dont j’avais besoin n’existait sous aucune forme achetable, et j’avais des clients qui attendaient.

Ce que je possédais, c’était la connaissance de quelque chose que la plupart des gens avaient oubliée. Eric Young avait écrit une implémentation DES quelques années auparavant: du code bon, propre, librement disponible, écrit pour le plaisir du travail et totalement sans rapport avec tout cela. Eric ne travaillait pas sur SSL. Il n’était pas au courant de SSL. Lorsque Netscape a publié la spécification, je l’ai lue, je suis allé voir Eric avec le problème, et je lui ai présenté cela comme une étape relativement modeste par rapport à ce qu’il avait déjà réalisé.

Ce n’était pas l’ensemble du tableau. Chaque partie était simple, mais il y avait un nombre important de parties. Une implémentation DES vous fournit un chiffre symétrique. SSL nécessite la cryptographie à clé publique, l’arithmétique à précision arbitraire, ASN.1, la gestion des certificats X.509 et une machine d’état de protocole, le tout correctement, car en cryptographie, « presque correct » équivaut à « cassé ». J’avais présenté l’ampleur du projet de façon optimiste. Eric a rapidement compris l’ampleur du travail et l’a apprécié, car l’échelle s’est révélée être l’attrait plutôt que l’obstacle. Je ne suis pas sûr que cela aurait commencé autrement.

Il a réalisé le cœur cryptographique, ce qui explique pourquoi la bibliothèque porte ses initiales. Je me suis chargé des parties qui transforment une bibliothèque en quelque chose que d’autres peuvent réellement déployer: l’intégration applicative, les tests, la documentation et l’aspect communautaire. J’ai également recherché activement chaque utilisation d’une bibliothèque de chiffrement concurrente pour la convertir ou la remplacer. SSLtelnet, SSLftp, NCSA httpd et de nombreux autres paquets sont le fruit de mon travail, des applications construites sur les algorithmes et protocoles cryptographiques implémentés par Eric. Cette combinaison nous a permis à chacun de nous concentrer sur ce qui nous intéressait réellement, ce qui, à mon avis, est la principale raison de la pérennité du projet.

Être en Australie a rendu la résolution possible, et il s’est avéré que de nombreuses autres personnes rencontraient exactement le même problème pour exactement les mêmes raisons. Un outil créé pour répondre à une exigence client spécifique à Brisbane est devenu utile à tous en dehors des États‑Unis, et finalement à un grand nombre de personnes à l’intérieur également.

Savions‑nous ce que cela deviendrait ? Non. Personne ne se lance dans la construction d’infrastructures critiques. Une infrastructure critique est ce que vous découvrez avoir construit, quelques années plus tard, lorsque vous réalisez qui en dépend. Ce que nous pensions faire était résoudre un problème immédiat, puis répondre aux questions d’autres personnes qui avaient rencontré le même obstacle. La partie « répondre aux questions » s’est avérée aussi importante que le code.

Vous travaillez dans la cryptographie et la sécurité Internet depuis plus de trois décennies. Qu’est‑ce qui a le plus changé dans le paysage des menaces pendant cette période, et quels problèmes de sécurité sont restés étonnamment similaires malgré d’énormes avancées technologiques ?

Le changement le plus important est que l’attaque des systèmes est devenue une profession dotée d’un modèle économique. Au milieu des années quatre‑vingt‑dix, les personnes qui pénétraient dans les systèmes le faisaient principalement par intérêt. Aujourd’hui, il existe une industrie, avec spécialisation, outils, chaînes d’approvisionnement, support client, et dans certains cas un financement étatique. Cela change totalement la façon de penser, car vous ne défendez plus contre la curiosité, mais contre quelqu’un disposant d’un budget, d’une échéance et d’un cas d’affaires.

Le deuxième changement concerne l’échelle et la dépendance. L’application moyenne en 1995 était quelque chose que vous écriviez. L’application moyenne aujourd’hui est quelque chose que vous assemblez, et la majorité du code provient de personnes que vous n’avez jamais rencontrées et que vous ne pouvez pas nommer. La surface d’attaque est passée de votre code à vos dépendances, et la plupart des organisations n’ont pas adapté leur réflexion en conséquence.

Ce qui est resté remarquablement constant, ce sont les modes d’échec. Nous continuons à écrire des bugs dans du code qui analyse des entrées non fiables. Nous continuons à livrer des systèmes avec des paramètres par défaut que personne n’a revus. Les certificats expirent encore un samedi. Les identifiants se retrouvent encore à des endroits où ils ne devraient pas être. Et la cryptographie n’est presque jamais cassée au niveau mathématique. Elle est contournée, mal configurée, ou simplement désactivée. Si vous m’aviez remis une liste des dix principales causes de violations en 1996 et une autre du mois dernier, vous auriez du mal à les différencier. La technologie a complètement changé. Les erreurs, non.

OpenSSL 4.0 a été publié en avril 2026, marquant la première version majeure du projet depuis plusieurs années. Que nous indique cette version sur l’évolution de l’infrastructure cryptographique, et quels changements, selon vous, seront les plus déterminants pour les organisations qui dépendent d’OpenSSL ?

Ce qu’il faut surtout retenir à propos de la version 4.0, c’est qu’il s’agit principalement d’une version de soustraction, et que c’était justement son objectif.

Nous avons supprimé complètement l’interface ENGINE. Nous avons retiré SSLv3 et le ClientHello SSLv2. Nous avons désactivé les courbes elliptiques obsolètes et les courbes EC explicites lors de la compilation. Nous avons rendu ASN1_STRING opaque et renforcé un grand nombre de signatures d’API. Ce sont ces changements qui créent du travail pour les développeurs, et ce sont ceux qui comptent, car une bibliothèque cryptographique qui ne fait que s’accumuler ne peut rester sécurisée. Chaque chemin de code obsolète que vous maintenez constitue une surface d’attaque que quelqu’un entretient pour vous, sans que personne ne le teste.

Il y a des ajouts: Encrypted Client Hello, le support du RFC 8998 incluant le groupe hybride SM2/ML‑KEM, cSHAKE, les KDF SNMP et SRTP, le FFDHE négocié pour TLS 1.2. L’ECH, en particulier, comble une véritable faille de confidentialité, car le Server Name Indication divulgue l’identité de chaque site visité depuis le déploiement de TLS 1.3. Mais ce sont les suppressions qui constituent le cœur de l’histoire.

Le message que je souhaite surtout que les organisations retiennent est le suivant: 4.0 n’est pas la version LTS. Elle est prise en charge jusqu’en mai 2027. La version stable à long terme actuelle est la 3.5, prise en charge jusqu’en avril 2030, et la 3.5 intègre déjà les algorithmes post‑quantique. Si vous voulez le code le plus récent, utilisez la 4.0. Si vous voulez une cible stable autour de laquelle bâtir un plan de migration de cinq ans, utilisez la 3.5. Choisir le numéro le plus élevé simplement parce qu’il est plus élevé est une erreur que nous observons chaque cycle.

La cryptographie post‑quantique est passée d’un problème de recherche à un défi de migration, OpenSSL supportant déjà ML‑KEM, ML‑DSA et SLH‑DSA ainsi qu’un échange de clés post‑quantique hybride. Pour les dirigeants qui estiment que l’informatique quantique est encore trop lointaine pour s’en préoccuper, quels risques négligent‑ils aujourd’hui ?

L’erreur la plus courante consiste à considérer cela comme une question de moment où un ordinateur quantique pertinent pour la cryptographie apparaîtra. C’est la mauvaise variable. La bonne question est la durée pendant laquelle vos données doivent rester confidentielles, et le temps nécessaire à votre migration. Soustrayez le second du premier et vous obtenez votre véritable échéance, et pour de nombreuses organisations cette échéance est déjà dépassée.

Le trafic chiffré peut être capturé dès aujourd’hui et stocké indéfiniment. Si les informations qu’il contient ont un horizon de sensibilité de vingt ans (dossiers patients, fichiers du personnel, propriété intellectuelle, documents diplomatiques, positions financières), alors un adversaire n’a pas besoin d’un ordinateur quantique immédiatement. Il en aura besoin éventuellement, et un stockage bon marché en attendant. Ce n’est pas une attaque spéculative ; c’est une décision de conservation.

Le deuxième point négligé est que la migration n’est pas un seul projet. L’échange de clés est la partie facile, et une grande partie est déjà en cours: OpenSSL 3.5 a fait de l’échange de clés post‑quantique hybride la valeur par défaut de TLS, de sorte que de nombreuses organisations utilisent déjà un accord de clés post‑quantique sans en avoir explicitement décidé. Les signatures et la hiérarchie des certificats constituent la partie difficile, car elles impliquent les autorités de certification, les racines matérielles de confiance, les clés de signature du firmware, les modules de sécurité matériels, et des appareils avec une durée de vie de quinze ans qui ont été conçus en supposant que RSA resterait viable indéfiniment.

Le troisième point est la contrainte que personne ne budgète: les signatures post‑quantiques sont volumineuses. Une signature ML‑DSA‑65 fait environ cinquante fois la taille d’une signature ECDSA P‑256, et SLH‑DSA est encore plus grande. Cela pose problème: tailles de poignée de main, appareils contraints, protocoles avec des limites de champ codées en dur, liaisons satellite et IoT. Vous découvrez ces problèmes par les tests, pas en lisant une norme.

L’un des défis de la migration post‑quantique est que les organisations ne savent parfois même pas où la cryptographie est utilisée dans leurs applications, infrastructures, appareils et dépendances tierces. Comment les entreprises doivent‑elles aborder l’inventaire cryptographique et la crypto‑agilité afin que la prochaine transition majeure d’algorithme ne devienne pas une urgence ?

Commencez par une vérité inconfortable: vous ne pouvez pas établir un inventaire cryptographique en envoyant un questionnaire à vos fournisseurs. Vous recevrez un mélange de texte marketing, d’incertitudes honnêtes et de réponses qui étaient valides il y a trois versions. Je le dis après avoir passé beaucoup de temps récemment à lire la documentation de fournisseurs de matériel dans un domaine connexe, et l’écart entre ce que la documentation prétend et ce que le produit fait est plus grand que ne le supposent la plupart des acheteurs.

Il faut examiner. Il existe trois couches, chacune nécessitant des techniques différentes. Le code que vous avez écrit: analyse statique, analyse des dépendances, et recherche des identifiants d’algorithmes que vous avez codés en dur il y a des années. Le code que vous avez lié: listes de matériaux logiciels, étendues aux listes de matériaux cryptographiques, où le travail CBOM est réellement utile. Les éléments que vous avez achetés ou connectés: observation réseau, car ce que vos systèmes négocient réellement sur le fil est la vérité de terrain, souvent différente de ce que l’on pensait.

En matière d’agilité, le principe est simple mais la pratique ne l’est pas: l’algorithme doit être une décision de configuration, pas une modification de code. Si changer un chiffre nécessite un développeur, une compilation, un cycle de test et une version, vous n’avez pas d’agilité. Vous avez un projet. Centralisez les opérations cryptographiques derrière une interface que vous contrôlez, afin d’avoir un seul point de modification au lieu de quatre cents.

Puis vient la partie que presque tout le monde ignore: la mettre en pratique. Une agilité jamais testée n’est qu’une affirmation, pas une capacité. Choisissez un week‑end calme, désactivez un algorithme dans un environnement non‑production, et voyez ce qui casse. Il y aura forcément un problème. Mieux vaut le découvrir selon votre planning que lors d’une transition d’urgence imposée.

Un levier utile est la durée de vie des certificats. L’industrie tend vers des certificats à durée de vie nettement plus courte, ce qui rend la gestion manuelle des certificats invivable et impose l’automatisation dont vous auriez de toute façon besoin. Si vous automatisez correctement l’émission et la rotation des certificats, vous avez construit la majeure partie de l’infrastructure requise pour une future transition d’algorithme.

L’IA modifie à la fois la défense en cybersécurité et les capacités des attaquants. Selon vous, où l’IA change‑t‑elle réellement l’équation de sécurité, et où les organisations se concentrent‑elles trop sur la technologie au détriment de faiblesses plus fondamentales ?

L’IA change réellement une chose, et je peux en parler directement car cela nous est arrivé.

Un nombre important de vulnérabilités divulguées dans OpenSSL cette année ont été découvertes grâce à une analyse pilotée par l’IA. En janvier, nous avons publié une version corrigeant douze problèmes, presque tous provenant d’un même groupe de recherche utilisant l’analyse automatisée, qui ont fourni des correctifs avec leurs rapports. En juin, nous avons corrigé une vulnérabilité critique de type use‑after‑free dans la vérification PKCS#7, découverte par un chercheur travaillant avec un système d’IA. C’est un réel changement de capacité pour détecter des bugs de sécurité mémoire et d’analyse dans du code C mature, revu par des experts pendant des années. J’ai observé le même schéma dans d’autres bibliothèques cryptographiques. En analysant un lot de CVE Bouncy Castle de cette année, l’empreinte de l’analyse de code automatisée est évidente.

L’implication évidente est que cela fonctionne dans les deux sens. Les mêmes techniques sont à la disposition de quiconque veut les utiliser, sur les mêmes bases de code, et les défenseurs n’en ont pas l’accès exclusif.

L’implication moins évidente, et celle que je soulignerais, est la charge que cela impose aux mainteneurs. Générer un rapport de vulnérabilité plausible est désormais presque gratuit. En faire le triage ne l’est pas. Cela coûte toujours du temps réel à un expert humain. Les équipes de sécurité open source, généralement petites et souvent bénévoles, absorbent un volume croissant de rapports de qualité très variable. Les bons, comme la recherche que j’ai citée, sont fournis avec des reproductions et des correctifs. Les mauvais constituent une attaque par déni de service contre les personnes dont vous dépendez. Si votre organisation déploie l’IA contre du code open source, financez la capacité de triage à l’autre bout.

Ce que je considère comme un mauvais focus: l’IA ne corrige pas vos systèmes. Elle n’inventorie pas vos actifs, ne fait pas tourner vos identifiants, ne retire pas votre matériel non supporté, et ne rend pas responsable la personne en charge du certificat qui expire le mois prochain. Les organisations qui achètent des outils de sécurité IA tout en exécutant des logiciels contenant des vulnérabilités connues non corrigées ont inversé la séquence. Le travail peu glorieux reste là où se situe le risque.

De nombreuses organisations investissent massivement dans des outils mais restent vulnérables à cause d’erreurs de configuration, de systèmes obsolètes, de processus faibles ou d’une mauvaise préparation aux incidents. Quels sont les erreurs de sécurité les plus conséquentes que vous continuez à observer, et que les équipes dirigeantes devraient avoir en place avant qu’une attaque ne survienne ?

L’erreur la plus conséquente consiste à considérer la sécurité comme une activité d’achat. Les outils sont acquis, les budgets sont respectés, les tableaux de bord sont verts, et personne ne s’est demandé si l’organisation peut réellement accomplir les actions fondamentales.

La deuxième consiste à ne pas savoir ce que vous exécutez. Vous ne pouvez pas corriger un logiciel dont vous ignorez l’existence, et la plupart des organisations découvrent le véritable contenu de leur parc lors d’un incident. C’est pourquoi le travail sur la nomenclature (bill‑of‑materials) est important, non pas comme un artefact de conformité, mais comme ce à quoi vous vous raccrochez à deux heures du matin lorsqu’une alerte critique apparaît et que quelqu’un vous demande si vous êtes concerné.

La troisième concerne les paramètres par défaut. Les systèmes sont installés, ils fonctionnent, et la configuration n’est jamais revue. Cinq ans plus tard, cette configuration devient une responsabilité, et personne ayant participé à la décision initiale n’y travaille plus.

La quatrième est la gestion des clés et des certificats confiée à des individus. Une proportion remarquable d’interruptions auto‑induites provient de certificats expirés qu’une seule personne suivait discrètement dans un tableau Excel avant de changer de poste.

Avant un incident, la direction doit disposer de quatre éléments. Un décideur désigné, disposant de l’autorité de mettre l’activité hors ligne, choisi à l’avance et par écrit, car le débat sur qui détient cette autorité n’est pas souhaitable en situation de crise. Des contrats de prestation déjà signés avec des experts en criminalistique externe et des conseillers spécialisés, car ces achats prennent des semaines alors que vous n’avez que quelques heures. Un canal de communication qui ne dépend pas des systèmes susceptibles d’être compromis. Et une capacité de restauration réellement testée de bout en bout, et non un dispositif de sauvegarde vérifié uniquement dans le sens où les tâches se sont terminées avec succès.

Ensuite, répétez‑le. Un exercice de simulation (table‑top) au niveau exécutif, une fois par an, révélera davantage de lacunes réelles qu’un autre outil.

Lorsqu’une cyberattaque grave se produit, les dirigeants peuvent se retrouver à prendre des décisions techniques, juridiques, opérationnelles et de communication sous une pression énorme. Qu’est‑ce qui distingue les organisations qui réagissent efficacement de celles qui laissent un incident s’aggraver considérablement ?

Les organisations qui gèrent bien la situation ont pris les décisions importantes avant l’incident, de sorte qu’au cours de l’incident elles exécutent plutôt que de délibérer. C’est le principal facteur.

Au‑delà de la préparation, quelques éléments séparent constamment les bonnes réponses des mauvaises.

Ils séparent l’enquête technique de la piste exécutive et de communication, avec une interface clairement définie entre les deux. Lorsque les mêmes personnes tentent de contenir une intrusion et de rédiger une notification client, les deux tâches sont mal exécutées.

Ils conservent les preuves avant de remédier. L’instinct de reconstruire immédiatement la machine compromise est fort, mais il détruit les informations nécessaires pour établir l’étendue. Si vous ne pouvez pas répondre « qu’est‑ce qu’ils ont encore touché », vous ne pouvez pas dire de façon crédible que l’incident est terminé.

Ils acceptent que les premières informations soient provisoires et communiquent en conséquence. La plupart des dommages réputationnels que j’ai observés ne proviennent pas de la violation elle‑même, mais d’affirmations précoces et confiantes qui ont dû être rétractées. Dire « voici ce que nous savons, voici ce que nous ne savons pas encore, voici quand nous vous tiendrons informés » n’est pas une faiblesse. C’est la seule position que vous n’aurez pas à renverser.

Et, surtout: ils créent des conditions permettant aux ingénieurs de transmettre de mauvaises nouvelles aux dirigeants. Le schéma d’échec que j’ai le plus souvent observé est une organisation où l’exposition juridique était si évidente que personne ne voulait être celui qui consigna les faits réels. L’incident s’aggrave alors en silence. Si vos ingénieurs gèrent leur propre responsabilité plutôt que l’incident, vous avez un problème de gouvernance qu’aucun outil ne résoudra.

OpenSSL occupe une position particulière en tant qu’infrastructure open‑source critique utilisée dans tout l’écosystème technologique, tandis que OpenSSL Corporation se concentre sur le service aux communautés commerciales aux côtés de la OpenSSL Foundation, qui fonctionne de manière indépendante. Comment équilibrez‑vous les besoins des entreprises, des développeurs, des régulateurs et de la communauté open‑source plus large lorsque les décisions concernant la sécurité et la compatibilité peuvent toucher une si grande partie d’Internet ?

La réponse honnête est que vous ne les équilibrez pas en essayant de satisfaire tout le monde à chaque décision. Vous les équilibrez en publiant une politique et en l’appliquant de façon prévisible, afin que les parties puissent planifier en fonction, même si elles n’aiment pas un résultat particulier.

La prévisibilité est ce que nous devons à nos utilisateurs. Nous publions des versions fonctionnelles en avril et en octobre. Nous annonçons à l’avance quelle version est stable à long terme et jusqu’à quand. Nous annonçons les suppressions importantes bien avant qu’elles ne soient effectives. La suppression de ENGINE dans la version 4.0 a été décrite publiquement plusieurs mois avant la sortie, et approuvée à la fois par la Corporation et la Fondation. Quiconque a été surpris en avril n’avait pas suivi, et nous avons rendu cela aussi simple que possible.

La réponse structurelle réside dans la séparation elle‑même. La Fondation existe pour servir la bibliothèque open source et la communauté qui l’entoure. La Corporation existe pour servir les organisations avec des exigences commerciales (engagements de support, validation FIPS, calendriers spécifiques) et rendre l’ensemble financièrement viable. Maintenir cette distinction signifie qu’aucun des deux jeux de besoins n’est discrètement résolu au profit de l’autre. Lorsque les exigences des entreprises et de la communauté entrent réellement en conflit, ce conflit se produit entre deux organisations aux mandats clairs, plutôt que dans la tête d’une seule personne.

L’autre aspect est d’écouter correctement, ce qui nécessite de véritables mécanismes plutôt que des suppositions. C’est en grande partie la raison pour laquelle nous organisons la conférence, qui se tient à Prague en octobre, et pourquoi l’infrastructure communautaire existe. Il est très facile pour les mainteneurs de développer des théories convaincantes sur les besoins des utilisateurs. Il est bien plus utile d’être dans une salle avec eux.

En regardant la prochaine décennie, quelle transition de sécurité ou cryptographique pensez‑vous que les organisations sous‑estiment encore aujourd’hui, et quelles leçons tirées de l’évolution de SSL, OpenSSL et des trente dernières années de sécurité Internet les dirigeants devraient‑ils appliquer en s’y préparant ?

La transition que je juge la plus sous‑estimée n’est pas la cryptographie post‑quantique en tant que problème d’algorithme. Il s’agit de l’identité des machines et de la hiérarchie des certificats qui sous-tendent tout.

L’échange de clés post‑quantique sera largement résolu par les paramètres par défaut, et une grande partie l’est déjà. Ce qui ne sera pas résolu par les paramètres par défaut, c’est l’infrastructure de confiance: certificats racine dans le matériel, clés de signature du firmware gravées dans les appareils, HSM avec une décennie de durée de vie restante, systèmes industriels et médicaux qui fonctionneront encore en 2040 avec des hypothèses cryptographiques intégrées dès la fabrication. Ceux‑ci ne peuvent pas être mis à jour simplement en diffusant une nouvelle version de bibliothèque, et dans certains cas ne peuvent pas être mis à jour du tout. L’ampleur de ce problème de remplacement n’est actuellement reflétée dans aucune planification budgétaire.

Parallèlement, une transition réglementaire se profile. Le Cyber Resilience Act en Europe, ainsi que des cadres comparables ailleurs, modifieront les obligations liées à la distribution de logiciels contenant des composants que vous n’avez pas écrits. La plupart des organisations n’ont pas encore analysé ce que cela implique pour leur dépendance à l’open source, ni pour les personnes qui le maintiennent.

Trois leçons tirées de trente ans:

1. Les transitions prennent une décennie de plus que prévu. SSLv3 a été déprécié en 2015, désactivé par défaut en 2016, et nous avons finalement retiré le code en avril 2026. Cela représente onze ans, pour un protocole que tout le monde reconnaissait comme cassé. Planifiez la migration post‑quantique en fonction de cette réalité, et non du communiqué de presse.
2. Les paramètres par défaut sont le seul contrôle de sécurité qui fonctionne à grande échelle. Tout ce qui exige que chaque administrateur prenne la bonne décision ne se produira pas. La raison pour laquelle l’échange de clés post‑quantique hybride s’est déployé aussi rapidement est qu’il est activé par défaut et ne nécessite aucune décision. Concevez pour les personnes qui ne liront jamais votre documentation, car cela représente presque tout le monde.
3. Vous dépendez de moins de personnes que vous ne le pensez. Presque toutes les organisations du monde s’appuient sur du code cryptographique maintenu par un très petit nombre