Résumé

  • La RFC 10042 enregistre trois méthodes SSH combinant ML-KEM avec P-256, P-384 ou X25519, puis produit un secret partagé à partir des deux résultats.
  • La présence du code ne suffit pas : il faut observer la méthode réellement négociée, les échecs et l'authentification de chaque connexion.

Deux algorithmes, une méthode négociée

La RFC 10042 vise le risque « collecter aujourd'hui, déchiffrer plus tard ». Elle définit mlkem768nistp256-sha256, mlkem1024nistp384-sha384 et mlkem768x25519-sha256. Chaque nom désigne une seule méthode SSH, mais exécute deux schémas : ECDH traditionnel et encapsulation ML-KEM.

Le client envoie ses éléments publics postquantiques et classiques concaténés. Le serveur renvoie un texte chiffré ML-KEM, sa clé publique traditionnelle, sa clé d'hôte et la signature de l'échange. Les longueurs attendues doivent être vérifiées et les erreurs prévues interrompent l'échange. Les secrets deviennent K = HASH(K_PQ || K_CL) avec des encodages de longueur fixe.

Ce sont des faits normatifs. L'inférence opérationnelle est différente : la migration n'est franchie que lorsque le nom hybride gagne la négociation et que l'échange complet réussit. Des politiques anciennes, un décalage de versions ou un réglage de repli peuvent encore sélectionner une méthode classique.

L'hybride ne remplace pas l'authentification

La clé d'hôte et sa signature restent dans la transcription. L'échange hybride ne corrige donc ni une mauvaise gestion des clés d'hôte, ni une décision laxiste de confiance, ni des identifiants compromis. La publication de la RFC ne prouve aucun déploiement particulier.

La RFC exige des paires éphémères ECDH et ML-KEM neuves à chaque connexion et interdit de réutiliser l'aléa des textes chiffrés ML-KEM. Les secrets ont des encodages fixes afin d'éviter des comportements de longueur variable susceptibles de créer des fuites temporelles.

Une taille bornée, un coût non nul

Les trois méthodes respectent les tailles minimales de paquet SSH. Les équipes doivent néanmoins mesurer compatibilité, latence, processeur, marge de capacité, erreurs et conditions de retour arrière. Les sources ne chiffrent pas ces coûts pour un parc donné.

Les bénéficiaires sont les sessions dont la confidentialité doit durer au-delà des hypothèses classiques actuelles. Le coût revient aux équipes qui maintiennent clients, serveurs, bastions, automatisation et bibliothèques. Le contre-factuel classique est plus simple mais n'apporte pas ML-KEM ; une solution uniquement postquantique supprimerait la couverture classique et n'est pas celle de la RFC.

Sources