Perfect Forward Secrecy en VPN explicado de forma sencilla: cómo PFS protege tus datos incluso tras un ataque

Por qué Perfect Forward Secrecy es imprescindible para VPN en 2026

Los datos valen más que el oro

En 2026, la encriptación en internet ya no es un lujo, sino una cuestión de supervivencia para cualquier negocio. Por VPN transmitimos de todo: contabilidad, código fuente, bases de datos de clientes, accesos a sistemas internos. Y todo esto interesa no solo a hackers, sino también a inteligencia industrial, atacantes dentro de la red y, lamentablemente, a proveedores demasiado curiosos. La mala noticia: interceptar tráfico se ha vuelto más sencillo. Dispositivos TAP de red baratos, almacenamiento en la nube asequible para guardar terabytes durante años, índices de metadatos... todo esto permite a alguien almacenar silenciosamente datos cifrados durante años y luego intentar descifrarlos cuando surja la oportunidad.

La buena noticia: Perfect Forward Secrecy (PFS) rompe este mal guion. Aunque alguien robe tu clave a largo plazo del servidor o haya un phishing exitoso contra un admin, PFS no permitirá descifrar conexiones antiguas. Cada sesión VPN vive su propia vida criptográfica efímera y tras finalizar es como un rastro de papel que quemaste. Todo lo que interceptaste antes queda inútil, solo un montón de bytes sin sentido.

¿Qué aporta exactamente PFS?

PFS garantiza la propiedad de secreto directo: la filtración de claves a largo plazo no revela claves de sesiones pasadas. Cada sesión recibe un secreto efímero nuevo, generado mediante un intercambio seguro (normalmente el esquema Diffie-Hellman sobre curvas elípticas — ECDHE). Estas claves no se repiten, no se almacenan y desaparecen en cuanto dejan de usarse. Ahí está la magia: sin clave, no hay descifrado posible.

Otro plus es su resistencia condicional a amenazas futuras. Imagina un atacante que intercepta tu tráfico hoy para intentar descifrarlo dentro de cinco años con nuevos recursos computacionales. Con PFS, ese atacante tendría que actuar en el momento exacto de la sesión; si pierde esa ventana, lo siento, no hay segunda oportunidad. Esa postura vale mucho frente a la tendencia de ‘captura ahora, descifra después’.

¿Quién necesita esto sí o sí?

Respuesta sencilla: todos los que no quieren que su pasado los alcance en el futuro. Bancos, fintech y aseguradoras, por supuesto. Empresas IT, enfoque DevOps, acceso a Git y artefactos, también. Organizaciones médicas con datos personales, bufetes con correspondencia confidencial, proveedores de servicios en la nube, medios, incluso freelancers que se conectan a VPN de clientes desde redes distintas. A menudo escuchamos: «Somos pequeños, ¿a quién le importamos?». Pero los ataques masivos, baratos y automatizados no discriminan. Cuando se trata de cifrado, el tamaño del negocio ya no es excusa.

Y sí, no es exclusivo para B2B. VPN caseras para privacidad y streaming, routers con clientes integrados o apps móviles — si el protocolo incluye PFS, tu pasado seguirá siendo pasado.

Cripto-abc: claves y sesiones en VPN

Claves de sesión vs. claves a largo plazo

Las claves a largo plazo son tu “pasaporte”: confirman que eres quien dices ser. El servidor VPN tiene un certificado y clave privada, el cliente sus credenciales, a veces también un certificado. Estas claves duran mucho y se cambian con poca frecuencia. Las claves de sesión son tickets desechables: se generan en cada conexión, duran minutos u horas y desaparecen sin dejar rastro.

En esquemas tradicionales sin PFS, si alguien obtiene la clave privada del servidor, el archivo histórico de tráfico interceptado es oro puro: con una sola clave puedes descifrar miles de sesiones. PFS rompe esa dependencia: la clave a largo plazo solo ayuda a acordar un nuevo secreto de sesión, pero no puede recuperarlo retroactivamente.

Cifrado simétrico y asimétrico

En VPN y TLS suelen convivir dos mundos. La criptografía asimétrica (pares de claves, certificados) se usa para autenticar las partes y para el intercambio seguro del secreto. La simétrica (una clave compartida) sirve para cifrar rápido el flujo de datos una vez hecho el handshake. Es un balance entre velocidad y seguridad: la asimétrica es más lenta, necesaria al inicio; la simétrica, más rápida, se encarga del resto.

PFS se aplica en la etapa de intercambio de claves. Nos ponemos de acuerdo en un secreto común temporal sin revelar el valor en claro. A partir de ese secreto generamos claves para cifrado simétrico (AES-GCM, ChaCha20-Poly1305). Y arrancamos la transmisión.

¿Dónde residen las claves en la práctica?

Las claves del servidor a largo plazo suelen guardarse en almacenes seguros, a veces en módulos hardware (HSM). Las claves de sesión viven en la memoria de los procesos, por poco tiempo y de forma ágil. En soluciones VPN modernas, es buena práctica minimizar el logging de material de handshake, limpiar memoria, limitar privilegios y usar implementaciones cifradas seguras.

Es clave entender que seguridad no es solo matemáticas. Es disciplina operativa: permisos adecuados, actualizaciones, control de bibliotecas, desactivar algoritmos débiles. PFS no te salva si la clave privada está en tu escritorio como un archivo key.pem. Pero como parte de un sistema bien configurado, es un escudo poderoso.

¿Cómo funciona Perfect Forward Secrecy en pocas palabras?

Definición e idea clave

PFS es una propiedad del protocolo donde la filtración de claves a largo plazo no revela secretos de sesiones pasadas. Se consigue con claves efímeras (de un solo uso) para cada handshake. Lo esencial es que no hay vínculo criptográfico entre la identidad a largo plazo y el secreto de sesión. La conexión existe solo en el intercambio y es unidireccional.

En otras palabras, aunque alguien robe mañana tu clave privada del servidor, las conversaciones de ayer quedarán secretas. No hay botón mágico para “descifrar el pasado”. La clave de sesión no se almacena y es imposible calcularla solo con las trazas públicas si los parámetros y curva están bien configurados.

Claves efímeras: nacen rápido, desaparecen rápido

Las claves efímeras son pares temporales creados para un intercambio concreto. El cliente genera su clave privada efímera, el servidor la suya. Se intercambian las partes públicas y calculan un secreto común que nadie externo puede ver. Con eso derivan las claves para cifrado simétrico usando funciones KDF (HKDF). Terminado el uso, las destruyen. Elegancia pura.

Esto lleva a una conclusión importante: el valor del tráfico interceptado con PFS se deprecia más rápido que un yogur sin refrigerar. ¿Quieres descifrarlo? Deberías intervenir justo en ese momento del handshake y la sesión activa. Si llegas tarde, el tren ya partió.

Ruptura de herencia: cómo PFS ‘corta’ el pasado

En esquemas sin PFS, las claves de sesión se derivan del secreto a largo plazo. Si alguien obtiene la clave principal, accede a todas las conversaciones anteriores. Con PFS eso no ocurre. El único nexo entre los datos largos y sesiones específicas es la autenticación y pacto de parámetros. Pero el secreto es producto de claves efímeras, independientes del certificado del servidor o la cuenta del cliente.

Es como si para cada llamada compraras un teléfono desechable, hablaras veinte minutos y luego lo tiraras a la basura. Aunque alguien robe tu agenda, las conversaciones del teléfono desechado no sirven de nada.

Intercambio de claves Diffie-Hellman y ECDHE en detalle

Diffie-Hellman clásico: paso a paso

La esencia del DH es simple y genial. Las partes acuerdan parámetros públicos de grupo: números grandes y módulo (en versión clásica) o una curva (en ECDH). El cliente elige un secreto a, el servidor otro b. El cliente envía g^a mod p, el servidor g^b mod p. Cada uno calcula el secreto común g^(ab) mod p con su componente privado y la parte pública del otro. Pero un tercero que vea solo g^a y g^b, sin conocer a o b, no puede calcular g^(ab).

Para reforzar seguridad se usan grupos estandarizados con resistencia comprobada y se evita reutilizar claves efímeras privadas. El corazón es el problema del logaritmo discreto, que sigue sin solución eficiente en tiempo real con parámetros sólidos.

ECDHE: curvas elípticas para velocidad y fiabilidad

ECDHE sustituye la aritmética modular por la aritmética sobre puntos de curva elíptica. Ventajas: claves más pequeñas con igual resistencia y alta velocidad, especialmente en móviles y dispositivos embebidos. En 2026, la curva de facto es X25519 (Curve25519) para ECDH: rápida, segura, con implementaciones cuidadas.

El esquema es parecido: ambas partes intercambian puntos públicos, multiplican el punto recibido por el escalar privado y obtienen el secreto común, una coordenada que luego usa HKDF para derivar claves. La ‘E’ en ECDHE significa efímero, es decir, claves de un solo uso. Esa es la implementación práctica de PFS en el handshake.

Por qué interceptar no ayuda al atacante

Un interceptador pasivo ve solo componentes públicos y tráfico cifrado. Para recuperar el secreto debería resolver un problema matemático complejo (logaritmo discreto en grupo o curva), sin solución práctica con parámetros correctos. La clave a largo plazo del servidor tampoco ayuda: no contiene secretos efímeros, solo firma o autentica el intercambio.

Los ataques activos (como man-in-the-middle) chocan contra la autenticación: certificados, claves precompartidas con autenticación, mecanismos como tls-auth o tls-crypt en OpenVPN. Sin romper la confianza no hay forma de intervenir sin dejar rastro. Y si la confianza es fuerte, el archivo interceptado queda inútil.

Por qué el tráfico interceptado no se puede descifrar después

Modelo de amenaza harvest-now-decrypt-later

Es un escenario real: un adversario graba tus sesiones cifradas durante años con la esperanza de obtener la clave privada del servidor o tecnología cuántica para revisitar ese archivo. Sin PFS esto funciona alarmantemente bien. Con PFS, casi nada, porque las claves de sesiones pasadas no se recuperan de filtraciones futuras.

Vemos cómo grandes jugadores mitigan riesgo: sesiones cortas, parámetros ECDHE estrictos, prohibición de cifrados y protocolos antiguos. La idea es clara: separar el pasado para evitar problemas futuros. Puede sonar técnico, pero es una defensa estratégica.

Qué se rompe sin PFS

Sin PFS, la filtración futura del servidor revela todo lo que alguna vez cifró. Es como una llave maestra que abre toda la casa guardada en un solo lugar: si se pierde, no solo se abre la caja fuerte, también todas las habitaciones. Además, la tentación de mantener sesiones largas para ahorrar CPU empeora el problema: cuanto más tiempo vive una clave, más valiosa es para un atacante.

Y aunque todo parezca controlado hoy, mañana puedes actualizar una biblioteca, aparece una vulnerabilidad, alguien sube un volcado de memoria… y el tráfico antiguo estará en riesgo. PFS convierte esas catástrofes en molestias de bajo impacto local.

Con PFS, la filtración no retrocede la historia

Imagina que tu clave privada del servidor fue robada. Malo, sí. Pero el archivo cifrado del último año se mantiene seguro. El atacante tendrá que esperar nuevas conexiones, actuar en tiempo real, y solo si puede intervenir en la cadena de confianza. Esto eleva mucho la barrera de ataque y disminuye riesgos.

Por otro lado, PFS no elimina reglas básicas: rotación de certificados, políticas estrictas de acceso, logs limpios sin secretos, protección de endpoints. Es un trabajo en equipo. Pero PFS es un delantero poderoso en tu defensa criptográfica.

Protocolos VPN que soportan PFS en 2026

TLS 1.3: PFS por defecto

En TLS 1.3 PFS no es opcional sino la norma. Todo el proceso de handshake se basa en (EC)DHE. No hay intercambio RSA anticuado. En VPN esto importa para OpenVPN (modo TLS) y servicios HTTPS (DoH, HTTP/3). Además, criptografía simplificada, menos handshakes y mejor rendimiento.

En 2026 la mayoría de clientes y servidores ya usan TLS 1.3, lo que te garantiza PFS si no activas configuraciones antiguas por «compatibilidad». La regla es sencilla: TLS moderno, curvas modernas, y tendrás secreto directo.

OpenVPN: ECDHE y tls-crypt como caballo de batalla

OpenVPN soporta PFS hace tiempo vía DHE/ECDHE. Parámetros recomendados: tls-version-min 1.2 (mejor 1.3 donde sea posible), ECDHE con X25519 o secp256r1, cifrados AES-256-GCM o ChaCha20-Poly1305, y tls-crypt activado para proteger el canal de control. Con esta configuración no solo tienes PFS, sino también protección de metadatos contra espionaje pasivo.

En 2026, muchos admins prefieren X25519 por rapidez y simplicidad, fijan reneg-sec entre 3 y 5 minutos para actualizar claves regularmente y usan verify-x509-name para validar estrictamente el servidor. Económico, fiable y resistente.

WireGuard: PFS incorporado al diseño

WireGuard se basa en el protocolo Noise IK y usa ECDH sobre Curve25519 (X25519) con rekey regular. Claves efímeras y sesiones cortas son ADN del estándar. Las claves se recalculan cada 120 segundos o tras cierto volumen de datos. PFS aquí no es opción, sino práctica habitual.

En 2026 WireGuard está casi en todas partes: kernels Linux, routers, OS móviles e infraestructuras SASE/ZTNA. Ofrece rendimiento excelente en móviles, recuperación estable de sesiones en roaming y criptografía transparente sin opciones complejas que rompan.

IKEv2/IPsec: clásico potente con PFS en Fase 2

En IKEv2, PFS se activa en CHILD_SA (segunda fase). En configuración se traduce en requerir Diffie-Hellman adicional para cada SA. Elige grupos modernos: ECP (ej. ECP256) o ffdhe3072 y superiores, y recuerda rekey cada 30-60 minutos de tráfico activo.

Buenas noticias: implementaciones modernas como strongSwan, libreswan y gateways comerciales en 2026 recomiendan PFS y grupos estrictos por defecto. Mala noticia: algunos perfiles antiguos sin PFS aún existen y deberían migrarse cuanto antes.

Rendimiento y sobrecarga: ¿da miedo activar PFS?

Números prácticos: overhead en handshake

Mito: “PFS ralentiza mucho”. Realidad: en CPUs actuales y con algoritmos adecuados, el overhead en handshake son decenas de milisegundos. En sesiones VPN largas es imperceptible frente a la transferencia y latencia de red. TLS 1.3 ha optimizado mucho los handshakes, y WireGuard ahorra complejidad de protocolo.

Mediciones 2025-2026 en VM cloud con AES-NI y ECDHE X25519 muestran costos del 1-3 % del tiempo de establecimiento de canal. En ARM móviles con ChaCha20-Poly1305 el resultado es similar: carga extra mínima y seguridad mucho mayor.

Elección de cifrados según hardware

Si tienes servidores x86 con AES-NI, AES-128/256-GCM vuela. En ARM y móviles, ChaCha20-Poly1305 suele superar a AES. Lo esencial: no mezclar cifrados obsoletos por «compatibilidad». En 2026 podemos vivir tranquilos con ECDHE X25519 + AES-GCM o ChaCha20-Poly1305.

Ayudan también ajustes correctos de MTU, configuración cuidadosa de colas y desactivación de opciones viejas que añaden metadatos innecesarios. Y, por supuesto, mantener actualizadas las librerías criptográficas: OpenSSL, BoringSSL, wolfSSL modernas están mejor optimizadas que el software antiguo.

Rekey óptimo y temporizadores

La frecuencia de cambio de claves es un balance. Muy pocas veces aumenta riesgo, muy seguido usa CPU. Valores prácticos: 2-5 minutos en escenarios tipo WireGuard, 30-60 minutos en CHILD_SA de IPsec con túneles estables, 3-10 minutos en reneg de OpenVPN. Si el flujo es muy intenso y constante, opta por un punto medio y monitoriza métricas.

Indicador clave: latencias p95/p99 al establecer flujo tras rekey. Si picos son bajos, los usuarios no notan nada. Y reduces significativamente el riesgo de claves «largas».

Práctica: cómo activar y verificar PFS

Chequeo rápido en TLS y HTTPS

Aunque hablamos de VPN, conviene saber verificar PFS en HTTPS porque la mecánica es la misma. Mira qué intercambio de claves usa: ECDHE o DHE está bien, RSA mal. Herramientas actuales muestran la curva (X25519, secp256r1) y cifrados (AES-GCM, ChaCha20). Si ves X25519 y TLS 1.3, tienes PFS automáticamente.

Para diagnóstico interno, revisa logs del servidor, activa modo verbose en entorno de pruebas y confirma que se usan claves efímeras, no acuerdos estáticos. Fácil: hay ECDHE = hay PFS.

OpenVPN: qué buscar en configuración

Busca tls-version-min 1.2 o 1.3, configura tls-cipher o ncp-ciphers con ECDHE, activa tls-crypt o tls-auth, establece reneg-sec razonable. En el servidor, genera parámetros DH, pero para seguridad y velocidad usa ECDHE con X25519. Confirma que remote-cert-tls server está activado en cliente y verify-x509-name comprueba nombre del servidor. Esto previene MiTM y asegura que PFS actúa correctamente.

Chequea logs: en handshake deben aparecer ECDHE y cifrados AEAD modernos. Si ves clave estática sin intercambio efímero, algo falla.

WireGuard: vistazo a rekey y curva

WireGuard integra PFS con Noise. Si usas versiones estándar, ya tienes ECDH X25519 y cambios periódicos de clave. Revisa la frecuencia del rekey, por defecto unos 120 segundos de actividad. No debe haber logging excesivo de material clave.

Para validar, activa debug en nodo de prueba, monitorea establecimiento de sesiones, volumen de datos y reconexiones tras cambio de red. Si todo está estable, PFS funciona como esperado.

IKEv2/IPsec: PFS en CHILD_SA

Verifica que el perfil pide DH extra en creación de CHILD_SA. Elige grupos modernos: ECP256 o superior, ffdhe3072 o 4096. Ajusta rekey cada 30-60 minutos, o más frecuentemente para datos sensibles. Asegúrate que grupos obsoletos (modp1024) estén deshabilitados.

Consulta logs del gateway: en establecimiento de CHILD_SA deben figurar líneas con grupo DH para PFS. Si no aparecen, CHILD_SA se crea sin forward secrecy y hay que corregir la política urgentemente.

Buenas prácticas para parámetros y política criptográfica en 2026

Curvas y grupos

Recomendación 2026: X25519 como curva principal para ECDHE y ECDH. Alternativa aceptable es secp256r1 para compatibilidad con HSM corporativos y ciertos equipos de red. Para DH clásico, mínimo ffdhe2048, preferible ffdhe3072. Pero lo ideal es elegir X25519 por simplicidad y rapidez.

Evita curvas con historial dudoso o grupos muy antiguos. Lista «no»: secp192r1, modp1024, curvas exóticas sin revisión amplia. Cuanto más universal y popular la curva, mejor afinadas sus implementaciones y menos riesgos de bugs.

Cifrados y modos

Mandatos AEAD: AES-128/256-GCM y ChaCha20-Poly1305. Sin CBC, RC4 y reliquias. En x86 con AES-NI, AES-GCM vuela. En ARM y grupos mixtos, ChaCha20-Poly1305 es la opción universal. La clave: menos variantes, menos confusión y menos riesgos de “activar algo inseguro”.

HKDF (basado en SHA-256) es la función estándar para derivar claves del secreto común. Asegúrate que no haya dependencias viejas con SHA-1. No compliques parámetros solo por estética; eso no mejora seguridad.

Rotación de claves y control de superficies

Planifica rotación de certificados server cada 12-18 meses, o mejor automatiza. Para sesiones, intervalos razonables de rekey (minutos, no horas) y prohíbe túneles «eternos». Loguea lo mínimo, no guardes secretos, recorta campos sensibles. La realidad: menos guardas, menos tienes que proteger y limpiar.

Y sí, actualizaciones. En 2026 aún hay vulnerabilidades críticas. Parchear rápido una librería criptográfica suele ser más barato que cualquier investigación forense y mucho menos costoso que daños reputacionales.

PFS y criptografía post-cuántica: mirando cinco años adelante

Riesgo cuántico: sin pánico, con plan

Los ordenadores cuánticos todavía no rompen ECDH ni RSA en el mundo real, pero la moda de «captura ahora, descifra después» obliga a estar alerta. PFS reduce el valor de archivos interceptados porque para descifrar sesiones pasadas habría que intervenir en el momento del handshake, no luego con un “espada cuántica”.

No evita que avancemos hacia esquemas post-cuánticos, pero gana tiempo. Concretamente: activa PFS, actualiza protocolos y sigue de cerca la implementación de handshakes híbridos.

Handshakes híbridos: X25519 más KEM post-cuántico

En 2026 la industria debate masivamente handshakes híbridos: ECDHE clásico (ej. X25519) combinado con un KEM post-cuántico (familia ML-KEM, antes conocido como Kyber). La idea: resistencia simultánea a ataques clásicos y cuánticos durante el periodo de transición. Si una parte falla algún día, la otra permanece segura.

Para VPN, esto está en marcha: pilotos para TLS, experimentos en IKEv2, propuestas para extender WireGuard. Si planeas que tu producto dure, piensa en evolutivo para la pila criptográfica; pero no sacrifiques la seguridad actual por escenarios hipotéticos — PFS ya cierra el agujero principal contra descifrado retrospectivo.

Hoja de ruta de adopción

Plan realista: hoy mismo usar ECDHE con PFS y cifrados modernos, actualizar librerías regularmente, monitorear soporte a handshakes híbridos en tus plataformas. Cuando los estándares maduren y haya soporte mainstream, planifica rollout gradual: entornos de prueba, canarios, migración progresiva de clientes.

Importante: los algoritmos post-cuánticos suelen tener claves y mensajes más grandes, afectan MTU y rendimiento. Haz pruebas previas para evitar problemas bajo carga pico en producción.

Errores comunes y anti-patrones

Claves estáticas y PSK sin PFS

El peor hábito es usar claves estáticas por “comodidad” y predictibilidad. Un archivo, un secreto, decenas de clientes. Fácil hasta la primera fuga. Después, todo el archivo de sesiones en manos del atacante. Si usas PSK, hazlo solo con acuerdos efímeros y autenticación adicional para mantener PFS.

Lo mejor: certificados con TLS moderno y ECDHE, o WireGuard con gestión simple de claves y secreto directo incorporado. Estática solo donde no haya alternativa, con segmentación estricta y cambios frecuentes.

Reutilización de parámetros DH y RNG deficiente

Reutilizar valores efímeros es pecado capital. Un generador de números aleatorios débil es peor. En VMs sin suficiente entropía, contenedores sin rngd, kernels viejos, es un riesgo real. La solución: kernels modernos, librerías criptográficas probadas, fuentes hardware de entropía, inicialización temprana.

Dicho claro, mejor configurar bien el generador de números aleatorios desde el principio que dedicar semanas a investigar handshakes «deterministas» y repetitivos.

Sesiones largas y ahorro en “cerillas”

Ahorra en rekey es mala idea. Sesiones que duran días sin cambiar claves amplían ventana de riesgo. Distribuye carga de handshakes en el tiempo y ajusta temporizadores. Pero dejar clave mucho tiempo es un anzuelo para el atacante. Piensa así: la clave es consumible, no reliquia.

No olvides monitoreo: recoge métricas de reconexiones, fallos de handshake, latencias. Ajusta tiempos donde veas anomalías. Controla, no adivines.

FAQ: breve y directo

Preguntas básicas

Aquí tienes respuestas simples para explicar rápido a un colega por qué PFS importa justo ahora.

1. ¿Qué es Perfect Forward Secrecy en palabras sencillas? Es una forma de hacer que si roban claves mañana, no se puedan leer las conexiones de ayer. Cada sesión VPN se cifra con una clave única y desechable que desaparece tras acabar.
2. ¿Por qué no se puede descifrar el tráfico interceptado después? Porque la clave de sesión no está ligada a la clave larga del servidor. Surge en un intercambio efímero (ECDHE) y no se almacena. Sin clave, nada que descifrar retroactivamente.
3. ¿Qué protocolos VPN soportan PFS en 2026? WireGuard por defecto, OpenVPN con ECDHE, IKEv2/IPsec con PFS activado en CHILD_SA y cualquier servicio TLS 1.3 que sustente soluciones VPN.

Preguntas técnicas

Detalles para quienes configuran y quieren hacerlo bien desde el inicio.

1. ¿Qué parámetros elegir para un PFS seguro? ECDHE con X25519, cifrados AEAD AES-GCM o ChaCha20-Poly1305, HKDF-SHA256. Para IKEv2, PFS con ECP256 o ffdhe3072 y rekey periódico.
2. ¿Cuánto afecta PFS al rendimiento? Mínimo en CPUs modernas. Normalmente 1-3 % de overhead en handshake. En sesiones largas, casi imperceptible.
3. ¿PFS ayuda contra ataques cuánticos? Disminuye el valor de archivos interceptados porque sin intervención en el momento del handshake, sesiones pasadas no se pueden abrir. La protección completa contra amenazas cuánticas requieren handshakes híbridos o post-cuánticos, que están empezando a implementarse.