Le post-quantique hybride

Éditorial

Les déploiements post-quantiques combinent ML-KEM et X25519 au lieu de choisir entre les deux. Ce n'est pas une hésitation d'ingénieur mais une défiance assumée envers des primitives jeunes, et elle se paie surtout en complexité et en code, beaucoup moins en octets.

Mis à jour le 25 septembre 2026~27 min de lecture13 sections

papy cyber

Explication de la marmotte

Ce texte parle d’une porte équipée de deux serrures différentes : une ancienne, éprouvée depuis longtemps mais menacée par un futur outil de cambriolage, et une toute neuve, conçue pour lui résister mais encore peu éprouvée. Tant qu’une des deux tient, la porte reste fermée. Reste à savoir ce que coûte vraiment cette double précaution.

→ Lire l’explication complète de la marmotte

Constats datés

Ce texte examine l’échange de clés hybride tel qu’il se déploie dans TLS, SSH et quelques messageries : un secret établi à la fois par une courbe elliptique classique et par un mécanisme post-quantique, puis mélangé. Les identifiants de groupes, les brouillons de normalisation et les positions des agences bougent vite. Les éléments factuels datent de septembre 2026 ; le raisonnement devrait leur survivre.

Deux serrures sur la même porte

L’objet de cet éditorial tient dans un nom que personne n’aurait osé donner à un enfant : X25519MLKEM768. C’est un groupe d’échange de clés pour TLS 1.3 qui fait deux choses à la fois. Il réalise un échange Diffie-Hellman classique sur la courbe 25519, et il réalise une encapsulation ML-KEM, le mécanisme post-quantique normalisé par le NIST à partir de la proposition Kyber. Les deux secrets sont accolés, puis versés dans la dérivation de clés du protocole. Le canal ne tombe que si les deux tombent.

Dit ainsi, c’est du bon sens. Dit autrement, c’est un vaudeville. On a organisé pendant près d’une décennie une compétition internationale pour élire l’algorithme qui nous sauverait de l’ordinateur quantique ; on l’a couronné, normalisé, publié en grande pompe ; et le jour de son entrée dans le monde, on lui a collé un chaperon. Ce chaperon, précisément, est le vieil algorithme qu’il était venu remplacer, celui dont on nous annonce depuis des années la mort certaine. C’est un peu comme engager un garde du corps et exiger que l’ancien, qu’on vient de licencier pour incompétence, dorme dans la chambre d’à côté.

La question de cet éditorial n’est pas « faut-il migrer » : elle est traitée dans le chapitre sur la préparation de la migration post-quantique. Elle est plus étroite et plus gênante : pourquoi combine-t-on au lieu de choisir, et que dit ce choix de la manière dont nous accordons notre confiance à une primitive ?

La réponse courte est qu’on a peur de deux choses à la fois, et qu’aucun algorithme seul ne rassure sur les deux. La réponse longue occupe la suite, parce que la réponse courte a une facture, et que cette facture n’arrive pas à l’adresse où tout le monde guette le facteur.

Deux peurs qui ne se ressemblent pas

Le discours ambiant mélange deux menaces, parce que le mélange vend mieux.

La première peur porte sur l’ancien. Un ordinateur quantique assez grand et assez fiable, exécutant l’algorithme de Shor, résoudrait le logarithme discret sur courbe elliptique et la factorisation. X25519 tomberait, RSA avec lui. Personne ne sait quand, ni même si, une telle machine existera. Mais la menace a une propriété désobligeante : elle est rétroactive. Un échange enregistré aujourd’hui sera lisible le jour où la machine existera, ce qui fait l’objet de l’éditorial voisin, Récolter maintenant, déchiffrer plus tard. Contre cette peur, X25519 seul est un parapluie en papier.

La seconde peur porte sur le neuf. ML-KEM repose sur la difficulté supposée d’un problème de réseaux euclidiens structurés, le module learning with errors. Les réseaux ont une littérature ancienne et sérieuse. Mais un problème mathématique n’est pas un algorithme déployé : entre les deux, il y a des choix de paramètres, une structure algébrique ajoutée pour gagner en taille et en vitesse, une transformation qui apporte la sécurité contre les chiffrés choisis, et des implémentations. Chaque étage peut céder sans prévenir les autres. Contre cette peur, ML-KEM seul ne sert à rien, par définition, ce qui est une phrase qu’on imprime rarement sur les brochures.

Ces deux peurs n’ont ni la même nature, ni le même calendrier. La première est une rupture hypothétique au mécanisme connu et aux conséquences totales. La seconde est une surprise cryptanalytique au mécanisme inconnu, sans calendrier, et dont l’histoire récente fournit des exemples pour qui a la mémoire courte mais pas trop.

Les cadavres de la compétition

Le processus de normalisation post-quantique a eu la délicatesse de nous montrer ce qu’il fallait craindre. Plusieurs candidats sérieux, examinés pendant des années par des gens compétents, sont tombés sous des attaques classiques, sur un ordinateur ordinaire, sans le moindre qubit.

Le cas le plus élégant, car il faut bien que la mort ait du style, est celui de SIKE, fondé sur les isogénies de courbes supersingulières : compact, raffiné, encore en lice à un stade avancé. En 2022, une attaque classique a permis d’en retrouver la clé secrète avec des moyens dérisoires. La même année, le schéma de signature Rainbow, finaliste, a vu sa sécurité effective chuter bien en dessous de ce qui était annoncé. Ni l’un ni l’autre n’était une fantaisie de congrès. Tous deux avaient passé plusieurs tours d’évaluation publique, le menton haut.

La leçon n’est pas que ML-KEM va tomber ; rien ne l’indique. Elle est que « a survécu à la compétition » n’est pas une propriété de même nature que « a survécu à trente ans de déploiement ». Une compétition est un filtre, pas une garantie, et celle-ci a eu l’honnêteté de le démontrer sur ses propres finalistes.

L’asymétrie qui justifie tout

Posons les deux primitives côte à côte, comme deux prévenus.

X25519 a derrière lui des années d’analyse, des déploiements massifs, des implémentations relues jusqu’à l’usure, et une seule condamnation connue (Shor), prononcée par un tribunal qui n’a pas encore été construit. ML-KEM a derrière lui une analyse sérieuse mais plus courte, une structure plus complexe, des implémentations dans leur prime jeunesse, et une résistance présumée à Shor.

Chacun couvre exactement le trou de l’autre, et l’hybridation refuse de parier. Elle fabrique un secret qui reste sûr tant qu’au moins un des deux mécanismes tient, et sa seule hypothèse est que les deux ne s’effondrent pas le même jour. C’est la propriété de robustesse des combinateurs. Elle s’énonce en une ligne. Elle s’obtient en un peu plus.

Ce que « combiner » veut dire

Dire qu’on « combine » deux secrets ne dit rien, de la même manière que dire qu’on « mélange » deux produits ménagers ne dit rien de l’état de la cuisine après. Tout dépend de la manière.

Le mélange naïf et le mélange correct

La construction retenue dans TLS 1.3 est d’une sobriété presque janséniste. Le client envoie, dans le même champ, sa part pour les deux mécanismes, simplement accolées. Le serveur répond par un chiffré ML-KEM et une clé publique X25519 éphémère, accolés eux aussi. Chacun obtient deux secrets, les concatène, et verse le tout dans le calendrier de clés de TLS 1.3, là où l’on aurait mis le secret Diffie-Hellman seul.

Pourquoi est-ce suffisant ? Parce que TLS 1.3 lie déjà tout au transcript. Les clés de session dérivent du secret partagé, mais aussi d’un condensé de l’ensemble des messages échangés, parts publiques et chiffrés compris. Un attaquant qui toucherait à l’un des composants modifierait le transcript, donc les clés, donc ferait échouer la poignée de main. La dérivation de TLS fait office de combinateur, et elle le fait bien, parce qu’elle a été conçue pour digérer des entrées de natures diverses.

La même concaténation, sortie de ce contexte, devient fragile. Combiner deux secrets de KEM hors d’un protocole qui lie les chiffrés, par un simple OU exclusif ou par une fonction de hachage qui ne voit que les secrets, fait perdre des propriétés de liaison : rien n’empêche plus, dans certaines constructions, qu’un même secret combiné corresponde à plusieurs couples de chiffrés, ce qui peut suffire à ruiner la sécurité de l’ensemble contre les chiffrés choisis. C’est pourquoi les KEM hybrides autonomes, pensés pour être réutilisés hors de TLS (on en voit passer à l’IETF pour des usages de type HPKE), injectent explicitement dans la dérivation les chiffrés et les clés publiques, pas seulement les secrets.

La robustesse d’un hybride est une propriété de la construction complète, pas des deux primitives qu’on y a versées. Deux bons algorithmes mal combinés donnent un mauvais algorithme, avec l’air sérieux en prime, ce qui est la pire espèce.

Un KEM n’est pas un Diffie-Hellman

Seconde subtilité, plus discrète. Diffie-Hellman est un échange symétrique : chacun publie une valeur, chacun calcule le même secret. Un KEM est asymétrique : l’un publie une clé d’encapsulation, l’autre y enferme un secret aléatoire et renvoie le chiffré, le premier l’ouvre. Le chapitre sur l’établissement de clés détaille la mécanique.

Dans TLS 1.3, la différence se loge sans douleur : la poignée de main a déjà un aller et un retour. Dans les protocoles bâtis sur des Diffie-Hellman statiques ou croisés, en revanche, la substitution n’est pas terme à terme, et la messagerie Signal a dû concevoir une nouvelle variante de son accord de clés initial pour y faire entrer un KEM (les chapitres sur les messageries sécurisées situent le problème). L’hybride y devient une nouvelle recette, qui réclame sa propre analyse et a souvent reçu des preuves formelles : c’est rassurant, et qu’il ait fallu en produire l’est moins.

Le prix en octets

C’est le coût dont tout le monde parle, et c’est le moins grave. Il mérite quand même qu’on le pose correctement, car ses effets indirects sont plus sérieux que sa valeur faciale.

Une part X25519 fait 32 octets. Pour ML-KEM-768, le jeu de paramètres des hybrides courants, la clé d’encapsulation fait 1 184 octets et le chiffré 1 088. L’hybride additionne : un peu plus de 1 200 octets dans le message du client, un peu plus de 1 100 dans la réponse du serveur. Sur une connexion qui transportera ensuite une page web de plusieurs centaines de kilo-octets, dont une bonne moitié de scripts publicitaires, c’est epsilon. En temps de calcul, ML-KEM est rapide, souvent plus que l’opération sur courbe qu’il accompagne. Si l’on s’arrêtait là, cet éditorial ferait trois paragraphes et je pourrais retourner à ma sieste.

La première enveloppe

L’effet réel de ces octets n’est pas leur nombre, c’est l’endroit où ils tombent. Le premier message d’une poignée de main TLS, le ClientHello, tenait jusqu’ici dans un seul paquet. Avec une part hybride, il déborde et doit être découpé sur plusieurs segments.

Rien, dans les normes, n’interdit un ClientHello en plusieurs morceaux. Mais des pare-feux, répartiteurs et boîtiers d’inspection avaient été écrits en supposant le contraire, et le déploiement des premiers hybrides dans les navigateurs en a déterré qui abandonnaient la connexion dès que le premier message ne tenait plus dans le premier paquet. Le problème n’était pas cryptographique. Il était archéologique : des hypothèses implicites fossilisées dans du matériel que plus personne ne met à jour, et que certains ont parfois oublié posséder.

C’est l’ossification, vieille maladie du réseau : chaque liberté qu’un protocole n’exerce pas finit par lui être retirée par un équipement qui a décidé à sa place. Le coût de l’hybride en octets se mesure moins en bande passante qu’en compatibilité avec des boîtes que personne n’a inventoriées.

Le pari du premier message

Deuxième effet indirect. Dans TLS 1.3, le client envoie spéculativement des parts de clé pour les groupes qu’il croit acceptés par le serveur. S’il se trompe, le serveur réclame une nouvelle tentative, et l’on paie un aller-retour. Avec des parts de 32 octets, on pouvait en envoyer plusieurs par politesse. Avec des parts d’un kilo-octet, la politesse devient coûteuse, et chaque part supplémentaire aggrave le problème de l’enveloppe.

Le client doit donc parier, et le bon pari dépend d’une population de serveurs qui change pendant la transition. Ce coût n’apparaît dans aucun comparatif d’algorithmes, pour l’excellente raison qu’il n’est pas dans l’algorithme. Quant aux objets connectés sur liaison radio avare, pour qui deux mille octets ne sont pas un détail, ils mériteraient un éditorial à eux seuls ; pour une connexion web ou une session SSH, l’argument de la taille relève du réflexe, et il dispense commodément de parler de ce qui coûte vraiment.

Le prix en complexité

Ce qui coûte vraiment, c’est d’abord que l’hybride n’est pas un algorithme mais un assemblage négocié, et que tout ce qui se négocie se configure, se versionne et se casse, de préférence un vendredi.

Des noms qui changent sous les pieds

Pendant la phase expérimentale, navigateurs et grands serveurs ont déployé un hybride fondé sur une version préliminaire de Kyber, sous un identifiant provisoire. Puis ML-KEM a été publié dans sa forme définitive, avec assez de différences pour que les deux ne se parlent pas, et un nouvel identifiant a remplacé l’ancien. Ils ont cohabité un temps, puis le premier a été congédié. L’ordre de concaténation des deux composants a d’ailleurs changé au passage.

C’est le prix normal d’un déploiement anticipé, et l’anticipation était justifiée. Mais qui voulait « activer le post-quantique » a dû suivre plusieurs noms pour une seule intention, et découvrir que clients et serveurs n’avaient pas été mis à jour au même pas. Une primitive qui change deux fois de nom avant d’être stable n’a pas de défaut ; elle a un âge.

Une matrice qui double

Deuxième source de complexité : la matrice de test. Un serveur qui accepte l’hybride doit continuer d’accepter le classique pendant toute la transition, sous peine de perdre les clients anciens. Il a donc deux chemins d’établissement de clé, qui doivent tous deux fonctionner, être testés, et résister à qui voudrait imposer le plus faible.

TLS 1.3 se défend bien contre l’attaquant actif qui voudrait rayer l’hybride de la liste du client : le transcript le trahirait. Il ne protège pas du déclassement par configuration : une mise à jour qui retire l’hybride des groupes autorisés, un boîtier qui termine TLS et le rétablit derrière lui avec ses propres réglages, un client embarqué jamais mis à jour. Ces déclassements-là sont silencieux, puisque chaque poignée de main, prise isolément, est parfaitement correcte. Le crime est parfait, et il n’y a même pas de criminel.

Vérifier ce qu’on négocie réellement

La seule réponse est la vérification, qui est plus simple qu’on ne le croit. Pour SSH, le client liste les algorithmes d’échange de clés qu’il connaît, et une connexion verbeuse indique celui qui a été retenu :

# Algorithmes d'échange de clés connus du client SSH local
ssh -Q kex

# Algorithme réellement négocié avec un hôte donné (lecture seule)
ssh -v [email protected] exit 2>&1 | grep -i 'kex: algorithm'

OpenSSH propose des échanges hybrides depuis plusieurs versions et les versions récentes en font leur choix par défaut ; les noms exacts varient selon la version installée, d’où l’intérêt de lire ce que la commande répond plutôt que ce que la documentation promet. Pour TLS, tout dépend de la bibliothèque : les outils récents permettent d’imposer un groupe et d’observer si la poignée de main aboutit, les anciens ne connaissent tout simplement pas les noms. Dans tous les cas, ce qui compte n’est pas ce que le serveur sait faire, c’est ce qui est négocié avec les clients réels, et cela se lit dans les journaux ou dans une capture, jamais dans une plaquette.

Ce travail relève de l’inventaire cryptographique. Il est ennuyeux et n’a rien de quantique : les choses utiles ont rarement le bon goût d’être passionnantes.

La surface d’implémentation

On arrive au coût qu’on mentionne le moins, et qui est à mon sens le plus sérieux. Hybrider, c’est ajouter du code cryptographique neuf à côté de code cryptographique ancien, dans le chemin critique de chaque connexion.

La cryptographie meurt rarement de ses mathématiques. Elle meurt de ses implémentations : un calcul dont la durée dépend d’un secret, une vérification oubliée, une valeur mal validée, un tampon mal dimensionné, un aléa mal tiré. Le chapitre sur les canaux auxiliaires en tient le registre, et le registre est épais. Les implémentations de courbes elliptiques ont mis des années à atteindre leur sagesse actuelle, et la courbe 25519 a précisément été dessinée pour que le code correct soit plus facile à écrire que le code faux. C’est la seule forme de vertu qui marche en informatique : celle qui coûte moins cher que le vice.

ML-KEM n’a pas eu ces années.

Ce qui peut fuir

Un KEM fondé sur les réseaux manipule des polynômes, des réductions modulaires, des compressions de coefficients, et un mécanisme de rejet implicite : si le chiffré reçu ne correspond pas à ce que donnerait sa réencapsulation, l’algorithme ne renvoie pas d’erreur mais un secret pseudo-aléatoire, pour ne rien avouer. Cette transformation est essentielle contre les chiffrés choisis. Elle est aussi l’endroit rêvé pour une fuite : une comparaison qui s’arrête au premier octet différent, un branchement qui dépend du résultat, une division dont la durée varie selon l’opérande.

Ce n’est pas théorique : des variations de temps d’exécution liées à des divisions sur des données secrètes ont été trouvées dans plusieurs implémentations de Kyber, y compris de référence, puis corrigées. On en retrouvera, parce que le code est neuf et que les compilateurs ont parfois l’obligeance de transformer un calcul à temps constant en calcul qui ne l’est plus, au nom de la performance.

Ce que l’hybride protège, et ce qu’il ne protège pas

C’est ici que l’argument se retourne à moitié. L’hybride protège contre une faiblesse mathématique de ML-KEM : si le problème tombe, X25519 tient encore. Il protège aussi contre les défauts qui rendent le secret ML-KEM faible ou prévisible, puisque l’autre moitié reste imprévisible.

Il ne protège pas contre un défaut qui compromet autre chose que le secret de session. Un débordement de tampon dans le code qui analyse une clé d’encapsulation reçue du réseau se moque du combinateur : il exécute du code arbitraire dans le processus qui détient la clé privée du serveur. Une fuite par canal auxiliaire sur une clé ML-KEM durable compromet cette clé, quel que soit le mélange qui suit ; seuls les usages éphémères, comme dans TLS, en sont largement préservés.

L’hybridation assure contre l’échec de la primitive. Elle n’assure pas contre l’échec du code qui l’entoure, et elle double la quantité de ce code. Ce n’est pas un argument contre elle. C’est un argument pour ne pas lui prêter une vertu qu’elle n’a pas, ce qui est la forme la plus courante de l’affection.

Ce que l’hybride ne couvre pas

L’hybridation dont on parle concerne l’établissement de clés. Il faut dire clairement ce qu’elle laisse de côté, car le vocabulaire commercial (« connexion post-quantique », « chiffrement résistant au quantique ») étend volontiers la propriété à tout ce qui passe dans le tuyau, y compris le tuyau.

L’authentification reste classique

Une poignée de main TLS hybride typique établit ses clés de manière hybride, mais authentifie le serveur par un certificat signé en ECDSA ou en RSA. Autrement dit : la confidentialité est protégée contre un futur ordinateur quantique, l’authentification ne l’est pas.

Est-ce grave ? Moins qu’il n’y paraît, et la hiérarchie des urgences est ici limpide. La collecte rétroactive menace la confidentialité : on enregistre aujourd’hui, on lit plus tard. Elle ne menace pas l’authentification d’une session passée : un attaquant qui saura forger une signature ECDSA en 2040 ne pourra pas revenir en 2026 usurper un serveur pendant une poignée de main terminée depuis quatorze ans. Le voyage dans le temps reste, à ce jour, hors du modèle de menace. L’authentification n’a besoin d’être post-quantique qu’à partir du moment où l’attaquant dispose de la machine. Il faudra être prêt avant, évidemment, mais la pression n’a rien de comparable.

Les signatures hybrides sont un autre métier

L’hybridation des signatures existe sur le papier et dans quelques profils, mais elle est nettement plus douloureuse. Les signatures post-quantiques normalisées sont beaucoup plus lourdes que leurs aînées sur courbe elliptique : on passe de quelques dizaines d’octets à plusieurs kilo-octets pour ML-DSA, davantage pour certaines variantes de SLH-DSA. Une chaîne de certificats en contient plusieurs, et hybrider revient à porter les deux jeux à la fois.

La question « comment combiner » y est aussi plus épineuse. Faut-il exiger que les deux signatures soient valides, ou qu’une seule le soit ? Comment empêcher qu’on retire l’une des deux pour présenter un objet mono-algorithme à un vérificateur trop accommodant ? Comment les formats de certificats et les politiques de vérification décrites dans le chapitre sur la signature numérique représentent-ils un objet doublement signé ? Il existe plusieurs réponses concurrentes, et aucune n’a l’évidence d’un mélange dans une dérivation.

L’hybride d’établissement de clés est facile parce qu’une KDF sait mélanger ; l’hybride de signature est difficile parce qu’une vérification doit trancher. Mélanger est à la portée de tous. Trancher, c’est autre chose, comme le savent les juges et les pâtissiers.

Le meilleur argument contre

La position inverse est tenue par des gens sérieux, pas seulement par des vendeurs pressés.

Tous les organismes n’ont pas fait le même choix. L’ANSSI et plusieurs de ses homologues européens recommandent l’hybridation pendant la transition, au moins pour l’établissement de clés. D’autres, notamment la NSA pour les systèmes de sécurité nationale américains, ont indiqué ne pas l’exiger et privilégier un passage direct aux algorithmes post-quantiques seuls. Ce ne sont pas des caprices, ce sont des arbitrages, et l’argument contre l’hybride mérite d’être formulé à son meilleur.

Il dit ceci : la complexité est elle-même une vulnérabilité, et l’hybride en ajoute pour une assurance dont la valeur est surestimée.

D’abord, ML-KEM n’est pas un nouveau venu mathématique : les réseaux sont étudiés depuis des décennies, la famille a résisté à un examen public intense, et les paramètres comportent des marges. Ensuite, chaque ligne ajoutée peut contenir une faille. Si l’effondrement mathématique de ML-KEM est improbable et qu’une faille dans un attelage de deux mécanismes plus un combinateur est, à l’échelle de l’écosystème, à peu près certaine, l’hybride échange peut-être un petit risque théorique contre un risque pratique plus grand.

Enfin, et c’est le plus fort, les solutions de transition ont une fâcheuse tendance à l’immortalité. Un hybride déployé « le temps de gagner en confiance » ne dit pas quand la confiance suffira. Qui décidera de retirer X25519, sur quel critère, à quelle date ? Si la réponse est « personne, jamais », on paiera l’hybride indéfiniment, et l’on maintiendra indéfiniment une courbe elliptique qui, dans le monde où l’hybride aura servi, ne protégera plus rien. Il n’y a rien de plus durable qu’une mesure provisoire, sinon peut-être une mesure provisoire qui a bien marché.

Cet argument est solide sur la surface d’implémentation et sur l’absence de critère de sortie. Il ne me convainc pas sur le fond, pour une raison d’asymétrie. Si l’on déploie ML-KEM seul et qu’une attaque classique le renverse, la collecte rétroactive fait qu’on a perdu tout ce qui a été échangé depuis le déploiement, sans recours. Si l’on déploie l’hybride et qu’une faille apparaît dans la partie ML-KEM, on corrige le code, et les échanges passés restent protégés par X25519 contre tout attaquant non quantique. La première défaillance est irréversible et silencieuse, la seconde réparable et généralement visible. Entre un risque plus rare mais définitif et un risque plus fréquent mais réparable, pendant la période où l’on sait le moins de choses sur la primitive, je prends le second, avec l’enthousiasme mesuré qui convient à un choix entre deux ennuis.

La position « pur post-quantique » deviendra d’ailleurs plus défendable à mesure que le temps passera sans attaque, ce qui est exactement le sujet de la section suivante.

Ce que ça dit de notre confiance

On arrive au fond du sujet, qui n’est pas technique. L’hybridation est un aveu. Elle écrit noir sur blanc, dans des normes : nous ne savons pas établir la sûreté d’une primitive autrement qu’en attendant qu’elle survive.

Ce n’est pas nouveau, c’est seulement rarement dit avec cette franchise. La confiance que nous accordons à AES, à SHA-2, à X25519 ne repose pas sur une preuve de sécurité au sens mathématique : il n’en existe pas pour ces primitives. Elle repose sur des réductions à des problèmes supposés difficiles, sur des analyses publiques, et surtout sur du temps passé sous le regard d’attaquants compétents sans que rien ne cède. Le temps est notre seul instrument de mesure, et il a le défaut d’être incompressible. Aucun budget, aucun comité, aucune feuille de route ne transforme cinq ans d’analyse en vingt ; on a essayé avec d’autres choses, les vins notamment, sans grand succès.

Le chapitre sur les problèmes difficiles explique ce qu’on suppose ; l’hybridation montre ce qu’on en pense. On suppose que le problème des réseaux structurés est difficile. On ne le croit pas encore assez pour lui confier seul ce qu’on veut protéger pendant des décennies. C’est la différence entre la foi et la religion : la seconde a des rites.

Une défiance à plusieurs étages

La défiance n’est d’ailleurs pas uniforme, et il vaut la peine de la ranger par étages.

On se méfie modérément du problème mathématique : les réseaux ont un long passé, et un effondrement général serait une surprise majeure. On se méfie davantage de la structure ajoutée : les variantes « module » et « anneau » introduisent de l’algèbre pour gagner en efficacité, et l’algèbre est le terrain de jeu préféré de la cryptanalyse. On se méfie nettement des paramètres : les estimations de sécurité concrètes reposent sur des modèles de coût d’attaque qui ont évolué et évolueront. On se méfie franchement des implémentations, pour les raisons dites plus haut.

L’hybride répond bien aux trois premiers étages et mal au quatrième. C’est une manière utile de le penser : un bon outil contre les surprises de cryptanalyse, un outil neutre à négatif contre les surprises de code.

Le problème de la sortie

Si l’hybride est une mesure de défiance, sa suppression devrait être une mesure de confiance. Or personne ne sait en écrire le critère. « Dix ans sans attaque significative » ? Il faudrait définir « significative », et l’on connaît des comités qui y ont passé leur retraite. « Quand l’ordinateur quantique existera » ? X25519 ne servira alors plus à rien contre celui qui le possède, mais continuera de protéger contre tous les autres, ce qui n’est pas négligeable. « Quand les implémentations seront mûres » ? C’est une propriété continue, sans seuil, comme la vieillesse.

Je soupçonne qu’on ne retirera pas X25519 par décision, mais par érosion. Une version future d’un protocole proposera un mode post-quantique seul, les clients l’adopteront par défaut, l’hybride deviendra un mode de compatibilité, puis un mode obsolète, puis une ligne dans un tableau que plus personne ne lit. C’est ainsi que meurent les algorithmes : pas par abrogation, par désuétude, et toujours plus lentement que prévu. Je parle en connaisseur.

Ce que je ne sais pas

Je ne sais pas évaluer la probabilité qu’une attaque classique affaiblisse sérieusement ML-KEM. Je sais qu’elle est jugée faible par ceux dont c’est le métier, et je sais que la même chose se disait de candidats tombés depuis. Les deux informations sont vraies en même temps, et c’est tout l’argument de l’hybride.

Je ne sais pas quelle part des défaillances de l’hybride viendra du code plutôt que des mathématiques. Mon intuition, exposée plus haut, est que ce sera l’écrasante majorité. C’est une intuition nourrie par l’histoire des implémentations cryptographiques, pas une mesure, et je ne connais pas d’étude qui l’ait mesurée pour les hybrides.

Je ne sais pas combien de temps les identifiants actuels resteront stables. Noms de groupes, ordre de concaténation, profils recommandés ont déjà changé une fois. Les brouillons de l’IETF et les recommandations des agences sont les sources à vérifier, pas ce texte, qui a le défaut de ne pas se mettre à jour tout seul.

Et je ne sais pas quand l’ordinateur quantique pertinent existera, ni s’il existera. Personne ne le sait. Ceux qui donnent une date vendent souvent quelque chose, et ceux qui jurent qu’il n’existera jamais n’auront, en cas d’erreur, que des excuses à offrir, ce qui ne déchiffre rien à l’envers.

Ce qui reste

L’hybridation n’est pas un compromis mou entre deux positions. C’est une construction précise qui répond à une situation précise : une menace connue contre l’ancien, une menace inconnue contre le neuf, et l’impossibilité d’attendre, puisque la collecte a déjà commencé.

Trois choses me semblent acquises. Que combiner n’est pas additionner : la robustesse tient à la construction qui mélange, pas aux ingrédients, et un protocole qui lie proprement son transcript fait l’essentiel du travail. Que le coût réel n’est pas dans les octets mais dans la négociation, la matrice de test, la compatibilité avec des équipements oubliés, et surtout dans la quantité de code cryptographique neuf posée sur le chemin de chaque connexion. Et que l’hybride assure contre la cryptanalyse, pas contre les bugs : il couvre la surprise mathématique et multiplie les occasions de surprise logicielle.

Reste une leçon plus large. Nous avons bâti un monde où la confiance dans une primitive ne s’obtient qu’en la laissant vieillir sous le feu, et où l’on n’a pas le loisir d’attendre qu’elle ait vieilli. L’hybride est la réponse d’ingénieur à ce dilemme : porter ceinture et bretelles parce qu’on ignore lequel des deux lâchera. C’est raisonnable. Il aurait seulement fallu le présenter pour ce que c’est, un aveu d’ignorance soigneusement construit, plutôt que comme une « solution résistante au quantique ». Les aveux d’ignorance bien construits sont ce que la cryptographie fait de mieux. C’est dommage qu’ils se vendent si mal ; c’est aussi, peut-être, ce qui les rend fiables.

🐝 Ce qui arrive si on s’en passe

Sans hybride, deux paris s’offrent, et tous deux se perdent en silence. Rester sur la seule courbe elliptique laisse chaque échange enregistré aujourd’hui en attente de lecture, sans que rien ne signale la collecte au moment où elle a lieu. Passer à la seule méthode post-quantique expose au sort de ses concurrents malheureux : une attaque classique publiée un matin rend lisible tout ce qui a transité depuis le déploiement, et aucune correction ne rattrape le passé. Même avec l’hybride, faute de vérifier ce qui est réellement négocié avec les clients, un déclassement par configuration ramène les connexions au seul algorithme ancien, poignée de main après poignée de main parfaitement correcte, sans qu’aucun journal s’en émeuve.

🦫 Explication de la marmotte 🍫

Pour protéger une connexion, deux machines doivent d’abord se mettre d’accord sur une clé secrète commune, sans que personne d’autre puisse la découvrir. La méthode actuelle repose sur un calcul avec des courbes elliptiques. Un futur ordinateur quantique assez puissant pourrait la casser, et comme des échanges enregistrés aujourd’hui pourraient être lus plus tard, le danger existe dès maintenant. Une méthode nouvelle, appelée ML-KEM, résiste à ce type d’ordinateur, mais elle est jeune : d’autres candidats de la même compétition ont été cassés avec des ordinateurs ordinaires. La solution hybride utilise donc les deux méthodes en même temps. Chacune produit un secret ; les deux secrets sont accolés et passés dans une fonction qui en tire les clés de la session, en tenant compte de tous les messages échangés. Tant qu’une seule des deux méthodes résiste, la clé reste secrète, à condition que la combinaison soit faite correctement. Les coûts sont réels : les messages grossissent d’environ mille octets, ce qui a fait échouer d’anciens équipements réseau ; les noms des variantes ont changé pendant la mise au point ; les serveurs doivent maintenir deux chemins, et un mauvais réglage peut revenir sans bruit à la seule méthode ancienne. Surtout, on ajoute du code neuf, qui peut contenir des erreurs ou laisser deviner des secrets par son temps de calcul. L’hybride protège contre une faiblesse mathématique, pas contre ces erreurs de programmation, ni la preuve d’identité du serveur, qui reste classique.

À lire aussi

• Dimensionner un HSM pour la migration post-quantiqueImpact des algorithmes post-quantiques sur la capacité, les performances et l'exploitation des modules cryptographiques matériels existants.
• Courbes elliptiques : compacité, validation et piègesRendre les courbes elliptiques utilisables sans excès d’algèbre, en insistant sur le choix de courbe, les encodages et les erreurs de validation.
• Évaluer la force d’une protectionExpliquer comment raisonner en bits de sécurité, en durée de confidentialité et en coût réel d’attaque, sans réduire la décision à la longueur d’une clé.

Pages voisines

La citent

• Dimensionner un HSM pour la migration post-quantique
• Protocole SSH, clés d'hôte, authentification et durcissement

Le post-quantique hybride

Elle cite

• ⇄Lien dans les deux sens :Récolter maintenant, déchiffrer plus tard
• ⇄Lien dans les deux sens :Établir une clé : Diffie-Hellman, KEM et HPKE
• ⇄Lien dans les deux sens :Informatique quantique : histoire, acteurs, usages et avenir
• ⇄Lien dans les deux sens :Intégrer la cryptographie post-quantique dans TLS
• ⇄Lien dans les deux sens :Préparer la migration post-quantique
• ANSSI
• Gouverner la cryptographie: inventaire, agilité et conformité
• Les problèmes difficiles qui rendent la clé publique possible
• Messageries, courrier sécurisé et groupes chiffrés
• NSA Cybersecurity

⇄ : les deux pages se citent l’une l’autre.