Résumé

  • La RFC 10042, document informatif de l'IETF signé par Panos Kampanakis, Douglas Stebila et Torben Hansen, définit trois échanges de clés SSH associant ML-KEM à P-256, P-384 ou X25519.
  • La réponse hybride transporte toujours la clé publique de l'hôte serveur et une signature. L'authentification de l'utilisateur intervient ensuite dans un protocole distinct : échange de clés, identité du serveur et identité de l'utilisateur exigent donc trois preuves.
  • Un exemple SFTP publié par AWS rend la séparation visible dans le journal : algorithme hybride, algorithme et empreinte de clé d'hôte, puis authentification de l'utilisateur par clé publique.

Dans un journal produit par ssh -v, le mot « key » revient souvent. Cette répétition peut donner l'impression qu'une seule mécanique décide de tout. Or les lignes ne parlent pas des mêmes clés, ni des mêmes acteurs, ni du même risque.

La première ligne utile indique la méthode d'échange choisie. Une autre annonce l'algorithme de la clé d'hôte et son empreinte. Plus tard, une fois les clés de transport en service, le serveur indique par quelle méthode l'utilisateur a été authentifié. Le fichier transféré passe par une seule session, mais le contrôle n'a jamais été unique.

La RFC 10042 renforce la première étape. Publiée en août 2026 dans la catégorie Informational, elle décrit mlkem768nistp256-sha256, mlkem1024nistp384-sha384 et mlkem768x25519-sha256. Chaque méthode combine un secret issu de ML-KEM avec un échange elliptique classique. La session ne dépend ainsi ni exclusivement de la cryptographie traditionnelle, ni exclusivement du mécanisme post-quantique récent.

L'objectif opérationnel est clair. Un adversaire peut conserver aujourd'hui des flux chiffrés dans l'espoir de casser plus tard l'établissement classique des clés. L'hybridation réduit ce risque pour le secret de transport. Elle ne répond toutefois pas à toutes les questions que pose une connexion SSH.

La signature de l'hôte reste dans le message

La frontière apparaît dans la structure même de la RFC. Le client envoie ses matériaux éphémères classique et post-quantique. Le serveur renvoie son chiffré ML-KEM et sa valeur elliptique, mais aussi K_S, sa clé publique d'hôte, ainsi qu'une signature sur le hash d'échange.

Le secret final K est le hash de la concaténation du secret post-quantique et du secret classique. Le hash d'échange incorpore les versions des deux logiciels, leurs messages de négociation, la clé d'hôte, les valeurs hybrides et K. Le serveur signe ce hash avec la clé privée associée à son identité d'hôte.

Ces opérations sont reliées sans devenir équivalentes. L'échange hybride produit le matériau secret qui servira au chiffrement. La signature d'hôte engage une identité de serveur sur le transcript. Le client doit encore savoir pourquoi il fait confiance à la clé présentée.

La RFC 4253 négocie d'ailleurs deux listes différentes : kex_algorithms pour l'échange et server_host_key_algorithms pour la clé du serveur. Une combinaison compatible doit exister. Ensuite, le client compare la clé d'hôte avec sa base locale, une empreinte épinglée ou une chaîne de certificats. Accepter la clé sans la vérifier expose toujours à une attaque active, même si le secret de session contient une excellente contribution ML-KEM.

Une preuve d'identité de l'hôte doit donc conserver l'algorithme de signature, l'empreinte ou le certificat, l'origine de la confiance, le résultat de la vérification et les règles de rotation. Le seul nom de la méthode hybride n'en dit rien.

L'utilisateur n'est pas l'hôte

Après le transport vient un retournement de perspective. Le client a cherché à reconnaître le serveur ; le serveur doit maintenant décider si un utilisateur déterminé peut accéder au service demandé.

La RFC 4252 place ce protocole d'authentification au-dessus de la couche de transport. Elle impose le support de la méthode publickey et décrit aussi le mot de passe et l'authentification fondée sur l'hôte. Dans le cas d'une clé publique, le serveur vérifie une signature, mais il vérifie surtout si cette clé est admise pour ce nom d'utilisateur et si d'autres facteurs sont requis.

Employer une signature aux deux endroits ne confond pas les propriétaires. La clé d'hôte va du serveur vers le client. La clé de l'utilisateur va du client vers le serveur. Les fichiers authorized_keys, l'annuaire d'identité, les comptes désactivés, les commandes forcées, les restrictions SFTP et les privilèges répondent à des politiques qui ne figurent pas dans mlkem768x25519-sha256.

Une migration peut donc progresser par étapes cohérentes : d'abord les bibliothèques et préférences KEX, ensuite les signatures d'hôte, puis les identités et automatismes utilisateurs. L'erreur n'est pas de procéder par étapes. Elle consiste à présenter la réussite de la première comme la preuve des deux suivantes.

Le journal AWS sépare les colonnes

Un article AWS sur SFTP fournit un exemple particulièrement instructif. Le texte de 2023 utilisait encore des noms expérimentaux fondés sur Kyber. Une mise à jour datée du 5 septembre 2025 précise que deux politiques AWS Transfer Family sont passées à ML-KEM et prennent en charge les trois noms repris dans la RFC 10042.

Il ne faut pas rebaptiser rétroactivement l'ancienne trace en session RFC 10042. Sa valeur est ailleurs : elle montre comment lire le résultat. Le journal affiche d'abord la méthode hybride, puis ssh-ed25519 pour la clé d'hôte avec une empreinte, et seulement plus tard une authentification de l'utilisateur par publickey. Enfin, le sous-système SFTP s'ouvre.

On peut transformer cette chronologie en trois questions reproductibles :

  1. Quelle méthode les deux implémentations ont-elles réellement sélectionnée ?
  2. Quelle clé d'hôte a signé l'échange, et quelle règle a conduit le client à la reconnaître ?
  3. Quelle identité utilisateur a été admise, pour quel compte et avec quelle autorisation ?

Le mot « connecté » ajoute une preuve de fonctionnement, pas une garantie sur les droits de chaque fichier, son chiffrement au repos, les journaux, les sauvegardes ou le rétablissement après incident.

Cette transition de Kyber expérimental vers les noms ML-KEM rappelle aussi la dimension de cycle de vie. Clients, serveurs, appareils embarqués et outils d'automatisation n'évoluent pas au même rythme. L'ordre des préférences, la version des bibliothèques et les replis de compatibilité déterminent la méthode réellement exécutée. L'inscription chez l'IANA avec la mention SHOULD offre un repère d'interopérabilité ; elle ne mesure pas le déploiement mondial.

La valeur d'une limite bien tenue

Amazon Science présente Panos Kampanakis comme principal security engineer chez AWS, actif en cryptographie appliquée, automatisation de la sécurité et normalisation. Dans un entretien AWS de 2023, il recommandait d'inventorier les usages de cryptographie asymétrique, de mesurer l'impact des nouveaux algorithmes sur des protocoles tels que SSH et de préserver l'agilité algorithmique. Il distinguait également la preuve de concept du soutien durable à grande échelle.

Ce parcours éclaire le document sans créer une paternité individuelle. Douglas Stebila et Torben Hansen sont co-auteurs. La RFC remercie des contributeurs liés à AWS, OpenSSH, PuTTY et à la revue du mécanisme. NIST a normalisé ML-KEM ; le processus IETF et le registre IANA fournissent les coordonnées communes.

La force de la RFC 10042 vient de sa précision : messages, combinateur, encodages, contrôles de longueur, clés éphémères par connexion, interdiction de réutiliser l'aléa du chiffré et règles d'abandon. Elle transforme une intention générale en contrat testable entre implémentations.

Le principe de spécification initiale minimale de Heng Lu s'applique directement. Il n'est pas nécessaire que la RFC gère aussi tous les magasins de confiance, annuaires de comptes et procédures de reprise. Elle doit définir le mécanisme commun le plus étroit, tandis que les opérateurs conservent leurs décisions locales.

La primauté du code en fonctionnement complète cette discipline. Une réception exploitable retient les versions du client et du serveur, les listes offertes et la méthode sélectionnée, l'algorithme et l'empreinte d'hôte, la décision de confiance, le chiffrement et le MAC, SSH_MSG_NEWKEYS, la méthode utilisateur, l'autorisation, le canal ouvert, le rekey, le repli et les échecs.

La RFC 10042 rend la première preuve plus forte. La bonne gouvernance consiste à ne pas la copier dans les deux cases qui attendent encore leurs propres résultats.

Sources