Les préclés résolvent un problème de synchronisation lors de l’établissement d’une session. Elles ne remplacent ni un canal de communication ni une gestion des clés bien documentée.
Un destinataire hors ligne peut recevoir un message chiffré plus tard parce que son appareil a publié à l’avance du matériel de clé publique. L’expéditeur a toujours besoin d’un service de livraison joignable ; « chiffrement asynchrone » ne signifie pas que les messages traversent une panne réseau ou apparaissent instantanément sur un téléphone déconnecté.
Les conceptions post-quantiques étendent cette idée avec un mécanisme d’encapsulation de clés. Les questions importantes concernent l’établissement du secret initial, le retrait des anciennes clés privées et la manière dont les messages suivants renouvellent la sécurité.
Les préclés résolvent un problème de synchronisation
Imaginez que Maya soit hors ligne lorsque Sam commence une nouvelle conversation. L’appareil de Maya a précédemment téléversé des préclés publiques. Sam peut récupérer ce matériel, effectuer la partie expéditeur de l’accord de clés et envoyer un premier message chiffré. Maya le traite après sa reconnexion, à l’aide de clés privées conservées sur son appareil.
Le serveur fournit donc des informations publiques et met des données chiffrées en attente ; il n’a pas besoin de posséder le secret de messagerie qui en résulte. La spécification X3DH de Signal est une description primaire de cette conception asynchrone. Une préclé signée et une préclé à usage unique ont des durées de vie et des rôles différents ; « préclé » ne désigne pas un mot de passe secret envoyé au serveur.
Pour une conversation déjà établie, l’application peut utiliser l’état de session existant plutôt que répéter la configuration initiale pour chaque message. Démarrer une session et faire évoluer ses clés de message sont deux opérations distinctes.
Ce qu’ajoute un KEM post-quantique
Un mécanisme d’encapsulation de clés comporte trois opérations fondamentales : générer des clés, encapsuler avec une clé publique et décapsuler avec la clé privée correspondante. L’encapsulation produit à la fois un secret partagé et un texte chiffré. Le texte chiffré peut être transmis plus tard ; le secret lui-même n’est pas envoyé en clair.
La norme NIST FIPS 203 standardise ML-KEM. Pour ML-KEM-768, la clé publique d’encapsulation fait 1 184 octets, le texte chiffré 1 088 octets et le secret partagé 32 octets. Ce sont des tailles au niveau de l’algorithme, pas la taille d’un paquet de messagerie complet. Les signatures, les clés classiques, les identifiants et l’encadrement du transport ajoutent du volume ; une clé publique mise en cache peut ne pas accompagner chaque message.
Dans une construction hybride, un protocole combine du matériel secret classique et post-quantique selon un schéma défini de dérivation des clés. Juxtaposer des noms d’algorithmes ne démontre pas que leur composition est sûre. La liaison aux identités, la validation, la séparation des domaines et la gestion des échecs doivent être spécifiées et examinées.
Un exemple : PQXDH, pas un modèle universel
La spécification PQXDH de Signal décrit des préclés post-quantiques signées à usage unique et une clé signée de dernier recours. L’expéditeur vérifie les signatures fournies, effectue l’accord de clés et joint le texte chiffré du KEM et les identifiants des clés au premier message chiffré. Le destinataire dérive ensuite le même secret et traite le message.
La clé de dernier recours permet l’établissement lorsque les clés KEM à usage unique ne sont pas disponibles, mais l’analyse en cas de compromission n’est pas identique. La suppression et la rotation des clés privées influencent la protection des sessions antérieures. La spécification distingue aussi la confidentialité persistante post-quantique de l’authentification face à un attaquant quantique actif. Ces détails ne doivent pas être remplacés par « la solution de repli n’a aucun coût de sécurité ».
PQXDH est une construction précisément spécifiée. Ses courbes, signatures et paramètres exacts ne doivent pas être repris dans la description d’un autre produit, sauf si ce produit les documente.
Un mécanisme ratchet n’est pas une réserve de préclés
Les préclés servent à établir les sessions. Un protocole ratchet modifie les secrets pendant la conversation. La spécification Double Ratchet explique l’évolution des clés de message et des constructions ratchet post-quantiques plus récentes, y compris des conceptions qui ne transmettent pas un échange post-quantique complet avec chaque message applicatif.
La confidentialité persistante concerne les messages antérieurs après une compromission ultérieure des clés. La sécurité après compromission concerne le rétablissement de la sécurité des communications futures une fois que l’attaquant perd son accès et que du nouveau matériel secret est incorporé. Aucune des deux ne signifie qu’un logiciel malveillant peut rester indéfiniment sur un téléphone pendant que la cryptographie lui dissimule, d’une manière ou d’une autre, le texte en clair de ce téléphone.
Supprimer une préclé publique du serveur empêche sa réutilisation ordinaire ; cela n’équivaut pas à supprimer la clé privée correspondante d’un terminal. Un audit utile vérifie les règles de cycle de vie ainsi que le comportement face aux messages retardés.
Ce que Livara documente — et ce qui demande encore des preuves
La page de sécurité de Livara décrit un établissement de session hybride avec des clés à usage unique lorsqu’elles sont disponibles, des avancées ordinaires de la chaîne de messages et des époques ML-KEM périodiques. Cela diffère de l’ancienne affirmation selon laquelle chaque message effectue un nouvel échange ML-KEM complet. Il s’agit d’énoncés de la documentation du produit, pas d’une vérification indépendante de l’implémentation.
N’en déduisez pas une politique précise de repli en cas d’épuisement des clés, un intervalle de réapprovisionnement ou une valeur de latence réseau. Ces questions exigent une documentation du protocole propre à la version ou des résultats mesurés. Le Proof Lab n’est pas non plus un test complet de l’établissement asynchrone, de l’épuisement des clés ou de la récupération des messages retardés.
Comment évaluer les promesses de messagerie hors ligne
Demandez au fournisseur ou à l’évaluateur des preuves couvrant ces cas :
| Cas de test | Ce qu’il faut observer |
|---|---|
| Premier message à un contact déconnecté | Le matériel de clé publique utilisé et le moment où le destinataire reçoit effectivement le message |
| Préclés à usage unique épuisées | Si l’établissement s’arrête ou suit un repli documenté, et le compromis de sécurité annoncé |
| Réinstallation ou changement d’identité du destinataire | Si les anciens messages en attente restent déchiffrables et si les changements de clés sont visibles |
| Messages retardés ou réordonnés | Limites de conservation, gestion des clés sautées et erreurs compréhensibles |
| Retour après une longue absence | Renouvellement sûr des clés, traitement borné et état de livraison exact |
| Comparaison des performances | Appareil, version de l’application, réseau, taille de la charge utile et mesures séparées de l’établissement initial et des sessions déjà établies |
Utilisez des comptes et des messages de test sans données sensibles. Un test de livraison réussi démontre ce scénario, pas toutes les propriétés cryptographiques. À l’inverse, un échec de livraison peut provenir du réseau ou du cycle de vie plutôt que d’une rupture du chiffrement.
Questions fréquentes
Le destinataire peut-il être hors ligne pendant que j’envoie ?
Oui, si l’application dispose du matériel public nécessaire et de l’infrastructure de livraison et de stockage. Le destinataire ne peut lire le message en attente que lorsque son appareil peut le récupérer et le traiter.
Des clés KEM plus grandes ralentissent-elles toujours sensiblement les conversations ?
La taille des clés ne permet pas, à elle seule, d’affirmer un délai universel. La fréquence d’établissement, le regroupement, la mise en cache, l’implémentation et les conditions réseau comptent. Publiez une mesure comparative plutôt que promettre une surcharge nulle.
Une préclé signée prouve-t-elle l’identité de la personne derrière le compte ?
Elle authentifie du matériel par rapport à une identité de signature. La liaison entre cette identité et la personne que vous souhaitez joindre est une question distincte de confiance et de vérification.
Le chiffrement post-quantique fonctionne-t-il sans aucune connexion ?
Certains calculs locaux peuvent être effectués hors ligne. La livraison des messages exige toujours une voie de communication ; la cryptographie n’en fournit pas.
