Chiffrement post-quantique d’OpenSSH
(openssh.com)- OpenSSH prend en charge des algorithmes post-quantiques pour se protéger contre les attaques d’ordinateurs quantiques
- Depuis la version 9.0, il applique par défaut l’algorithme sntrup761x25519-sha512 pour la connexion, et depuis la version 10.0, mlkem768x25519-sha256 est désormais le mode de connexion par défaut
- À partir de la version 10.1, un message d’avertissement apparaît quand un échange de clés non post-quantique est utilisé
- La plupart des algorithmes de signature existants (RSA, ECDSA, etc.) devraient aussi être pris en charge dans le futur
- Pour protéger le trafic existant en toute sécurité, les algorithmes post-quantiques doivent être appliqués à la fois côté serveur et côté client
Introduction du chiffrement post-quantique dans OpenSSH
OpenSSH prend en charge plusieurs algorithmes de négociation de clés qui restent sûrs face aux attaques d’ordinateurs quantiques
Il recommande d’utiliser ces algorithmes pour toutes les connexions SSH
Depuis OpenSSH 9.0 (2022), sntrup761x25519-sha512 fournit par défaut un algorithme de négociation de clés (KexAlgorithms) post-quantique, et mlkem768x25519-sha256 a été ajouté à partir de la version 9.9
Depuis OpenSSH 10.0, mlkem768x25519-sha256 est défini comme mode de chiffrement par défaut
Afin de favoriser l’adoption des algorithmes post-quantiques, OpenSSH affiche à partir de la version 10.1 l’avertissement suivant lorsqu’un échange de clés sans résistance post-quantique est utilisé
** WARNING: connection is not using a post-quantum kex exchange algorithm. **
This session may be vulnerable to "store now, decrypt later" attacks.
The server may need to be upgraded. See https://openssh.com/pq.html
Cet avertissement est affiché par défaut, mais il peut être désactivé via l’option WarnWeakCrypto de ssh_config(5)
Contexte
Un ordinateur quantique est un appareil qui calcule en codant l’information dans des états quantiques
Il peut résoudre rapidement certains problèmes mathématiques impossibles à traiter pour des ordinateurs classiques
Le principe mathématique de nombreux algorithmes de chiffrement repose sur des problèmes qui peuvent être aisément résolus par un ordinateur quantique
Si un ordinateur quantique suffisamment puissant (à un niveau cryptographiquement significatif) venait à apparaître, ces systèmes cryptographiques pourraient être compromis
Les algorithmes utilisés pour la négociation de clés et les signatures numériques sont particulièrement exposés
Bien que ces ordinateurs quantiques n’existent pas encore, les experts prévoient leur arrivée dans les 5 à 20 ans ou au milieu des années 2030
La protection de la confidentialité d’une connexion SSH repose sur la négociation de clés
Si un attaquant casse cet algorithme d’échange, il peut déchiffrer le contenu de toutes les sessions
En outre, même sans interception en temps réel, il est possible d’effectuer des attaques de type « store now, decrypt later » qui consistent à stocker des sessions chiffrées pour les déchiffrer plus tard quand un ordinateur quantique sera disponible
OpenSSH renforce donc la prise en charge du chiffrement post-quantique pour contrer ce type d’attaque
FAQ
Q : J’ai reçu un message indiquant qu’un avertissement est apparu dans SSH, que dois-je faire ?
- OpenSSH affiche un avertissement sur les connexions utilisant un chiffrement non sûr face au quantique à partir de la version 10.1
- Cela signifie que le serveur connecté ne prend pas en charge d’algorithme de négociation de clés post-quantique (mlkem768x25519-sha256, sntrup761x25519-sha512)
- La meilleure solution consiste à mettre à jour le serveur vers OpenSSH 9.0 au minimum (9.9 pour le second cas) et à vérifier que les algorithmes concernés ne sont pas désactivés dans KexAlgorithms
- Si la mise à jour du serveur n’est pas possible, ou si vous acceptez ce risque, vous pouvez aussi masquer l’avertissement en activant l’option WarnWeakCrypto dans ssh_config(5)
- Si nécessaire, appliquez ce réglage pour un hôte spécifique comme suit
Match host unsafe.example.com WarnWeakCrypto no
Q : Pourquoi se préparer maintenant alors qu’il n’existe pas encore d’ordinateur quantique ?
- C’est en raison de l’attaque de type « store now, decrypt later » mentionnée plus haut
- Le trafic que vous envoyez aujourd’hui pourrait être déchiffré plus tard, il est donc recommandé d’utiliser dès maintenant une connexion sûre vis-à-vis du quantique
Q : Vous avez dit que les algorithmes de signature étaient aussi risqués, pourquoi ce n’est pas prioritaire ?
- La plupart des algorithmes de signature actuels (RSA, ECDSA, etc.) peuvent également être neutralisés par un ordinateur quantique
- En revanche, dans ce cas, les sessions de trafic précédentes ne sont pas stockées en vue d’un futur déchiffrement
- La priorité pour les signatures, c’est de retirer progressivement les anciennes clés de signature au fur et à mesure que l’arrivée d’un ordinateur quantique se rapproche
- OpenSSH prévoit également de prendre en charge des algorithmes de signature post-quantiques à l’avenir
Q : Pourquoi c’est important si l’on pense que les ordinateurs quantiques resteront impossibles ?
- Certains considèrent qu’un ordinateur quantique ne sera jamais réalisable, mais les obstacles actuels sont un problème d’ingénierie, non de physique fondamentale
- Si les ordinateurs quantiques deviennent possibles, les mesures prises aujourd’hui protégeront des quantités massives de données utilisateurs
- Même si l’on s’avérait finalement en avance, il ne s’agit que d’une migration vers un chiffrement mathématiquement plus robuste
Q : Les algorithmes post-quantiques ne pourraient-ils pas aussi être vulnérables ?
- OpenSSH adopte une approche prudente
- Il n’a sélectionné que des algorithmes qui ont fait l’objet d’un examen approfondi ces dernières années, mais il reste possible qu’une nouvelle méthode d’attaque soit découverte
- Pour s’en prémunir, il a retenu des algorithmes avec une marge de sécurité confortable, ce qui laisse une forte probabilité de rester opérationnellement sûr, même s’ils s’avéraient plus faibles que prévu
- En outre, les algorithmes post-quantiques d’OpenSSH sont tous de type "hybride"
- Par exemple, mlkem768x25519-sha256 combine ML-KEM (post-quantique) et l’algorithme classique ECDH/x25519
- Ainsi, même si l’algorithme post-quantique est compromis à l’avenir, le niveau de sécurité au moins équivalent à l’existant est conservé
1 commentaires
Avis Hacker News
Les points importants sont cachés en bas de la page. Tous les algorithmes post-quantiques appliqués à OpenSSH sont en mode « hybride », combinant en même temps un algorithme d\u00e9change de cl3s post-quantique (par ex. ML-KEM) et une m5ode classique (x25519). En utilisant les deux algorithmes ensemble, mm me si l\u2019algorithme post-quantique venait plus tard cass, la s curit au moins quivalente a celle classique est prserv . Le point cl que l\u2019hybridation ne fait pas perdre de s curit par rapport l\u2019existant est essentiel.
L\u2019approche hybride a l\u2019avantage que, si un des algorithmes est compromis, l\u2019autre continue d\u2019offrir de la rsilience. En revanche, cela double, voire plus, le risque de bugs d\u2019implmentation et d\u2019expositions de vulnrabilits aux canaux secondaires (side-channel). En pratique, la menace quantique n\u2019est pas encore relle, mais ces bugs et vulnrabilits sont des enjeux actuels. Toutefois, au vu des énormes efforts de recherche et de validation de scurit des dix dernires annes, ce compromis me semble suffisamment acceptable.
L\u2019industrie dans son ensemble va majoritairement vers une architecture hybride PQC-clasique. Tant qu\u2019un ordinateur quantique capable de casser vraiment RSA, ECC et DH n\u2019apparat pas, la mthode conservatrice de mettre deux serrures en parallle semble le choix le plus s pour le moment. En revanche, les exigences algorithmiques CNSA 2.0 de la NSA (lien) n\u2019adoptent que les algorithmes uniquement post-quantiques et disent explicitement dans la FAQ que le mode hybride n\u2019est pas n cessaire.
Au vu du papier publi rcemment, la fois partisan et amusant (lien), je me demande si l\u2019adoption de la crypto post-quantique cette vitesse est vraiment ns . Je m\u2019informe que les matriau de cl post-quantique sont beaucoup plus volumineux qu\u2019avant, ce qui augmente beaucoup le trafic r seau et la consommation CPU.
Ce texte ne traite de l\u2019application de la PQC qu\u2019 l\u2019 hangement de cls dans les connexions SSH, donc la surcharge est assez faible. Et comme l\u2019indique aussi la FAQ, la question du « pourquo\u00a0quoi se prparer alors que l\u2019ordinateur quantique n\u2019existe pas encore ? » s\u2019explique par le risque de dchiffrement ult r (« store now, decrypt later \u00e0 propos du trafic envoy\u001 aujourd\u2019hui ). Certains disent que l\u2019ordinateur quantique est impossible reliser; pour moi, l\u2019obstacle principal n\u2019est pas physique mais d\u2019ingnierie. Si un tel ordinateur quantique devenait reliste, on pourrait protger une quantit gigantesque de donnes utilisateurs. Je recommande aussi la lecture de ce papier pour le plaisir, mais je ne l\u2019ai pas pris avec un cynisme excessif.
Il est amusant, ce papier. Mais si c\u2019 une critique s\u2019era , ce serait comparable la plainte de 1951 selon laquelle un transistor ne sait pas calculer π. Le besoin de PQC d\u00e9pend de deux questions : 1) penses-tu qu\u2019un ordinateur quantique ne viendra jamais de ton vivant ? 2) quelle importance accordes-tu la sensibilit des donnes dont tu as la garde. Si ces deux points te sont indiffrents, la PQC peut une perte de temps. Mais si je suis responsable de la maintenance d\u2019un systme cryptographique, je ne pense pas avoir le droit d\u2019ignorer la valeur des donnes utilisateurs.
Les discussions en cours portent surtout sur l\u2019 hange de cls. L\u2019change n\u2019a pas lieu souvent, et la surcharge est globalement sans enjeu. En bref : 1) Les algorithmes PQ (signature, change de cls) ont des tailles de cls bien plus importantes, mais les performances de calcul sont mme plus rapides ou comparables. 2) La plupart des protocoles comme TLS, SSH n\u2019effectuent l\u2019 hange de cls qu\u2019au dmarrage initial ; la grande taille des cls n\u2019est donc pas vraiment problmatique. Il peut toutefois y avoir des questions de compatibilit, par exemple des dpassements de MTU TCP. Dans des protocoles qui font un hange de cls trs frquent, comme Signal ou MLS, la PQ n\u2019est utilis qu parfois (rfrence). 3) Pour TLS, c\u2019est plutt la taille des messages de signature qui pose problme, car il y a beaucoup de signatures dans la chane de certificats. C\u2019est pourquoi l\u2019adoption de signatures PQ en TLS se heurte plus de questions de faisabilit (rfrence).
En plus des informations publiques, le fait que nos agences de renseignement recommandent l\u2019adoption de la PQ pour des systmes qui n\u2019ont pas besoin de secret plus de 20 ans est un facteur de confiance. Pour rfrence : en 2014, l\u2019agence de renseignement n rlandaise a mentionn qu\u2019une apparition entre 2030 et 2040 semblait peu probable, et que celle-ci serait peu probable mais non n gligeable ; en 2021, elle disait qu\u2019une apparition d\u2019ici 2030 restait peu probable mais qu\u2019il ne fallait pas la repousser. En 2025, 18 pays ont publi un avis conjoint pour se prparer d\u00e9j aux attaques « store now, decrypt later » d\u2019ici 2030 (document1, document2, dclaration conjointe)
L\u2019application macOS Secretive stocke les cls SSH dans le Secure Enclave. D\u2019apr s l\u2019algorithme pris en charge, elle utilise ecdsa-sha2-nistp256, et le Secure Enclave semble ne pas prendre en charge les algorithmes post-quantiques. Je me demande s\u2019il serait possible de les empaqueter en mode hybride, par exemple mlkem768 ecdsa-sha2-nistp256, avec la partie ECDSA seule traite par le SE (Secretive GitHub).
Je pense que l\u2019outil ssh-audit (lien) devrait ajouter une vrification pour les algorithmes thoriques (PQC hybrides). J\u2019ai l\u2019impression qu\u2019en fixant un seul algorithme, le grade A s\u2019affiche encore. Je suis actuellement en train d\u2019utiliser uniquement ChaCha.
Je m\u2019interroge sur l\u2019existence d\u2019algorithmes hybrides PQC conformes FIPS 140-3 pour OpenSSH.
L\u2019approche consistant se prparer d\u00e9j est raisonnable. Je pense mme plus, quand le changement de cls est une opration relativement mineure. Entre les deux options, laquelle est plus forte, la 512 n\u2019est-elle pas plus solide ?
Les deux algorithmes sont compltement diffrents. mlkem768x25519-sha256 combine l\u2019 hange de cls ML-KEM post-quantique et l\u2019ECDH/x25519 classique. Ainsi, si l\u2019un des deux est cass, le niveau classique est maintenu. La version 256 (mlkem768) a d\u2019ailleurs ru aprs la version 512 (sntrup761). OpenSSH prend en charge sntrup761x25519-sha512 depuis la version 9.0 et mlkem768x25519-sha256 depuis 9.9.
Les problmes de taille 256 bits / 512 bits ne sont absolument pas urgents. Aucune machine ne dispose encore de l\u2019 rreur nt n st possible, encore moins de l\u2019 au de puissance pour explorer un espace de 128 bits. Le timing n\u2019est pas .
ML-KEM est actuellement le choix par dfaut le plus raisonnable. Le standard de l\u2019industrie converge vers cette direction.
J\u2019envisage de migrer mon application de microblog/chat bas sur terminal vers la scurit post-quantique. J\u2019y ai rflchi davantage aprs plusieurs visionnements de l\u2019interview de Paul Durov et aprs avoir entendu ce qu\u2019il a vu traverser.
Je me demande lequel est le meilleur entre sntrup761x25519-sha512 et mlkem768x25519-sha256.
MLKEM768 offre de meilleures performances et des cls plus petites. SNTRUP761 offre des hypothses de scurit plus fortes et une meilleure rsistance face d\u2019ventuelles attaques cryptographiques.
NTRU Prime (sntrup) a t inclus pour des raisons historiques (mlkem n\u2019existait pas l\u2019). L\u2019un ou l\u2019autre convient, mais sntrup ressemble un choix par dfaut transitoire, un peu comme l\u2019ancien comportement par dfaut de GPG avec CAST.
Quand des certificats PQ (cls d\u2019authentification hte/utilisateur) seront-ils disponibles ?
Anticiper ce type d\u2019initiative est une bonne chose. Mme si des alternatives plus ses apparaissent plus tard, je pense que ce type d\u2019effort ne sera pas vain tant qu\u2019il n\u2019est pas pire qu\u2019aujourd\u2019hui.