Layered Performance Analysis of TLS 1.3 Handshakes: Classical, Hybrid, and Pure Post-Quantum Key Exchange

Este estudio presenta un análisis de laboratorio que evalúa el impacto de los algoritmos de criptografía post-cuántica (híbridos y puros) frente a los tradicionales en el rendimiento de las transacciones HTTP sobre TLS 1.3, examinando sus efectos específicos en cada capa de la pila de protocolos mediante pruebas de carga de hasta 100 transacciones por segundo.

Lo esencial

¡Claro que sí! Imagina que este artículo es como un informe de mecánica de un coche de carreras, pero en lugar de un motor de gasolina, el coche es la forma en que nos conectamos a internet de forma segura (el protocolo TLS 1.3), y el "combustible" nuevo es una tecnología llamada Criptografía Post-Cuántica (PQC).

Aquí tienes la explicación sencilla, usando analogías de la vida real:

🚀 El Gran Problema: El "Robo del Futuro"

Imagina que hoy guardas tus secretos en una caja fuerte (cifrado). Los ladrones actuales no pueden abrirla. Pero, pronto llegarán unos ladrones con una llave maestra futurista (computadoras cuánticas) que abrirá cualquier caja fuerte clásica en un segundo.

Para evitar que nos roben nuestros secretos ahora para descifrarlos mañana, necesitamos cambiar las cerraduras de nuestras cajas fuertes por unas nuevas, indestructibles para esos ladrones futuristas. Esas nuevas cerraduras son la Criptografía Post-Cuántica.

🔍 ¿Qué hicieron los autores?

Los autores (David, Daniel y Ana) se preguntaron: "Si cambiamos las cerraduras por estas nuevas y superseguras, ¿se hará más lento el coche? ¿Cuánto?".

En lugar de solo mirar el tiempo total del viaje, decidieron desmontar el coche pieza por pieza para ver exactamente dónde se pierde el tiempo. Imagina que el viaje de conexión a internet tiene 5 etapas:

1. El saludo inicial (TCP): Como saludar a un guardia en la puerta.
2. Preparar la maleta (TCP a TLS): El cliente preparando sus documentos antes de entrar.
3. El intercambio de llaves (TLS): El momento mágico donde se intercambian las llaves de la caja fuerte.
4. Abrir la puerta (TLS a App): El momento justo después de entrar.
5. Recoger el paquete (App): Recibir la respuesta del servidor.

🧪 El Experimento: Tres Tipos de Cerraduras

Probaron tres escenarios en su laboratorio (con un tráfico simulado de 100 coches por segundo):

1. La vieja cerradura (Clásica): La que usamos hoy (x25519).
2. La cerradura híbrida (Híbrida): Una cerradura doble. Tiene la vieja llave y la nueva llave cuántica atadas con cinta adhesiva. (Más segura, pero más pesada).
3. La cerradura 100% cuántica (Pura): Solo la nueva llave cuántica (ML-KEM).

📊 Los Resultados: ¿Dónde está el cuello de botella?

Aquí viene la parte más interesante, porque los resultados fueron sorprendentes:

1. El saludo inicial (TCP) y la entrega del paquete (App) 🚶‍♂️📦

• Analogía: Como caminar por el pasillo del aeropuerto.
• Resultado: ¡No cambió nada! Ya sea que uses la cerradura vieja o la nueva, caminar por el pasillo tarda lo mismo. La tecnología cuántica no afecta a estas partes.

2. Preparar la maleta (TCP a TLS) 🎒

• Analogía: Es el momento en que el pasajero (tu navegador) tiene que sacar sus documentos y llenar formularios antes de entrar.
• Resultado: ¡Aquí es donde se nota la diferencia! Con las nuevas cerraduras cuánticas, preparar la maleta tarda 6 veces más.
  • Por qué: Las nuevas cerraduras son más grandes y complejas. El ordenador del cliente tiene que trabajar más para generar las llaves antes de empezar. Es como si tuvieras que llenar un formulario de 5 páginas en lugar de uno de una línea.

3. El intercambio de llaves (TLS Handshake) 🔑

• Analogía: El momento en que realmente se intercambian las llaves en la puerta.
• Resultado: ¡Sorpresa! No hubo diferencia.
  • Aunque las llaves cuánticas son más pesadas, el proceso de intercambiarlas en la puerta fue tan rápido y eficiente que, en la práctica, tardó lo mismo que con la cerradura vieja.
  • Lección: La nueva tecnología es tan eficiente que el "peso" extra de las llaves no se siente en el intercambio final.

💰 El Costo Real: ¿Vale la pena?

Los autores calcularon cuánto tiempo extra nos cuesta usar estas nuevas cerraduras en total:

• El costo total: Añadir la criptografía cuántica al viaje completo solo nos cuesta unos 3 a 4 milisegundos extra (es decir, 0.003 segundos). ¡Es imperceptible para el ojo humano!
• El efecto del tamaño del paquete: Si pides un archivo pequeño (4 KB), el costo extra es más visible (como un 15% del tiempo total). Pero si pides un archivo grande (40 KB), ese costo extra se "diluye" y pasa a ser menos del 8%.
  • Analogía: Si tienes que caminar 10 metros y tardas 1 segundo más en ponerte los zapatos, es mucho. Pero si tienes que caminar 10 kilómetros, esos 1 segundo extra no importan nada.

🖥️ ¿Qué pasa con el ordenador? (CPU)

• En tu ordenador (Cliente): Tu ordenador tiene que trabajar el doble para preparar las llaves cuánticas. Si tienes un teléfono viejo o un dispositivo pequeño, esto podría notarse más.
• En el servidor (La web): El servidor apenas nota el cambio. Su trabajo aumenta muy poco (un 5-6% más de esfuerzo).

🏁 Conclusión en una frase

Cambiar a la nueva seguridad cuántica no va a hacer que internet se vuelva lento. El único "trabajo extra" ocurre cuando tu ordenador se prepara para entrar, pero una vez dentro, todo fluye igual de rápido. Es como cambiar de un coche de gasolina a uno eléctrico: el arranque puede ser un poco diferente, pero la carretera se siente igual.

En resumen: ¡Es seguro cambiar a la nueva tecnología! El costo de velocidad es mínimo y el beneficio de seguridad contra los ladrones del futuro es enorme.

Resumen técnico

Aquí tienes un resumen técnico detallado del artículo en español, estructurado según los puntos solicitados:

Título: Análisis de Rendimiento por Capas de los Handshakes TLS 1.3: Clásicos, Híbridos y PQC Puros

1. El Problema

La llegada de la computación cuántica amenaza las infraestructuras de clave pública actuales, impulsando la migración hacia criptografía post-cuántica (PQC). Aunque existen estándares finalizados por el NIST (como ML-KEM/FIPS 203), las organizaciones necesitan cuantificar el impacto en el rendimiento antes de su implementación en producción.
El problema central abordado es la falta de estudios que descompongan la latencia de una transacción HTTP sobre TLS en sus fases individuales. La mayoría de las investigaciones anteriores solo miden el tiempo total del handshake, lo que impide identificar en qué capa específica (TCP, inicialización del cliente, negociación TLS o aplicación) se origina la sobrecarga introducida por los algoritmos PQC.

2. Metodología

Los autores diseñaron un laboratorio que emula un entorno de producción realista para realizar pruebas de carga.

• Arquitectura Experimental:
  • Cliente: Generador de tráfico de alto rendimiento (Keysight CyPerf) que simula usuarios virtuales ejecutando transacciones HTTP con estado a una tasa sostenida de 100 transacciones por segundo (TPS).
  • Servidor: Un proxy inverso Nginx (v1.27.3) que termina TLS, compilado con OpenSSL 3.4.0 integrado con la biblioteca liboqs (Open Quantum Safe) para soportar algoritmos PQC.
  • Backend: Un agente que devuelve respuestas HTTP de diferentes tamaños (4 KB y 40 KB).
• Configuraciones Comparadas:
  • Clásico: x25519 (ECDH tradicional).
  • Híbrido: x25519 + ML-KEM (MLKEM512 y MLKEM768).
  • PQC Puro: MLKEM512 y MLKEM1024.
• Método de Análisis (Descomposición de 5 Capas):
  En lugar de medir solo el tiempo total, el estudio divide la transacción en cinco fases temporales utilizando capturas de paquetes (pcap) y logs de claves SSL:
  1. Handshake TCP: (SYN → SYN-ACK).
  2. Retraso TCP a TLS: (SYN-ACK → ClientHello) - Inicialización del contexto en el cliente.
  3. Handshake TLS: (ClientHello → Finished) - Negociación y verificación.
  4. Retraso TLS a Aplicación: (Finished → HTTP GET).
  5. Respuesta de Aplicación: (HTTP GET → HTTP 200 OK).
• Métricas: Se analizaron percentiles (p50, p95, p99), desviación estándar y se calculó el tamaño del efecto (Glass's $\Delta$) para determinar la significancia práctica de las diferencias.

3. Contribuciones Clave

1. Metodología de Descomposición de 5 Capas: Un enfoque novedoso que atribuye la sobrecarga PQC a fases específicas del protocolo en lugar de al tiempo total.
2. Comparación Empírica Exhaustiva: Más de 30 experimentos con ~1 millón de solicitudes totales, comparando configuraciones clásicas, híbridas y puras bajo carga realista.
3. Hallazgo de Neutralidad del Handshake TLS: Demostración estadística de que la capa de handshake TLS es "neutra al algoritmo", donde las diferencias entre PQC y clásico son insignificantes.
4. Herramientas y Datos Abiertos: Publicación de una herramienta de reducción de datos (pcap_layer_analysis.py) y un conjunto de datos público con capturas de paquetes descifradas para análisis reproducible.

4. Resultados Principales

• Capa TCP (Independencia): La latencia del handshake TCP no se ve afectada por el algoritmo criptográfico. Las diferencias son mínimas ($\Delta < 0.2$), confirmando que el PQC no impacta la red de nivel inferior.
• Inicialización del Cliente (TCP a TLS): El Cuello de Botella.
  • Esta capa muestra el mayor impacto. La latencia media aumenta de ~0.3 ms (x25519) a ~1.8-1.9 ms (PQC).
  • Esto representa un aumento de 6x en el tiempo de inicialización del contexto TLS en el cliente.
  • El tamaño del efecto es masivo ($\Delta \approx 7.7$), indicando que la generación de material de clave y la construcción del ClientHello son las causas dominantes de la latencia PQC.
• Handshake TLS (Neutralidad Algorítmica):
  • Contrario a la intuición, la fase de negociación TLS (ClientHello a Finished) no muestra diferencias prácticas significativas.
  • Las variaciones entre configuraciones (0.1 a 0.9 ms) caen dentro del ruido de medición y la variabilidad del sistema ($\Delta < 0.33$).
  • Incluso las variantes puras de ML-KEM, que teóricamente podrían ser más rápidas en microbenchmarks, no muestran ventaja medible a nivel de protocolo debido al enmascaramiento por la fragmentación de red y la programación del sistema.
• Capa de Aplicación: El tiempo de respuesta de la aplicación es dominante y depende del tamaño del payload (4 KB vs 40 KB), pero es independiente del algoritmo criptográfico.
• Impacto de la Carga de Datos (Payload):
  • Al aumentar el tamaño de la respuesta de 4 KB a 40 KB, la sobrecarga absoluta del PQC se mantiene constante (~2.4 ms), pero su impacto relativo disminuye (de ~15% a ~8% del tiempo total) debido al efecto de dilución.
• Utilización de Recursos (CPU):
  • Cliente: El uso de CPU se duplica (de ~3.7% a ~8.5%) en configuraciones PQC debido a la inicialización.
  • Servidor: El aumento es modesto en términos absolutos (~14-15%), pero representa un incremento relativo de hasta el 6% para configuraciones híbridas.
  • Red: El tráfico aumenta linealmente con el tamaño de las claves (de 32 B a ~1568 B), pero no afecta la latencia de manera proporcional.

5. Significado e Implicaciones

• Planificación de Migración: La migración a PQC en TLS 1.3 conlleva un costo de latencia inicial concentrado casi exclusivamente en la inicialización del cliente (generación de claves), no en la negociación del protocolo en sí.
• Impacto en Dispositivos Constrained: El doble uso de CPU en el cliente sugiere que dispositivos IoT o móviles con recursos limitados podrían sufrir un impacto más severo que los servidores.
• Dispositivos de Red (MiTM): Para dispositivos que realizan inspección de tráfico (Man-in-the-Middle), el impacto podría ser significativo al sumar la carga de CPU tanto del lado del cliente como del servidor, además de la alta tasa de sesiones.
• Conclusión de Rendimiento: A pesar del aumento en la generación de claves, el costo total en la latencia de extremo a extremo es moderado (agregando solo 3-4 ms en promedio). Para transacciones con payloads grandes, el impacto relativo es insignificante (<10%).
• Futuro: Se recomienda realizar pruebas de estrés más allá de 100 TPS y evaluar algoritmos de firma digital (como ML-DSA) en entornos de red reales con balanceadores de carga.

En resumen, el estudio desmitifica la idea de que el PQC ralentiza drásticamente todo el handshake TLS, demostrando que el rendimiento es robusto y que la penalización es un costo fijo de inicialización manejable en la mayoría de los escenarios de producción.