Post-Cuántico TLS 1.3: ¿Qué configuración híbrida de KEM minimiza la sobrecarga del handshake en OpenSSL?

TLS 1.3 está siendo migrado al intercambio de claves post-cuántico porque el Diffie-Hellman clásico y X25519 no resistirán una computadora cuántica grande. NIST ha seleccionado ML-KEM como su mecanismo de encapsulación de claves post-cuántico [9]. El intercambio de claves y la autenticación post-cuánticos con ML-KEM y ML-DSA afectarán el rendimiento de TLS 1.3 en la Web y otras aplicaciones [9]. Los estudios hasta ahora se han concentrado en la sobrecarga de estos algoritmos resistentes a la computación cuántica en el tiempo hasta el primer byte de TLS, es decir, el tiempo de handshake [9]. Ese enfoque tiene sentido para el costo de establecimiento de conexión, pero deja el tamaño del código, una segunda preocupación nombrada directamente en la pregunta de investigación, casi sin abordar por la literatura de medición recopilada aquí.

Los datos de despliegue muestran que la transición ya está en marcha pero incompleta. Un estudio de medición de 2026 encontró que el 49.3% de los dominios admiten mecanismos híbridos de intercambio de claves post-cuánticos como MLKEM768 con X25519, mientras que el 50.7% de los dominios continúan usando intercambio de claves clásico [14]. El mismo estudio encontró una adopción del 0% de certificados híbridos post-cuánticos, dejando la capa de autenticación vulnerable a ataques habilitados por la computación cuántica, como la falsificación de certificados [14]. También encontró que el 15.70% de los dominios, especialmente en sectores críticos como la banca y el gobierno, todavía dependen de TLS 1.2 [14]. Este estado mixto es la razón por la cual los constructores necesitan números de rendimiento concretos ahora, no después de que la migración esté completa.

La motivación de seguridad es cuantificable. El material de clave simétrica con seguridad clásica de 128 bits proporciona aproximadamente 64 bits de seguridad efectiva contra un atacante cuántico [14]. Esa reducción a la mitad es la razón por la cual la migración de KEM se trata como urgente en lugar de opcional, y enmarca por qué las compensaciones de latencia y tamaño de configuraciones KEM específicas importan operativamente, no solo académicamente.

La pregunta de investigación pregunta específicamente sobre OpenSSL 3.4+ y configuraciones nombradas como X25519Kyber768 y X25519MLKEM512. Las afirmaciones disponibles describen experimentos en OpenSSL 3.x integrado con liboqs [1] [8] y en evaluaciones comparativas multiplataforma de familias PQC relacionadas [12], pero ninguna de las fuentes vincula sus mediciones a la versión exacta de OpenSSL 3.4+ o la métrica de tamaño de código nombrada en la pregunta. Un constructor debe leer el resto de esta nota como una respuesta a la mitad de latencia de la pregunta, con una brecha explícita señalada en la mitad del tamaño del código.

Dicho de manera clara y una vez, por adelantado: ninguna afirmación verificada conecta la ventaja de tamaño de paquete de ML-KEM-512, o el rendimiento de cualquier configuración KEM, con el tamaño del código. Cada afirmación que discute la ventaja de ML-KEM-512 habla solo del tamaño del paquete y la latencia del handshake bajo estrés de red, nunca del tamaño del código compilado o enlazado, la huella binaria o el tamaño de la biblioteca [1]. Ninguna afirmación compara el tamaño del código entre ML-KEM-512, ML-KEM-768, Kyber768 o cualquier combinación híbrida. Un lector que necesite una respuesta sobre el tamaño del código debe tratar esta nota como silenciosa en esa dimensión; nada aquí implica que una ventaja de tamaño de paquete se traduzca en una ventaja de tamaño de código, porque ninguna fuente hace esa conexión.

Esto es importante para despliegues empotrados y con restricciones, donde el tamaño del código es a menudo la restricción vinculante en lugar de la latencia. Dado que la literatura revisada aquí no lo mide, ninguna decisión de adquisición o ingeniería que dependa del tamaño del código puede resolverse solo con estas afirmaciones. Por lo tanto, el resto de esta nota trata la latencia como la mitad respondible de la pregunta y trata el tamaño del código como una pregunta abierta y no abordada.

ML-KEM es una de las selecciones de algoritmos post-cuánticos de NIST para el intercambio de claves, junto con ML-DSA para la autenticación [9]. Los experimentos más relevantes para el rendimiento de OpenSSL evalúan algoritmos ML-KEM directamente y también una configuración híbrida, X25519+ML-KEM-768, que combina el intercambio de curva elíptica clásico X25519 con el mecanismo post-cuántico ML-KEM-768 [1]. Este diseño híbrido es común en el despliegue: los mecanismos híbridos de intercambio de claves post-cuánticos observados en la naturaleza, como MLKEM768 con X25519, siguen el mismo patrón de emparejar una primitiva clásica y una post-cuántica en una sola negociación [14].

Otros trabajos en este espacio estudian familias KEM relacionadas pero distintas. Un estudio investiga el impacto de incorporar KEM post-cuánticos, específicamente los estándares CRYSTALS-Kyber y HQC, junto con el candidato a estándar BIKE, en el handshake TLS 1.3 [8]. Otro presenta lo que llama la evaluación empírica multiplataforma más extensa hasta la fecha de algoritmos PQC seleccionados por NIST, incluyendo CRYSTALS-Kyber y NTRU para KEM, junto con BIKE como alternativa basada en códigos, y CRYSTALS-Dilithium y Falcon para firmas [12]. Estos amplían el panorama más allá de ML-KEM solo, pero no informan cifras para las etiquetas exactas X25519MLKEM512 o X25519Kyber768 nombradas en la pregunta; un constructor que mapee estas familias a los nombres de grupo de OpenSSL debe hacerlo con cuidado, ya que las afirmaciones aquí no establecen que Kyber y ML-KEM sean intercambiables o idénticos.

El lado de las firmas de TLS 1.3 es un mecanismo separado del intercambio de claves pero comparte la misma presión de migración. Dilithium 2 y Falcon 512 superan a RSA 4096 en la duración del tiempo de handshake TLS [13]. Esto es un contexto útil para un constructor que ensambla una pila completa de TLS 1.3 post-cuántico, ya que tanto la elección del intercambio de claves como la del algoritmo de firma contribuyen al costo total del handshake, pero es un hallazgo separado de las comparaciones KEM que son el foco de esta nota.

El método más detallado para los números relevantes para OpenSSL es el estudio ARM64. Los experimentos se realizaron utilizando OpenSSL 3.x integrado con liboqs [1]. La configuración híbrida X25519+ML-KEM-768 fue una de las configuraciones evaluadas [1]. Se realizaron 100 iteraciones para cada configuración [1]. Se utilizaron cinco escenarios de red: loopback, LAN (10 ms RTT), WAN (50 ms RTT) y tasas de pérdida de paquetes del 1% y 5% [1]. Leído como cinco condiciones distintas: loopback, LAN, WAN, pérdida del 1% y pérdida del 5%, esto coincide con el recuento declarado de cinco; un constructor que reproduzca la configuración debe tratarlo de esa manera en lugar de como cuatro escenarios.

Un estudio relacionado pero separado en terreno similar investiga Kyber, HQC y BIKE en TLS 1.3, y realizó una evaluación experimental exhaustiva midiendo la latencia del handshake bajo condiciones de red emuladas con probabilidades de pérdida de paquetes variables [8]. Esto es metodológicamente paralelo al diseño de estrés de red del estudio ARM64, pero cubre una familia KEM diferente, por lo que sus números no deben fusionarse con las cifras de ML-KEM sin cuidado.

Un tercer esfuerzo de evaluación comparativa más grande midió la latencia computacional, la utilización de memoria, los tamaños de clave y la sobrecarga del protocolo en múltiples niveles de seguridad, Niveles 1, 3 y 5 de NIST, en tres entornos de hardware distintos y varias condiciones de red [12]. Esta es la única afirmación en el conjunto que nombra los tamaños de clave y la utilización de memoria como variables medidas, lo que está cerca pero sigue siendo distinto del tamaño del código; no informa una cifra de tamaño de código para ninguna configuración de OpenSSL, por lo que no cierra la brecha señalada anteriormente.

Un cuarto estudio adopta un ángulo diferente, descomponiendo el handshake TLS en etapas y midiendo tamaños del efecto en lugar de tiempos brutos. Este enfoque en capas le permite aislar dónde en el handshake una elección de KEM realmente importa, en lugar de tratar el handshake como una sola medición; su hallazgo central se discute una vez, en su totalidad, en la siguiente sección.

Los números de latencia principales provienen del estudio ARM64. Los algoritmos ML-KEM introducen una sobrecarga computacional insignificante en comparación con el X25519 clásico en condiciones de baja latencia [1]. Los tiempos de handshake 1-RTT en estado base para los algoritmos ML-KEM oscilan entre 11.3 y 13.3 ms [1]; este es el único rango autorizado para la temporización en estado base en esta nota, referenciado desde otras secciones en lugar de repetirse. Bajo pérdida de paquetes, la brecha se amplía: ML-KEM alcanzó 180 ms con un 5% de pérdida de paquetes, mientras que X25519 alcanzó 281 ms [1], por lo que en la tasa de pérdida más alta probada, ML-KEM fue más rápido en términos absolutos, no solo comparable. Los tiempos de reinicio de sesión redujeron consistentemente la latencia del handshake para todos los algoritmos probados [1], lo que significa que las conexiones reanudadas fueron más rápidas que los handshakes 1-RTT nuevos en todos los casos, independientemente del KEM en uso.

Dentro de este estudio ARM64, ML-KEM-512 mostró el mejor rendimiento, particularmente debido a su pequeño tamaño de paquete [1]. Esta es la única afirmación en el conjunto que clasifica las configuraciones entre sí en un mecanismo nombrado, y es lo más cerca que la evidencia está de responder directamente la mitad de latencia de la pregunta de investigación.

Un análisis en capas separado descompone el handshake TLS 1.3 en etapas en lugar de tratarlo como un solo número, y este es el calificador más importante de los resultados ARM64 anteriores. Su hallazgo central, establecido una vez aquí y referenciado en lugar de repetido en otra parte de esta nota: el intercambio de handshake TLS, la etapa desde ClientHello hasta Finished, es efectivamente neutral en cuanto al algoritmo, con todas las configuraciones probadas, clásicas, híbridas y ML-KEM puro, mostrando tamaños del efecto insignificantes, Glass's Δ por debajo de 0.2 a 0.33 [4]. En consonancia con esto, no se encontró ninguna penalización o ventaja prácticamente significativa atribuible al algoritmo de intercambio de claves en el intercambio de handshake TLS [4]. En cambio, el costo sensible al algoritmo se aísla específicamente en la construcción de ClientHello [4], no en el intercambio de ida y vuelta en su conjunto.

Esto replantea los números ARM64 en lugar de contradecirlos. El rango de estado base y las cifras de pérdida de paquetes citadas anteriormente [1] describen el tiempo de handshake de pared bruto bajo estrés de red; el hallazgo de tamaño del efecto insignificante del estudio en capas [4] describe el tamaño estadístico de la diferencia atribuible al algoritmo dentro de la etapa de intercambio de handshake, bajo condiciones y métricas presumiblemente diferentes. Los dos no están midiendo la misma cantidad, por lo que un constructor no debe leer uno como anulando al otro; más bien, los números ARM64 muestran lo que sucede específicamente en condiciones de red adversas, mientras que el análisis en capas muestra que, promediado entre configuraciones, la etapa de intercambio en sí misma conlleva poco costo atribuible al algoritmo, con la sensibilidad real situada aguas arriba en la construcción de ClientHello.

En conjunto, una lectura práctica es: si el objetivo de despliegue está dominado por el estrés de red, la pérdida de paquetes y el RTT, los números ARM64 son los relevantes y ML-KEM-512 se reporta como el de mejor rendimiento allí [1]. Si el objetivo de despliegue es una red estable con baja pérdida, el hallazgo del estudio en capas sugiere que la elección entre las configuraciones probadas no producirá, por sí misma, una diferencia de latencia prácticamente significativa en la etapa de intercambio [4], aunque el costo de construcción de ClientHello merece atención por separado.

El tiempo de handshake no es el único lugar donde puede aparecer la sobrecarga post-cuántica. Un estudio argumenta que los estudios hasta ahora se han centrado en la sobrecarga de los algoritmos resistentes a la computación cuántica en el tiempo hasta el primer byte de TLS, es decir, el tiempo de handshake [9], y se propone llenar un vacío: cuantifica el impacto de ML-KEM y ML-DSA en conexiones TLS 1.3 típicas que transfieren unos pocos cientos de KB del servidor al cliente, estudiando la desaceleración en el tiempo hasta el último byte [9]. Su hallazgo es que, en condiciones de red estables, el impacto de ML-KEM y ML-DSA en el tiempo hasta el último byte de TLS 1.3 es menor que el impacto en el tiempo hasta el primer byte, y este impacto disminuye a medida que aumentan los datos transferidos [9]. Para un constructor, esto significa que los números de latencia de handshake discutidos anteriormente son más relevantes para conexiones de corta duración o dominadas por el handshake; para transferencias de carga útil más grandes, los mismos algoritmos importan proporcionalmente menos al tiempo total de conexión.

El panorama más amplio de evaluación comparativa también incluye trabajos que son más amplios en alcance pero no se centran en OpenSSL específicamente. Una evaluación empírica multiplataforma cubre CRYSTALS-Kyber, NTRU, BIKE, CRYSTALS-Dilithium y Falcon, midiendo la latencia computacional, la utilización de memoria, los tamaños de clave y la sobrecarga del protocolo en los Niveles de seguridad 1, 3 y 5 de NIST en tres entornos de hardware distintos y varias condiciones de red [12]. Un estudio adicional investiga CRYSTALS-Kyber, HQC y BIKE específicamente dentro del handshake TLS 1.3, con una evaluación experimental exhaustiva de la latencia del handshake bajo pérdida de paquetes emulada [8]. Ninguno de estos dos estudios se informa aquí con cifras vinculadas a OpenSSL 3.4+ o a las configuraciones nombradas X25519Kyber768 o X25519MLKEM512, por lo que deben leerse como contexto para el panorama KEM en lugar de como respuestas directas a la pregunta de esta nota.

En el lado de la autenticación, que interactúa con el costo del handshake aunque sea un mecanismo separado, Dilithium 2 y Falcon 512 superan a RSA 4096 en la duración del tiempo de handshake TLS [13]. Un constructor que ensamble una configuración completa de TLS 1.3 post-cuántico en OpenSSL necesita elegir tanto un KEM como un algoritmo de firma, y este hallazgo es el relevante para el lado de la firma, independientemente del KEM elegido.

Cualquier hallazgo de latencia o tamaño solo es útil si se asigna a lo que es desplegable y lo que realmente está desplegado. El estudio de medición de 2026 tuvo como objetivo identificar primitivas criptográficas vulnerables a la computación cuántica, detectar la presencia de algoritmos post-cuánticos o híbridos, y analizar el despliegue en el mundo real de TLS en diferentes sectores [14]. Sus cifras principales, ya señaladas anteriormente, son que el 49.3% de los dominios admiten intercambio de claves híbrido post-cuántico como MLKEM768 con X25519, y el 50.7% de los dominios todavía usan solo intercambio de claves clásico [14]. Esa división significa que un constructor que busque una amplia compatibilidad aún debe admitir la negociación solo clásica como respaldo para aproximadamente la mitad de los dominios observados, al menos en el momento de esa medición.

Más preocupante para cualquiera que razone sobre seguridad a largo plazo en lugar de solo latencia: se observó una adopción del 0% de certificados híbridos post-cuánticos, dejando la capa de autenticación vulnerable a ataques habilitados por la computación cuántica, como la falsificación de certificados [14]. Esto significa que incluso donde se despliega el intercambio de claves híbrido, la cadena de certificados que autentica ese intercambio aún no se ha migrado en ningún lugar del conjunto medido. Un 15.70% adicional de los dominios, especialmente en sectores críticos como la banca y el gobierno, todavía dependen de TLS 1.2 [14], una versión del protocolo que es anterior por completo a los mecanismos PQC híbridos discutidos a lo largo de esta nota.

Estas cifras no miden configuraciones de OpenSSL directamente, y no dicen nada sobre latencia o tamaño del código. Pero establecen el techo práctico de por qué se está haciendo la pregunta de latencia en primer lugar: el intercambio de claves híbrido está aproximadamente a medio desplegar, la autenticación híbrida no está desplegada en absoluto, y una fracción significativa del ecosistema no ha avanzado más allá de TLS 1.2. Un constructor que optimice para la configuración KEM híbrida más rápida debe tener en cuenta que la ventaja de latencia de la configuración solo importará para aproximadamente la mitad de las conexiones que pueden negociarla actualmente, y que la capa de certificados permanece sin abordar por la misma migración.

El límite más importante ya se ha mencionado cerca del principio: ninguna afirmación en este conjunto mide el tamaño del código para ninguna configuración KEM de OpenSSL, por lo que la mitad del tamaño del código de la pregunta de investigación no tiene respuesta en esta evidencia [1]. Esta no es una brecha menor; es una de las dos cantidades que la pregunta solicita, y un constructor que necesite una cifra de tamaño de código debe buscar fuentes fuera de esta nota.

En segundo lugar, el hallazgo del estudio ARM64 de que ML-KEM-512 mostró el mejor rendimiento debido al pequeño tamaño del paquete [1] se informa de un solo estudio en una plataforma de hardware, ARM64, con 100 iteraciones por configuración en cinco escenarios de red [1]. Es la única afirmación en este conjunto que clasifica directamente las configuraciones KEM entre sí por rendimiento medido; no se ha verificado de forma cruzada aquí contra una replicación independiente en una plataforma diferente o versión puntual de OpenSSL.

En tercer lugar, el hallazgo del estudio en capas de que el intercambio de handshake es efectivamente neutral en cuanto al algoritmo [4] y el hallazgo del estudio ARM64 de una brecha de 180 ms frente a 281 ms bajo un 5% de pérdida de paquetes [1] fueron producidos por diferentes grupos de investigación, probablemente bajo condiciones exactas diferentes, y esta nota no ha recibido una afirmación que reconcilie sus métricas en una escala comparable. Un constructor debe tratarlos como evidencia complementaria en diferentes niveles de granularidad, tamaño del efecto en la etapa de intercambio frente a tiempo de reloj real bajo estrés, en lugar de como un número único unificado.

En cuarto lugar, varios de los estudios de evaluación comparativa más amplios, que cubren Kyber, HQC, BIKE, NTRU, Dilithium y Falcon [8] [12] [13], no se informan aquí con cifras vinculadas a los nombres de configuración exactos en la pregunta de investigación, X25519Kyber768 o X25519MLKEM512, o a OpenSSL 3.4+ específicamente. Su relevancia es contextual, no una respuesta directa. Finalmente, las cifras de despliegue [14] describen la adopción a nivel de Internet en el momento de ese estudio y pueden no reflejar la adopción actual; tampoco miden el rendimiento, solo la presencia o ausencia de soporte.

1. Configurar OpenSSL 3.x integrado con liboqs como la pila base, coincidiendo con el entorno en el que se produjeron las cifras de latencia de referencia [1]; esto es un requisito previo para reproducir o ampliar esas cifras en lugar de adivinarlas.
2. Enumerar las configuraciones KEM a probar: como mínimo, X25519 simple como línea base clásica, una configuración pura de ML-KEM y la configuración híbrida X25519+ML-KEM-768, ya que este híbrido fue una de las configuraciones evaluadas directamente en los experimentos fuente [1].
3. Instrumentar el handshake para registrar el tiempo de establecimiento 1-RTT por separado del tiempo de reinicio de sesión (reanudación), porque los tiempos de reinicio de sesión redujeron consistentemente la latencia del handshake para todos los algoritmos en el estudio de referencia [1], y mezclar handshakes nuevos y reanudados en una sola medición desdibujará la comparación.
4. Construir cinco arneses de prueba de condiciones de red que coincidan con el diseño de referencia: loopback, LAN a 10 ms RTT, WAN a 50 ms RTT, pérdida de paquetes del 1% y pérdida de paquetes del 5% [1]. Confirmar que su arnés produce exactamente cinco condiciones distintas para ser una reproducción fiel.
5. Ejecutar 100 iteraciones por configuración por condición de red, coincidiendo con el protocolo de referencia [1], y registrar la distribución completa, no solo la media, para que los valores atípicos bajo pérdida de paquetes sean visibles.
6. Comparar el rendimiento en estado base de cada configuración KEM con el rango de referencia para handshakes 1-RTT en estado base de ML-KEM [1] como una verificación de cordura de que el arnés de prueba se comporta de manera consistente con las cifras publicadas antes de sacar nuevas conclusiones.
7. Bajo la condición de pérdida de paquetes del 5% específicamente, verificar si las configuraciones de la familia ML-KEM se mantienen más cerca de las cifras de referencia informadas para ML-KEM frente a X25519 bajo esa condición [1]; una configuración que se desempeña muy fuera de ambas cifras señala una diferencia en el arnés o el entorno que necesita investigación antes de comparar configuraciones entre sí.
8. Por separado, instrumentar y medir el tiempo de construcción de ClientHello por sí mismo, distinto del tiempo total de intercambio de handshake, ya que el costo sensible al algoritmo reside en la construcción de ClientHello en lugar de en la etapa de intercambio en sí [4]. Omitir esta separación es un punto de falla común: medir solo el tiempo total de handshake ocultará dónde reside realmente cualquier costo real dependiente del algoritmo.
9. Si el tamaño del código es importante para el objetivo de despliegue, tratarlo como una tarea de medición separada y no abordada: compilar la compilación de OpenSSL/liboqs para cada configuración y registrar el tamaño binario o de la biblioteca directamente. Ninguna afirmación en esta nota proporciona una línea base o rango esperado para esto, por lo que cualquier número producido aquí es trabajo nuevo, no una reproducción de hallazgos anteriores.
10. Si el despliegue implica transferencias de carga útil más grandes en lugar de conexiones cortas dominadas por el handshake, también medir el tiempo hasta el último byte para una transferencia representativa de unos pocos cientos de KB, ya que un estudio encontró que el impacto post-cuántico en el tiempo hasta el último byte es menor que en el tiempo hasta el primer byte y disminuye a medida que aumentan los datos transferidos [9]; esto cambia qué configuración importa más dependiendo del tamaño típico de conexión en el despliegue objetivo.
11. Informar los resultados con condición de red explícita, número de iteraciones y plataforma de hardware adjuntos a cada número, siguiendo el patrón de los estudios de referencia [1] [12], para que cualquier lector pueda juzgar si un resultado se generaliza más allá del entorno probado.

for config in [X25519, ML-KEM-512, ML-KEM-768, X25519+ML-KEM-768]:
  for scenario in [loopback, LAN_10ms, WAN_50ms, loss_1pct, loss_5pct]:
    for i in 1..100:
      measure(ClientHello_construction_time)
      measure(full_handshake_time)
      measure(session_restart_time)
    record distribution, not just mean
compare each config's numbers against reference ranges [1]
if code_size_required: compile and measure binary size separately (no reference baseline exists)