ES
HqcLethe transmite claves HQC sin memoria por cliente
HqcLethe: Streaming HQC Encapsulation for Tiny Stateless Servers · arXiv:2610.36808
En palabras sencillas
HQC es un método para que dos partes creen una clave secreta compartida. Sus claves públicas son demasiado grandes para un solo paquete de red, y guardar fragmentos incompletos para cada cliente podría permitir que un atacante agotara la memoria del servidor.
HqcLethe permite que el servidor procese fragmentos pequeños y olvide cada solicitud, mientras el cliente reúne las respuestas. Una demostración formal comprueba que las respuestas no revelan más que un texto cifrado HQC normal. En una Raspberry Pi, la memoria medida se mantuvo igual en las cargas de clientes probadas.
La investigación
¿Cómo puede un servidor aceptar una clave pública HQC que ocupa varios paquetes de red sin reservar memoria para cada intercambio incompleto?
Almacenar esos fragmentos puede permitir que un atacante agote la memoria del servidor, mientras que la multiplicación de polinomios de HQC no puede dividirse en fragmentos sencillos de entrada y salida que se correspondan entre sí.
HqcLethe transmite la encapsulación de claves HQC en fragmentos del tamaño de un paquete, para que un servidor sin estado evite reservar memoria por cliente mientras el cliente reconstruye el texto cifrado.
Para evaluar los costes del diseño, los autores compararon HqcLethe con McTiny, un diseño anterior de intercambio de claves sin estado, y midieron su uso de memoria en una Raspberry Pi 3B+.
En la categoría 5 y en un único equipo x86, HqcLethe usó 27 veces menos bytes de carga útil UDP y 9.5 veces menos CPU del servidor por intercambio que McTiny. En la Raspberry Pi, el límite mínimo de memoria necesario para completar sesiones fue de 1.2–1.6 MiB en los niveles y cargas de HQC probados, incluidos 64 clientes.
Estos resultados respaldan la eficiencia y el uso de memoria constante en esos entornos, pero la comparación de rendimiento abarca protocolos y elecciones criptográficas distintos.
Las cifras de rendimiento proceden de un único equipo x86 y comparan diseños distintos, por lo que no aíslan el efecto de la transmisión por partes.
La medición de memoria abarca las cargas probadas en Raspberry Pi; HqcLethe no evita que se sature el enlace de red, y la integración en un protocolo completo queda para trabajos futuros.
Qué muestran las pruebas
- El problema de memoria
HqcLethe es un método de intercambio de claves entre un cliente y un servidor que no conserva estado por cliente. HQC es un mecanismo de encapsulación de claves: permite que el servidor cree un secreto compartido y un texto cifrado a partir de la clave pública del cliente.
El problema es que las claves públicas de HQC ocupan varios paquetes. Si el servidor almacena intercambios incompletos, un atacante puede obligarlo a reservar memoria para muchos clientes.
El artículo pregunta cómo usar HQC sin que la memoria del servidor crezca con esas conexiones incompletas.
- Transmitir el cálculo por partes
HqcLethe divide la multiplicación de polinomios del servidor en cálculos de restos del tamaño de un paquete mediante el teorema chino del resto. El servidor devuelve restos enmascarados sin conservar estado del cliente, y el cliente reconstruye el texto cifrado.
Así cambia dónde se realiza el trabajo: el servidor puede olvidar cada solicitud mientras el cliente reúne las partes necesarias para obtener el resultado.
- Verificar las máscaras
Los restos sin proteger revelarían valores intermedios que no aparecen en un texto cifrado HQC ordinario. HqcLethe los enmascara para que desaparezcan cuando el cliente reconstruye y reduce el resultado.
Una demostración mecanizada en Rocq/SSProve establece que, bajo los supuestos indicados sobre los módulos, ningún algoritmo que intente distinguirlos puede diferenciar el procedimiento de restos enmascarados de un simulador que usa el cifrado HQC ordinario.
- Comparar diseños sin estado
Los autores compararon HqcLethe con McTiny, un intercambio de claves sin estado anterior que usa Classic McEliece. En la categoría 5 y en el mismo equipo x86, HqcLethe usó 27 veces menos bytes de carga útil UDP en total y 9.5 veces menos CPU del servidor por intercambio.
La comparación abarca diseños y elecciones criptográficas distintos, así que no indica qué cambio individual causó la diferencia.
- Evaluar el intercambio de recursos
Una comparación separada con un servidor con estado que almacena fragmentos muestra el coste de no conservar estado: en la categoría 5, HqcLethe usó aproximadamente el doble de bytes y 4.1 veces más CPU del servidor por sesión. En una Raspberry Pi 3B+, el límite de memoria medido se mantuvo en 1.2–1.6 MiB en los niveles y cargas de HQC probados, incluidos uno y 64 clientes. Estos resultados de implementación respaldan el diseño en los entornos de prueba descritos.
Detalles
- Autores del paper original
- Wind Wong, Klaus v. Gleissenthall
- Enviado a arXiv
- Licencia
- CC BY 4.0