La progression de la chaîne à chaque message et le renouvellement d’une époque post-quantique répondent à des aspects différents du problème du ratchet.
Un ratchet hybride post-quantique renouvelle les clés de messagerie à l’aide de données secrètes classiques et post-quantiques. Il vise à conserver une protection sous des hypothèses soigneusement définies si un composant devient vulnérable, tout en limitant au fil du temps les dégâts de certaines compromissions de clés.
Livara documente cette approche pour LVR1 avec P-256 et ML-KEM-768. Comprendre sa conception exige de distinguer l’établissement initial des clés, les mises à jour ordinaires de la chaîne de messages et les renouvellements post-quantiques périodiques. Ce ne sont pas une même opération effectuée à chaque message.
D’un secret partagé à des clés de message évolutives
Un mécanisme d’établissement de clés fournit aux participants des données secrètes utilisables dans un schéma de dérivation de clés. Un protocole de ratchet fait ensuite évoluer l’état et dérive les clés de message, au lieu de conserver une même clé de contenu pendant toute la conversation.
NIST FIPS 203 spécifie ML-KEM, notamment le jeu de paramètres ML-KEM-768. Il établit un secret partagé ; un chiffrement authentifié tel qu’AES-GCM chiffre la charge utile du message. L’authentification et la manière de combiner les composants relèvent du protocole dans son ensemble.
La présentation de la sécurité de Livara décrit un établissement hybride, des racines classiques et post-quantiques indépendantes, des chaînes unidirectionnelles d’envoi et de réception avançant avec les messages, et des mises à jour périodiques d’époque ML-KEM. Elle indique qu’une clé de message est combinée avec la racine post-quantique courante avant la protection du contenu et de l’en-tête.
Cette description ne doit pas être réécrite en « un nouvel échange P-256 et une nouvelle encapsulation ML-KEM ont lieu pour chaque message ». Une progression de chaîne peut être une étape de dérivation de clés relativement peu coûteuse.
Ce qu’une époque change
Une époque est une période de l’état du protocole associée à un renouvellement particulier. Répartir les messages d’établissement de clés plus volumineux entre les époques peut réduire le surcoût récurrent des communications, mais donne aussi aux règles de renouvellement une importance pour la sécurité.
Un évaluateur devrait poser les questions suivantes :
- Qu’est-ce qui déclenche une nouvelle époque : un compteur, le temps, une action du correspondant ou une autre condition ?
- Comment les identifiants d’époque et les données de clé sont-ils authentifiés ?
- Que se passe-t-il pour les messages retardés, dupliqués ou reçus dans le désordre ?
- Comment un client gère-t-il une mise à jour manquante ou un correspondant plus ancien incompatible ?
- Quels anciens secrets sont conservés pour les livraisons retardées, et quand sont-ils éliminés ?
Une implémentation doit fournir des réponses précises. Le mot « périodique » ne constitue pas à lui seul une spécification complète de récupération ou d’interopérabilité.
Quantifier la taille des primitives sans inventer un benchmark
FIPS 203 attribue à ML-KEM-768 une clé d’encapsulation de 1 184 octets et un texte chiffré de 1 088 octets. Il s’agit d’encodages de primitives, non de la taille totale d’un message ou d’un échange initial Livara. Les en-têtes du protocole, les signatures, le découpage en trames et la fréquence d’envoi de chaque valeur déterminent le trafic réel.
La taille des clés P-256 dépend également de leur représentation. Par exemple, un point de courbe compressé et un point non compressé ont des longueurs encodées différentes. Comparer une « taille de clé P-256 » non précisée à un texte chiffré ML-KEM ne constitue pas une analyse complète de la bande passante.
Pour évaluer le coût d’un ratchet, mesurez les octets par conversation et par époque, le temps CPU, la mémoire, les réveils radio et la latence de bout en bout sur des appareils représentatifs. Précisez les conditions de compilation et de réseau. Sans ces mesures, ni un « impact négligeable sur la batterie » ni un temps d’exécution universel inférieur à une milliseconde ne sont justifiés.
Confidentialité persistante et récupération après compromission
La confidentialité persistante vise à protéger les messages antérieurs après l’exposition de certains secrets ultérieurs, à condition que les anciens secrets requis aient été effacés. La sécurité après compromission concerne le rétablissement de la protection lorsqu’un attaquant ne contrôle plus le terminal et que de nouvelles données secrètes inconnues de l’attaquant entrent dans le protocole.
La spécification Double Ratchet explique ces distinctions et les limites de la récupération après intrusion. Un accès persistant par logiciel malveillant, un aléa manipulé ou un attaquant actif contrôlant les échanges concernés peuvent empêcher la récupération espérée. Envoyer un message de plus ne prouve ni qu’une session volée a été révoquée, ni qu’un téléphone compromis est sain.
Une construction hybride exige aussi une authentification et une combinaison solides. « L’attaquant doit casser les deux algorithmes » est une propriété visée sous les hypothèses de la construction, et non une affirmation inconditionnelle couvrant les bogues d’implémentation ou les terminaux malveillants.
Garder visibles les limites des fonctionnalités
Dans la documentation de Livara, les clés d’émetteur des groupes LGS1 sont distribuées via des sessions LVR1 entre paires de participants. Cela ne signifie pas qu’une chaîne d’émetteur de groupe soit structurellement identique au Double Ratchet d’une conversation directe. La page de sécurité actuelle exclut également du chiffrement de bout en bout les anciens groupes incompatibles et exige que les membres soient prêts avant la création d’un nouveau groupe chiffré.
Les pièces jointes possèdent leurs propres clés de contenu, transportées dans la conversation protégée. Les appels et l’enregistrement facultatif côté serveur nécessitent un examen séparé ; ne déduisez pas une protection post-quantique des médias du seul fait qu’un chemin de signalisation utilise une session hybride. Les canaux publics et les métadonnées opérationnelles sont hors du périmètre de confidentialité des contenus privés.
Qu’est-ce qui renforcerait la confiance ?
Recherchez une spécification versionnée, des tests d’interopérabilité et de cas d’échec, un examen indépendant et une relation claire entre le code source examiné et le client distribué. Les algorithmes normalisés apportent des éléments utiles sur les composants, pas une certification de leur composition.
Le Proof Lab de Livara démontre des primitives classiques sélectionnées et exclut explicitement la composition complète LVR1/LGS1 de ce banc d’essai local. Son modèle de menace reste un contexte indispensable. Ensemble, ces documents aident à formuler des questions ; ils ne doivent pas être présentés comme un substitut à une évaluation complète du protocole et de son implémentation.
