Post-quantique : .NET 11 RC2 ajoute le ML-KEM composite, encore expérimental
La version candidate 2 de .NET 11, publiée le 13 octobre, introduit une API expérimentale de ML-KEM composite. Elle combine un algorithme post-quantique et un algorithme classique dans un même échange de clés.
Publication automatique. Cet article a été rédigé par une intelligence artificielle, puis contrôlé par un second modèle d’IA qui vérifie les faits sur les sources primaires. Il a été publié sans relecture humaine préalable.
Microsoft a publié le 13 octobre la deuxième version candidate (RC2) de .NET 11, sa plateforme de développement. La liste des nouveautés mentionne des API expérimentales de ML-KEM composite et de HPKE. Pour les développeurs .NET, c'est un pas de plus vers la cryptographie post-quantique hybride, celle qui associe un algorithme résistant aux ordinateurs quantiques et un algorithme classique.
Ce que contient la RC2
Selon les notes de version des bibliothèques .NET, la nouvelle classe CompositeMLKem combine un mécanisme d'encapsulation de clés post-quantique, ML-KEM (normalisé par le NIST dans FIPS 203), et un mécanisme classique. Les deux contribuent au secret partagé. Si l'un des deux est un jour cassé, l'autre continue de protéger l'échange. La méthode CompositeMLKem.IsAlgorithmSupported permet de vérifier si une combinaison donnée est disponible. La fonction n'arrive que sur les plateformes qui gèrent déjà ML-KEM.
Il faut nuancer sur trois points :
- Statut expérimental : pour utiliser l'API, il faut désactiver l'avertissement de diagnostic
SYSLIB5006. Son interface pourrait donc encore évoluer. - HPKE pas encore post-quantique : l'implémentation de HPKE (Hybrid Public Key Encryption, chiffrement hybride à clé publique) ne gère dans la RC2 que les suites classiques fondées sur Diffie-Hellman. Les suites ML-KEM ne sont pas encore prises en charge. Cette API est elle aussi expérimentale (
SYSLIB5009). - CMS :
EnvelopedCmssait désormais chiffrer et déchiffrer avec ML-KEM, mais uniquement en ML-KEM pur et seulement hors de Windows.
Un standard IETF presque finalisé
Le ML-KEM composite repose sur un brouillon de l'IETF, l'organisme qui normalise les protocoles d'Internet. Ce texte, draft-ietf-lamps-pq-composite-kem, en est à sa version 23, mise à jour le 14 octobre. Il est en fin de parcours de normalisation mais n'est pas encore publié comme RFC. Il définit douze combinaisons qui associent ML-KEM-768 ou ML-KEM-1024 à RSA, aux courbes elliptiques NIST ou Brainpool, ou à X25519 et X448. L'approche hybride correspond aux recommandations de l'ANSSI, qui préconise d'associer algorithmes post-quantiques et classiques pendant la transition.
Pour rappel, .NET 10 proposait déjà les classes MLKem, MLDsa, SlhDsa et CompositeMLDsa (signatures composites). Selon Duende Software, seule MLKem y était considérée comme stable. Ces fonctions exigent Linux avec OpenSSL 3.5 ou ultérieur, ou un Windows dont la bibliothèque cryptographique CNG gère la cryptographie post-quantique. macOS n'était pas pris en charge dans .NET 10.
Que faire ?
- Tester sans déployer : la RC2 dispose d'une licence « go-live », mais une API expérimentale n'a pas sa place dans du code de production à longue durée de vie.
- Inventorier les usages de RSA et d'ECDH dans vos applications .NET, pour savoir où l'hybride pourra s'insérer.
- Vérifier les plateformes cibles (version d'OpenSSL, version de Windows) avec les méthodes
IsSupportedavant de compter sur ces API.
Méthode : article rédigé par intelligence artificielle à partir de sources publiques, faits vérifiés par un second modèle d’IA indépendant, publié automatiquement sans relecture humaine préalable, sous la responsabilité éditoriale de Frédéric LENQUETTE. Une erreur ? Signalez-la.
Partager cet article
