L’avancée utile est un nouvel outil pour la confidentialité à long terme. Sa valeur dépend de l’intégration, de l’implémentation et des limites opérationnelles.
ML-KEM-768 aide deux parties à établir un secret partagé qui peut ensuite servir à protéger des messages. C’est un composant d’un système de messagerie, pas un protocole de conversation complet, un algorithme de chiffrement des messages ni un certificat garantissant la sécurité d’une application.
Le NIST a publié FIPS 203 le 13 août 2024, standardisant ML-KEM et ses jeux de paramètres 512, 768 et 1024. Leur sécurité repose sur des problèmes fondés sur les réseaux euclidiens que l’on estime résistants aux attaques quantiques. Cette résistance estimée est une hypothèse de sécurité étayée par des analyses, pas une promesse qu’aucune faiblesse future n’est possible. NIST FIPS 203.
Où se place un KEM dans une conversation chiffrée ?
Une façon utile de lire une affirmation sur le chiffrement consiste à suivre le matériel de clé :
- Authentifier l’interlocuteur prévu. Un échange de clés avec un imposteur reste un échange avec la mauvaise personne.
- Établir du matériel secret partagé. Un KEM apporte un secret par encapsulation et décapsulation.
- Dériver des clés pour leurs usages particuliers. Une fonction de dérivation de clés sépare le matériel utilisé par les différentes parties du protocole.
- Chiffrer et authentifier les messages. Un schéma de chiffrement authentifié protège le contenu et détecte les modifications non autorisées.
- Gérer la session dans le temps. Rotation et suppression des clés, changements d’appareils et récupération déterminent ce qu’une compromission ultérieure peut exposer.
Ces étapes expliquent pourquoi une norme portant sur la deuxième étape ne peut pas valider toute l’application. La FAQ post-quantique du NIST fournit du contexte pour le déploiement des nouvelles normes.
Pourquoi combiner ML-KEM avec un accord de clés classique ?
Une conception hybride utilise un composant post-quantique aux côtés d’un composant classique, comme Diffie–Hellman sur courbes elliptiques. L’objectif est d’éviter de dépendre exclusivement de l’un ou l’autre ensemble d’hypothèses pendant la transition.
L’affirmation de sécurité concerne le combinateur et le protocole complets, pas simplement une liste de deux algorithmes. Les évaluateurs doivent savoir quelles entrées sont authentifiées, comment elles sont encodées et combinées, quel contexte est lié à la dérivation et ce qui se passe lorsqu’un composant échoue. Concaténer des secrets sans construction spécifiée n’est pas un argument de sécurité.
Pour les utilisateurs, la question pratique n’est pas « La page des paramètres dit-elle résistant au quantique ? », mais « Quelles conversations et versions utilisent réellement cette construction, et quelles preuves soutiennent cette affirmation ? ».
Ce que Livara documente
La documentation de sécurité de Livara décrit des sessions LVR1 de conversation directe utilisant du matériel classique P-256 et ML-KEM-768, avec AES-256-GCM pour le contenu. Elle décrit les groupes privés LGS1 comme des chaînes d’expéditeur distribuées via des sessions LVR1 entre paires. Ce sont des couches différentes : un message de groupe ordinaire n’est pas nécessairement un nouvel échange ML-KEM pour chaque destinataire.
Lisez cette documentation comme la description du développeur. Nommer des primitives standardisées ne démontre pas que la composition propre à Livara a été auditée indépendamment ni que chaque build installé l’implémente correctement. Le Proof Lab limite explicitement sa démonstration dans le navigateur : elle n’exécute pas les mécanismes ratchet LVR1/LGS1 complets et ne constitue pas un audit du protocole.
Ce que la protection post-quantique ne couvre pas
| Question | Pourquoi ML-KEM seul n’y répond pas |
|---|---|
| Un destinataire peut-il copier mon message ? | Le destinataire reçoit du contenu lisible. |
| Mon appareil est-il exempt de logiciel espion ? | L’intégrité du terminal est une hypothèse de confiance distincte. |
| Les sauvegardes sont-elles protégées ? | Les clés de sauvegarde et les règles de récupération nécessitent leur propre conception. |
| Les changements de membres d’un groupe sont-ils sûrs ? | Les règles d’authentification, d’appartenance au groupe et de renouvellement des clés comptent. |
| Le service conserve-t-il des métadonnées ? | Le chiffrement du contenu ne masque pas automatiquement le routage ou les horaires. |
| Un appel est-il protégé comme une conversation textuelle ? | La signalisation et les médias d’appel peuvent utiliser des protocoles différents. |
Le modèle de menace de Livara distingue également les conversations privées des canaux publics et reconnaît l’exposition au niveau des appareils. N’étendez pas une affirmation concernant les conversations directes à tous les usages du produit.
Liste de contrôle pour l’acheteur d’une « messagerie FIPS 203 »
Demandez le jeu exact de paramètres et la version du protocole ; une description de l’authentification de l’interlocuteur et de la combinaison des clés ; les versions clientes prises en charge ; le comportement avec des clients incompatibles ; et des tests ou constats d’examen liés à l’implémentation distribuée. Si un fournisseur revendique une validation FIPS, demandez l’enregistrement de validation pertinent et son périmètre. Utiliser un algorithme décrit dans une publication FIPS ne prouve pas, à lui seul, la validation du produit ou du module.
Ne déduisez pas l’autonomie, le débit ou la réactivité de l’application du nom du paramètre. Cela nécessite des mesures précisant l’appareil, le build et la charge de travail.
L’avancée utile pour la messagerie est un nouvel outil de confidentialité à long terme. Sa valeur dépend de l’intégration, de l’implémentation et des limites opérationnelles, pas du remplacement d’une étiquette marketing par une autre.
