Cifrado asimétrico vs simétrico en VPN: explicado de forma sencilla y con ejemplos

Seamos honestos: hay muchas siglas en el mundo VPN, y no siempre resultan fáciles de digerir. RSA, ECDH, PFS, AEAD, IKEv2, TLS 1.3, NoiseIK — marean, y no tenemos tiempo para empezar desde cero. Pero no necesitamos reinventar la criptografía. Nuestro objetivo es entender cómo el túnel VPN combina cifrado asimétrico y simétrico, por qué se usan ambos métodos, cuándo y dónde aparecen las claves de sesión, qué parámetros importan en 2026 y qué elegir en la práctica para que la conexión sea rápida y segura. Sin fórmulas complicadas. Hablaremos claro, con ejemplos de IPsec, OpenVPN y WireGuard. Explicaremos con lógica: la asimetría sirve para intercambiar secretos sin tener una clave común previa, la simetría cifra datos rápido y seguro. Un papel sencillo y un juego efectivo. Además, mostraremos cifras de rendimiento, analizaremos apretón de manos híbridos post-cuánticos y añadiremos un checklist práctico: qué activar, qué desactivar y errores comunes. Empecemos por lo esencial: cómo funciona esto en el túnel.

Cómo funciona el cifrado en VPN en la práctica

Por qué simetría y asimetría no son rivales

El secreto de cualquier protección VPN moderna es que el cifrado asimétrico y simétrico no compiten, sino que se complementan. Son como el embrague y el motor de un coche: uno arranca y cambia, el otro mueve el vehículo. La asimetría (RSA, ECDH) resuelve el problema de intercambiar un secreto entre partes que no tienen ninguna clave común antes de encontrarse. Realiza el "apretón de manos", verifica identidades, negocia parámetros y genera una clave de sesión común. Todo sin riesgo de gritar tu contraseña en medio de una multitud. La simetría (AES, ChaCha20) toma el testigo tras el apretón, cifrando el grueso del tráfico rápido y con bajo costo.

¿Por qué? Porque las operaciones asimétricas son costosas, ejecutar muchas impacta CPU y latencia. Las simétricas son ligeras y rápidas, especialmente en modos AEAD como AES-GCM y ChaCha20-Poly1305. Entonces, la fórmula es clara: un apretón de manos asimétrico breve para intercambiar claves de sesión y luego cifrado simétrico prolongado. Resultado: alto rendimiento, resistencia al espionaje y equilibrio perfecto entre seguridad y velocidad. No solo ahorramos recursos, sino que también activamos propiedades importantes como la Perfect Forward Secrecy (PFS), para que la compromisión de una clave a largo plazo no revele sesiones pasadas.

Qué son las claves de sesión y para qué sirven

Una clave de sesión es un secreto único para una sesión específica. Se genera durante el apretón de manos (por ejemplo, vía ECDH o mecanismo similar), dura solo esa sesión y desaparece al terminar o renovarse (rekey). Gracias a las claves de sesión, la VPN garantiza que aunque alguien robara tu clave privada a largo plazo (como la del servidor), no podría descifrar retroactivamente tráfico antiguo. Esto es la implementación práctica de la Perfect Forward Secrecy.

La clave de sesión no es un solo parámetro, sino un conjunto: claves para cifrado y autenticación en ambos sentidos, a veces varias para distintos niveles (en IPsec: IKE SA y Child SA), más contadores, “sal” y otros detalles criptográficos. Su vida está limitada: por tiempo (por ejemplo, 60 minutos), volumen de datos (1–4 GB), o ambos. Esto reduce riesgos de que la estadística sobre texto cifrado dé pistas a un atacante. Y además, si hay fallos, simplemente renovamos claves y seguimos funcionando.

Dónde residen las claves y cómo desaparecen

Las claves viven en la memoria del proceso del demonio VPN y en módulos criptográficos del núcleo o de tarjetas de red si hay offload. No deben almacenarse en disco en texto claro, y siquiera los volcados de memoria en producción no son aconsejables. Buenas prácticas incluyen envolver claves privadas del servidor en HSM o TPM, y mantener las de sesión solo en RAM con limpieza explícita al terminar. Y claro, nunca copias en logs: aquí no se juega.

La “muerte” de la clave es parte normal del ciclo vital. ¿Terminó la sesión? Se borran materiales, contadores y buffers. ¿Se alcanzó el límite por volumen o tiempo? Se renueva con un nuevo ECDH, obteniendo nuevas claves sin interrumpir el túnel. En flujo normal, ni notarás el proceso: una ráfaga corta de paquetes de control y el tráfico continúa como si nada.

Cifrado asimétrico: RSA, ECDSA, ECDH y X25519

RSA: clásico, pero no para siempre

Durante años RSA fue el icono del cifrado asimétrico en VPN: sencillo, claro, omnipresente. En OpenVPN se usan certificados RSA, en IKEv2 la autenticación es con firmas RSA. Esto resulta cómodo, compatible y estable. Pero el mundo avanza: las claves crecen, el precio computacional también, y la movilidad exige rapidez. En 2026 RSA-2048 sigue aceptable en la mayoría de escenarios, pero para infraestructuras longevas es preferible RSA-3072 o pasar a firmas con curvas elípticas (ECDSA/Ed25519), donde la seguridad mejora con menor costo en CPU.

Importante entender que RSA rara vez cifra datos directamente en VPN. Su rol es autenticar y a veces cifrar material clave, pero en protocolos modernos es una parte en el intercambio híbrido junto a ECDH. La tendencia clara: RSA queda para compatibilidad y entornos legales con PKI complejos, pero si buscas velocidad en el apretón y ahorro energético, ECDSA, EDDSA (como Ed25519) y, claro, ECDH con X25519 son mejores opciones.

Curvas elípticas y ECDH: velocidad y seguridad

ECDH es el caballo de batalla para intercambio de claves. Permite que dos partes calculen un secreto común sin revelar valores privados. Hoy domina X25519, que es rápido, resistente a muchos ataques, sencillo de implementar y eficiente en servidores y móviles. P-256 y P-384 siguen vivos y soportados, pero X25519 es el estándar de facto en VPN moderna.

¿Para qué? Porque ECDH provee el “combustible” para cifrado simétrico en sesión. Negociamos curva elíptica, intercambiamos puntos públicos, calculamos secreto común y luego derivamos claves por KDF. Resultado: PFS, mínima latencia en el handshake y sin necesidad de manejar secretos comunes a largo plazo. Todo limpio y eficiente.

PFS, grupos DH e intercambio de claves sin estrés

Perfect Forward Secrecy es el escudo que protege tu tráfico. La idea es simple: aunque un atacante tenga la clave privada del servidor, no podrá descifrar sesiones previas porque estas usan claves efímeras generadas en cada apretón (ECDHE, la E significa ephemeral). En IPsec esto implica elegir grupos ECP (como 19/20/21 para P-256/P-384/P-521) o curvas modernas como X25519. En OpenVPN sobre TLS 1.3, ECDHE es obligatorio. WireGuard usa X25519 con efimeridad integrada.

No te asustes, es cuestión de configuración: escoge grupos DH modernos, activa PFS en todos los child SA en IPsec, no limites fuente de entropía ni sobrecargues el handshake en redes con alta pérdida. Recuerda también que PFS exige rekey regular o pierde sentido. Nada místico: unas opciones bien puestas en el config y listo.

Cifrado simétrico en el túnel: la velocidad manda

Modos AEAD: AES-GCM y ChaCha20-Poly1305

La simetría son nuestros valiosos kilobytes y megabytes en acción. En 2026 las estrellas son los modos AEAD: AES-GCM y ChaCha20-Poly1305. AEAD (Authenticated Encryption with Associated Data) cifra y autentica simultáneamente, evitando errores comunes de cifrado sin verificación de integridad. Resultado: menos sobrecarga y configuración más sencilla. AES-GCM brilla en hardware con AES-NI (x86) o extensiones ARMv8 Crypto, alcanzando gigabits por núcleo. ChaCha20-Poly1305 sobresale donde no hay aceleración hardware, sobre todo en móviles, ofreciendo rendimiento predecible y baja latencia.

OpenVPN, WireGuard e IPsec soportan ambos hace tiempo. WireGuard usa ChaCha20-Poly1305 por defecto, explica su eficiencia energética en móviles. IPsec suele usar AES-GCM-128 o -256, especialmente con offload en kernel y NIC. Hay que controlar contadores (nonce) para evitar sobrepasarlos, de ahí la necesidad de rekey por volumen de datos.

Longitud de claves y significado real de 128 vs 256

En VPN reales, AES-128-GCM y AES-256-GCM son ambos muy seguros. La diferencia teórica no es tan relevante. AES-128-GCM suele ser más rápido en hardware antiguo, con menor latencia y más throughput. ChaCha20-Poly1305 tiene una longitud fija y también ofrece gran margen de seguridad. Consejo: si tienes servidores nuevos con AES-NI, usa AES-GCM-128 o -256, prueba ambos y observa uso de CPU. En móviles y contenedores sin aceleración, ChaCha20-Poly1305 es la mejor opción para no complicarte.

¿Y la amenaza cuántica? Afecta más al cifrado asimétrico que al simétrico. Incrementar la longitud de la clave simétrica es una solución directa. Pero si ya usas AES-128-GCM, no te alarmes. Para datos sensibles a largo plazo y archivos almacenados, AES-256-GCM es preferible. A menudo, rotar claves de forma correcta aporta más seguridad que solo subir el tamaño de la clave.

Aceleraciones hardware: AES-NI, ARMv8 CE, NIC offload

El rendimiento VPN hoy depende mucho de si tu hardware puede cifrar "al vuelo". En x86, AES-NI es estándar y proporciona decenas de gigabits en procesadores modernos. Servidores ARM (y móviles) usan ARMv8 Crypto Extensions con velocidades sólidas para AES-GCM. Y no olvides NIC offload: algunas tarjetas liberan CPU al manejar IPsec en hardware. No es magia, pero en enlaces 10G o 25G el offload a menudo decide el resultado.

Esto implica que la elección del cifrado debe considerar el hardware real. OpenVPN sin AES-NI puede quedar atrás respecto a WireGuard en un chip móvil que usa ChaCha20-Poly1305. Con Linux y XDP puedes optimizar aún más. Y por supuesto, perfilar con perf, eBPF, métricas de CPU y latencias pequeñas puede importar más que la “belleza” teórica del algoritmo en papel.

Combinación en diferentes protocolos VPN

IPsec/IKEv2: dos niveles, un objetivo

IPsec es el “abuelo túnel”, pero sigue vivo y eficiente. Su arquitectura tiene dos niveles: IKEv2 gestiona el handshake, intercambio de claves y autenticación; el tráfico lo cifra ESP (Encapsulating Security Payload). En IKEv2 se negocian algoritmos: grupos ECDH (como X25519), firmas (ECDSA, RSA) y se establecen SA. Luego se crean Child SA para cifrar tráfico real con AEAD (AES-GCM-128/256) y contadores.

En la práctica: configuras política de cifrado, eliges PFS, defines tiempos de rekey (IKE SA unas 8 horas, Child SA 1 hora o 1–2 GB), controlas NAT-T y MTU. Con buena configuración IPsec puede alcanzar decenas de gigabits con offload hardware. En 2026 muchos proveedores experimentan con modos híbridos PQC en IKEv2, aún más en pilotos que en producción. El stack principal sigue siendo ECDH X25519 y AES-GCM.

OpenVPN y TLS 1.3: handshakes sin charla extra

OpenVPN dejó atrás “solo túnel SSL” y ya usa TLS 1.3, reduciendo handshakes y eliminando partes delicadas del pasado. En TLS 1.3, ECDHE es obligatorio, garantizando PFS; autenticación con ECDSA o RSA. Tras handshake, OpenVPN usa cifrado simétrico: AES-GCM o ChaCha20-Poly1305, con muchas distribuciones que prefieren ChaCha en hardware limitado. Rotación de claves se controla con reneg-sec y límites de datos.

Para 2026: apuesta a TLS 1.3 con criptografía estricta, elimina suites antiguas, activa verify y pinning de raíz si usas PKI propia. Ajusta MTU y MSS; OpenVPN sobre UDP rinde mejor y es más estable en redes con pérdidas que sobre TCP. No olvides “data-ciphers”: solo enumera AEAD. Lo demás es superfluo.

WireGuard/NoiseIK: minimalismo y modernidad

WireGuard es exitoso por su protocolo NoiseIK sencillo, código minimalista y criptografía moderna lista para usar. Para intercambio de claves usa X25519, para cifrado ChaCha20-Poly1305, para hashes BLAKE2s, con rekey automático cada ~120 seg sin tráfico y según volumen — rápido y transparente. No intenta ser todo para todos, pero cumple magistralmente su función: túnel L3 rápido y seguro.

La magia real de WireGuard está en configuraciones simples y eficiencia móvil. Funciona de maravilla en CPUs limitados, y su implementación en kernel Linux minimiza latencias. Ojo con detalles prácticos: claves estáticas son cómodas, pero en ambientes estrictos es mejor integrar WireGuard con PKI y emisión automatizada de peers autorizados. En 2026 hay desarrollos independientes de handshakes híbridos PQC para WireGuard, aunque la estandarización y auditoría en mainstream aún esperan.

Tendencias cuánticas 2026: handshakes híbridos

NIST PQC y Kyber/Dilithium en contexto VPN

De 2022 a 2024, NIST seleccionó algoritmos post-cuánticos y en 2026 la industria experimenta su implementación. En el escenario de intercambio de claves destaca Kyber (CRYSTALS-Kyber), para firmas Dilithium y Falcon. ¿Qué significa para VPN? Handshakes híbridos: ECDH X25519 más Kyber para resistir amenazas clásicas y cuánticas. Firmas Dilithium pueden reemplazar RSA/ECDSA en cadenas de certificados, pero hay desafíos prácticos: tamaño de claves y certificados, MTU, rendimiento y compatibilidad.

No hay que caer en extremos. La migración total a PQC es prematura para la mayoría de proyectos VPN. Los híbridos son un puente racional: suman Kyber a X25519, prueban latencia y comportamiento en red real, evalúan aumento del handshake y carga CPU. Solo cuando la infraestructura esté lista se avanza. La criptografía en serio no admite errores; pilotos, pruebas y compatibilidad son obligación, no lujo.

Híbrido X25519+Kyber: dónde ya se prueba

En 2026 vemos modos híbridos en algunas compilaciones de OpenVPN y librerías TLS, en parches experimentales IKEv2 y en terminación TLS de NGINX para túneles interservicio. En sector empresarial, bancos y telecom inician pilotos: verifican que DPI no falle, cómo reaccionan balanceadores hardware, impacto en tamaño de hello y necesidad de ajustar MSS. Suele verse que latencia extra en handshake es palpable pero tolerable si se optimiza MTU y se limita la renovación.

¿Dónde cautela? Redes móviles con alta jitter y RTT inestable. Handshakes híbridos aumentan volumen de paquetes de control, elevando riesgo de fragmentación. La solución es simple: piloto, medición, activación solo en segmentos críticos y fallback a X25519 puro hasta que la base de clientes madure.

Lado práctico: MTU, rendimiento, compatibilidad

Algoritmos post-cuánticos suelen aumentar tamaño de claves y mensajes handshake, lo que afecta MTU y fragmentación. Este hecho suele pasarse por alto, y es un error. Si ya usas GRE, VXLAN u otras encapsulaciones, el margen MTU es limitado. Añade handshake híbrido y bienvenida la necesidad de ICMP Fragmentation Needed, que casi nadie permite. Resultado: handshake lento o caído. La prevención es sencilla: reduce MTU en interfaz túnel, activa MSS clamping y monitorea el comportamiento de tus middlebox.

El rendimiento es otro punto. Kyber y Dilithium son rápidos en CPU, pero su “peso” en bytes impacta red. Por eso "más ciclos" no significa "más rápido" necesariamente. La compatibilidad es el tercer pilar: necesitas versiones sincronizadas de librerías en servidor y clientes, y una estrategia clara de rollback. Y siempre registra logs, pero evita incluir datos sensibles criptográficos, solo metadatos y estados.

Gestión de claves y certificados

PKI, raíz, intermedios, OCSP/CRL

Sin PKI, grandes VPN se vuelven un caos. Certificado raíz firma intermedios; estos los de servidor y cliente. Así se consigue jerarquía de confianza manejable. Para revocación se usan OCSP y CRL. En 2026 muchos optan por OCSP stapling y certificados de corta vida para reducir dependencia de CRL centralizados. La regla es clara: cuanto más simple la verificación y más corto el certificado final, menos riesgos.

En práctica se reserva un root offline, guardado en HSM, y se usan intermedios de corta duración para emitir certificados servidores y clientes. Claves ECDSA/Ed25519 aceleran handshake. CRL se limpian periódicamente, respuestas OCSP se repingan y cachean. Renovación de certificados cliente se automatiza con MDM o CI para evitar carreras de última hora.

Políticas de rotación: tiempos, volúmenes, rekey

La rotación es fundamental. Para claves de sesión suele usarse tiempo y volumen de datos: 1 hora y 1–4 GB son valores comunes, siempre adaptados a carga. Para IKE SA conviene vida más larga que Child SA para no saturar handshakes. Para certificados, menor tiempo de vida reduce riesgo pero sube costos operativos si automatización falla.

En OpenVPN controla reneg-sec, reneg-bytes y data-ciphers. WireGuard renueva solo, pero monitorea peers y tiempo de handshake. En IPsec define lifetimes en políticas y no olvides PFS. No abuses del rekey frecuente: charla extra en redes con RTT alto es contraproducente. Encuentra equilibrio.

Almacenamiento seguro: HSM, TPM, permisos en archivos

Claves privadas a largo plazo del servidor deben estar fuera del alcance. HSM es ideal, TPM un buen compromiso, al menos para ligar a máquina específica. Si no hay hardware, controla permisos, usuarios de servicios y aislamiento en contenedores. No guardes claves privadas juntas con backups de configs “tal cual”. Cifra backups, separa secretos del estado común y revisa claves por parámetros débiles.

Claves de clientes son otro tema. En laptops con cifrado de disco y MDM es más sencillo. En móviles usa almacenamiento seguro de plataforma. No olvides lo básico: doble factor donde sea posible, certificados revocados presentes inmediatamente en CRL/OCSP, no “para después”.

Rendimiento y optimización

Elección de cifrado según hardware: escritorio, móvil, nube

El cifrado adecuado depende del hardware. En PCs y servidores con AES-NI vale AES-GCM-128/256. En nubes ARM con extensiones crypto activadas, igual. En móviles, routers SOHO y contenedores sin aceleración, ChaCha20-Poly1305 gana por consumo y estabilidad. WireGuard ofrece un baseline excelente sin complicaciones.

Haz pruebas. Usa iperf3 en túnel, mide RTT, jitter y pérdida. Compara AES-GCM-128 y -256 en tu plataforma: a veces 128 es 5–15% más rápido sin perder seguridad. Observa comportamiento bajo carga máxima: buffers llenos, colas NIC, saturación de núcleo. Sorprendentemente muchas veces el cuello de botella no es el cifrado, sino MSS/MTU.

MTU, MSS, UDP vs TCP, NAT-T y túneles QUIC

MTU es un asesino silencioso. VPN añade encapsulación, reduciendo carga útil. Si no ajustas MTU y MSS, tendrás fragmentación o peor, agujeros negros. Receta simple: reduce MTU en interfaz túnel (1380–1420 para túneles UDP, pero testea), activa MSS clamping y presta atención a ICMP. En IPsec con NAT-T suele usarse UDP/4500, asegúrate que firewalls no lo bloqueen.

UDP suele ser preferido en VPN porque evita problemas TCP sobre TCP. Pérdidas y jitter se toleran mejor, y protocolos de aplicación se encargan de retransmisiones. Túneles QUIC y TLS sobre QUIC son tendencia 2026, especialmente para sortear middleboxes intolerantes. Solo recuerda que añades otro nivel de túnel; no olvides MTU y restricciones de ruta.

Visibilidad completa y pruebas: iperf3, pktloss, jitter

Sin mediciones no hay optimización. Telemetría end-to-end es tu mejor aliada: métricas CPU, latencia en handshakes, frecuencia de rekey, porcentaje de pérdida, distribución de tamaño de paquetes, colas en interfaces. iperf3 para throughput, tc y ping para pérdida y jitter, eBPF para perfilado fino. Descubre dónde se generan demoras: en handshake, rekey o picos de tráfico. ¿La criptografía se queda en un solo núcleo?

No olvides casos reales: consultas cortas y flujos largos se comportan diferente. Segmenta pruebas: paquetes de 64 KB son una cosa, 1–4 MB otra. Usa cargas con trazas grabadas. Sí, lleva más tiempo que un “test de velocidad”, pero descubrirás cuellos de botella inesperados, como fragmentación o configuración de colas.

Errores comunes y checklist de implementación

Cifras débiles y protocolos obsoletos

El error principal es mantener en la lista de compatibilidad lo que ya debe descartarse. RC4, 3DES, CBC sin AEAD, grupos DH antiguos sin PFS — no deben estar en producción ni pruebas. En TLS 1.2 y más aún en 1.3, elimina compresión, renegociación innecesaria y extensiones exóticas. IKEv1 ya no tiene sentido, solo IKEv2. En OpenVPN usa solo data-ciphers modernos y lista estricta, nada de “any”.

Otro punto: confundir autenticación con cifrado. Certificados RSA sirven para firmas y verificación, no para cifrar tráfico principal. Este último se cifra con simétricos, elige AEAD y deja atrás CBC+HMAC por costumbre. Menos es más, menos errores.

Entropía y números aleatorios deficientes

Si falla el RNG, todo falla. Falta de entropía al iniciar VMs, contenedores con fuentes restringidas, RNG no inicializados en dispositivos embebidos — camino directo a claves predecibles. En 2026 usa núcleos modernos con getrandom, monitorea estado del RNG al inicio, ejecuta haveged o similar solo cuando es necesario y conoce riesgos. Mejor fuentes hardware cuando estén disponibles.

Verifica librerías criptográficas y sus versiones. Actualiza OpenSSL, BoringSSL, wolfSSL, LibreSSL — no por moda, sino porque vulnerabilidades en bajo nivel afectan todo el sistema. Y no registres materiales aleatorios o claves en logs. Nunca. Ni en debug en producción, ni “temporalmente”.

Políticas de acceso y segmentación de red

VPN no es bala de plata. Cifra tráfico, pero no soluciona por sí sola autorización ni segmentación. Error dar todo el centro de datos al escritório entero. Segmenta, usa ACL, grupos y principio de menor privilegio. La tendencia: zero trust — autentica, autoriza, da solo lo necesario, registra acceso y duración.

En implementaciones reales ayuda mucho un mapa sencillo: quién debe acceder a dónde. Con eso, handshakes, cifrados y protocolos relevantes son rutina técnica. Añade automatización: MDM para clientes, GitOps para servidores, plantillas y tests unificados. Así no solo cifras, también gestionas acceso, que es la meta de cualquier VPN corporativa.

Preguntas frecuentes (FAQ)

Fundamentos

¿Por qué una VPN usa cifrado asimétrico y simétrico a la vez?

La asimetría asegura un intercambio seguro de secretos entre partes sin clave común previa. Realiza el handshake, autentica y genera una clave de sesión. Luego entra la simetría para cifrar el tráfico principal rápida y eficientemente. Así logramos el dúo perfecto: seguridad en el handshake y alta velocidad en datos. Este es el enfoque estándar en IPsec, OpenVPN y WireGuard. La perfect forward secrecy añade protección extra: la compromisión de claves largas no revela sesiones anteriores. Elegante, simple y probado durante décadas.

¿Qué es PFS y por qué es tan mencionado?

PFS (Perfect Forward Secrecy) es una propiedad que garantiza que la compromisión de la clave a largo plazo no permite descifrar tráfico antiguo. Se logra mediante claves efímeras en el handshake (ECDHE). En IPsec implica grupos DH con PFS en Child SA, en OpenVPN/TLS 1.3 es por defecto, en WireGuard es X25519 con rekey frecuente. Si algún día roban la clave privada, el tráfico interceptado antes seguirá siendo inútil para el atacante. Por eso tanta atención a configurar bien handshake y claves.

Práctica

¿Qué elegir en 2026: AES-GCM o ChaCha20-Poly1305?

Si usas servidores con AES-NI o extensiones ARMv8 Crypto, opta por AES-GCM (128 o 256) y olvídate de complicarte. Donde no hay aceleración hardware, sobre todo en móviles, ChaCha20-Poly1305 suele ser más rápido y eficiente en batería. WireGuard usa ChaCha por defecto, explicación de su agilidad en smartphones. En OpenVPN puedes especificar data-ciphers y permitir ambos, dejando que el cliente elija según su hardware. Prueba, medir es tu mejor aliado.

¿Qué parámetros poner para rekey?

Valores típicos: 30–120 minutos y 1–4 GB en Child SA de IPsec; en OpenVPN, reneg-sec alrededor de una hora y límite por bytes; en WireGuard, rekey automático cada dos minutos inactivo o por contadores. Pero esto es general. Considera RTT, pérdidas y tipo de tráfico. Demasiado rekey sube la sobrecarga y latencia; poco debilita PFS y riesgo de desbordes. Encuentra balance en entorno de pruebas.

Seguridad

¿Ya conviene migrar a algoritmos post-cuánticos en VPN?

Completamente, normalmente es pronto. Los handshakes híbridos (X25519+Kyber) son un compromiso inteligente para pilotos y segmentos críticos. Mantienen compatibilidad clásica y añaden resistencia futura a ataques cuánticos. Ten en cuenta aumento de tamaño de mensajes y efecto en MTU. Haz pruebas piloto, mide latencia real, revisa DPI y balanceadores. Migración masiva solo cuando clientes e infraestructura estén listos y estándares auditados.

¿Cuál es la longitud de clave “correcta” hoy?

En asimétrico: RSA-2048 aún válido, pero mejor RSA-3072 o ECDSA/Ed25519. Para intercambio: X25519 es estándar de facto. En simétrico: AES-GCM-128 o -256; sin aceleración hardware, ChaCha20-Poly1305. Más largo no siempre es mejor; AES-128-GCM puede ser más práctico y rápido, y la verdadera fortaleza viene de PFS, rekey regular y RNG de calidad. Recuerda: seguridad es un sistema, no solo bits.