FR
HqcLethe traite les clés HQC sans mémoire par client
HqcLethe: Streaming HQC Encapsulation for Tiny Stateless Servers · arXiv:2610.36808
En termes simples
HQC permet à deux parties de créer une clé secrète commune. Ses clés publiques sont trop volumineuses pour tenir dans un seul paquet réseau, et conserver les fragments incomplets pour chaque client pourrait permettre à des attaquants de remplir la mémoire du serveur.
HqcLethe permet au serveur de traiter de petits fragments et d’oublier chaque demande, tandis que le client assemble les réponses. Une preuve formelle vérifie que ces réponses ne révèlent pas plus qu’un texte chiffré HQC ordinaire. Sur un Raspberry Pi, la mémoire mesurée est restée stable pour les charges de clients testées.
La recherche
Comment un serveur peut-il accepter une clé publique HQC répartie sur plusieurs paquets réseau sans réserver de mémoire pour chaque échange incomplet ?
Conserver ces fragments peut permettre à un attaquant d’épuiser la mémoire du serveur, tandis que la multiplication de polynômes de HQC ne se découpe pas simplement en fragments d’entrée et de sortie correspondants.
HqcLethe traite l’encapsulation de clé HQC par fragments de la taille d’un paquet : le serveur évite de conserver des données par client, et le client reconstitue le texte chiffré.
Pour évaluer les coûts de cette conception, les auteurs ont comparé HqcLethe à McTiny, une méthode d’échange de clés sans état antérieure, et mesuré son usage mémoire sur un Raspberry Pi 3B+.
En catégorie 5, sur un seul hôte x86, HqcLethe a utilisé 27 fois moins d’octets de charge utile UDP et 9,5 fois moins de processeur côté serveur par échange que McTiny. Sur le Raspberry Pi, la limite minimale de mémoire nécessaire pour terminer les sessions était de 1,2–1,6 MiB selon les niveaux HQC et les charges testés, y compris avec 64 clients.
Ces résultats étayent l’efficacité et la stabilité de l’usage mémoire dans ces configurations, mais la comparaison des performances porte sur des protocoles et des choix cryptographiques différents.
Les chiffres de performance proviennent d’un seul hôte x86 et comparent des conceptions différentes ; ils ne permettent donc pas d’isoler l’effet du seul traitement en flux. La mesure de mémoire porte sur les charges testées sur Raspberry Pi.
HqcLethe n’empêche pas la saturation du lien réseau, et son intégration à un protocole complet reste à réaliser.
Ce que montrent les preuves
- Le problème de mémoire
HqcLethe est une méthode d’échange de clés entre un client et un serveur qui ne conserve pas de données propres à chaque client. HQC est une méthode cryptographique qui permet au serveur de créer une clé secrète partagée et un texte chiffré à partir de la clé publique du client.
Or, les clés publiques HQC s’étendent sur plusieurs paquets. Si le serveur garde en mémoire les échanges incomplets, un attaquant peut le forcer à réserver de la mémoire pour de nombreux clients.
L’article cherche donc à utiliser HQC sans que la mémoire du serveur augmente avec ces connexions en attente.
- Traiter le calcul par fragments
HqcLethe répartit la multiplication de polynômes du serveur en calculs sur des restes de la taille d’un paquet, grâce au théorème chinois des restes. Le serveur renvoie des restes masqués sans conserver de données propres au client, puis celui-ci reconstitue le texte chiffré.
Le calcul est ainsi réparti : le serveur peut oublier chaque demande, tandis que le client rassemble les fragments nécessaires au résultat.
- Vérifier le masquage
Les restes bruts révéleraient des valeurs intermédiaires absentes d’un texte chiffré HQC ordinaire. HqcLethe les masque ; ces masques disparaissent lorsque le client reconstitue et réduit le résultat.
Une preuve mécanisée dans Rocq/SSProve établit que, sous les hypothèses énoncées sur les moduli, aucun test ne peut distinguer la procédure avec restes masqués d’un simulateur utilisant le chiffrement HQC ordinaire.
- Comparer deux conceptions sans état
Les auteurs ont comparé HqcLethe à McTiny, une méthode d’échange de clés sans état antérieure utilisant Classic McEliece. En catégorie 5, sur le même hôte x86, HqcLethe a utilisé 27 fois moins d’octets de charge utile UDP au total et 9,5 fois moins de processeur côté serveur par échange.
La comparaison porte sur des conceptions et des choix cryptographiques différents ; elle ne montre donc pas quel changement individuel explique l’écart.
- Évaluer le compromis
Une comparaison distincte avec un serveur qui conserve les fragments en mémoire rend visible le coût de l’absence d’état : en catégorie 5, HqcLethe a utilisé environ deux fois plus d’octets et 4,1 fois plus de processeur côté serveur par session.
Sur un Raspberry Pi 3B+, la limite de mémoire mesurée est restée entre 1,2 et 1,6 MiB selon les niveaux HQC et les charges testés, y compris avec un et 64 clients. Ces mesures étayent la conception dans les environnements testés.
Détails
- Auteurs de l’article original
- Wind Wong, Klaus v. Gleissenthall
- Soumis à arXiv
- Licence
- CC BY 4.0