Túneles locales seguros cuánticamente: Preparando tu pila de desarrollo para la criptografía post-cuántica

La computación cuántica es un elemento en la hoja de ruta para los equipos de seguridad y organismos de estándares. NIST ha propuesto una fecha para retirar los algoritmos de clave pública actuales, y las principales CDN y sistemas operativos ya negocian el intercambio de claves post-cuántico por defecto. Una parte de la pila recibe poca atención en esta migración: el túnel de desarrollo local.

Los desarrolladores usan túneles para exponer localhost a proveedores de webhooks, dispositivos móviles de prueba y clientes que revisan una versión de staging. Un túnel es una tubería protegida por TLS, por lo que hereda la misma exposición criptográfica que cualquier otra conexión TLS. También suele transportar material que no querrías leer más tarde, como claves API, tokens de sesión y cargas útiles copiadas de sistemas reales.

Esta guía cubre qué rompería una computadora cuántica en un túnel y qué no. También explica qué dicen los estándares hoy y cómo funciona el intercambio de claves híbrido en TLS 1.3. Luego analiza qué herramientas de túnel ya soportan intercambio de claves post-cuántico y cuál es el costo de rendimiento medido.

---

1. Qué está realmente en riesgo en un túnel

La anatomía de una conexión de túnel

Un túnel tiene dos patas:

1. Pata pública: un navegador, una app móvil o un remitente de webhook se conecta vía TLS al borde público del proveedor del túnel.
2. Pata del agente: un demonio cliente en tu portátil mantiene una conexión saliente de larga duración con el mismo borde, y las solicitudes se multiplexan por ella.

Cada pata está protegida por su propio apretón de manos criptográfico. En TLS 1.3, las claves de sesión provienen de un intercambio de claves (EC)DHE efímero, generalmente X25519. El certificado del servidor se verifica con una firma como RSA o ECDSA. Un túnel que protege solo una de estas patas deja la otra clásica. Cualquier pata puede ser la débil.

Por qué importa el algoritmo de Shor aquí

El algoritmo de Shor, ejecutado en una computadora cuántica con suficiente tolerancia a fallos, rompe RSA, Diffie-Hellman en campo finito y criptografía de curva elíptica incluyendo X25519 y ECDSA. Los cifrados simétricos como AES-256 y ChaCha20 no son el punto débil, así que la parte de cifrado bulk de un túnel no necesita ser reemplazada.

Ninguna máquina capaz de esto existe hoy. Sin embargo, las estimaciones de lo que se necesitaría han bajado. En 2019, Craig Gidney y Martin Ekerå estimaron que factorizar RSA-2048 requeriría unos 20 millones de qubits ruidosos. En mayo de 2025, Gidney publicó una estimación revisada de menos de un millón de qubits ruidosos y menos de una semana de tiempo de ejecución. Estas son estimaciones de recursos para una máquina que nadie ha construido, pero explican por qué los horizontes de planificación se acortaron.

Store-now-decrypt-later (SNDL)

SNDL significa grabar el tráfico cifrado ahora y descifrarlo cuando exista una computadora cuántica capaz. La guía de migración gubernamental, incluyendo el borrador de transición de NIST, considera esto como una razón para mover primero el intercambio de claves. No hay casos documentados de alguien archivando específicamente el tráfico de túneles de desarrollador. El argumento es sobre riesgo: si una sesión capturada está protegida solo por un intercambio de claves clásico, queda expuesta en cuanto llegue una computadora cuántica, independientemente de cuándo fue grabada.

Esto aplica principalmente a intercambio de claves. Las firmas y certificados no son un objetivo SNDL, porque falsificar una firma solo ayuda a un atacante que pueda hacerlo mientras la conexión está activa. Por eso, el intercambio de claves se ha migrado antes que la autenticación en toda la industria.

Si esto importa para tu túnel, depende de qué pasa por él y cuánto tiempo debe mantenerse confidencial. Cargas útiles de webhook con credenciales en vivo, datos de clientes copiados en un entorno de prueba y código fuente no publicado son ejemplos que aún podrían ser sensibles en una década.

---

2. Estándares: en qué estado están en octubre de 2026

El 13 de agosto de 2024, NIST publicó sus primeros tres estándares post-cuánticos:

Estándar	Algoritmo	Origen	Propósito
FIPS 203	ML-KEM	CRYSTALS-Kyber	Encapsulación de claves (intercambio de claves)
FIPS 204	ML-DSA	CRYSTALS-Dilithium	Firmas digitales
FIPS 205	SLH-DSA	SPHINCS+	Firmas digitales basadas en hash

Otros dos elementos están en progreso. FN-DSA, basado en Falcon, está especificado en FIPS 206, que aún es borrador, y se espera su finalización hacia finales de 2026 o principios de 2027. En marzo de 2025, NIST también seleccionó HQC, un KEM basado en códigos, como respaldo junto a ML-KEM.

La seguridad de ML-KEM se basa en la dificultad del problema Module Learning With Errors sobre reticulados estructurados. Es el algoritmo que TLS, SSH y VPN han adoptado para el intercambio de claves.

La línea de tiempo de migración

El informe preliminar IR 8547 de NIST (publicado el 12 de noviembre de 2024) propone descontinuar algoritmos de clave pública vulnerables a cuántico con 112 bits de seguridad, como RSA-2048 y ECC P-256, después de 2030, y prohibir su uso después de 2035. Es solo una propuesta, pero la política federal y el lenguaje de adquisiciones ya consideran esas fechas. La suite CNSA 2.0 de la NSA para sistemas de seguridad nacional establece hitos más tempranos y nombra ML-KEM-1024 y ML-DSA-87 como los algoritmos.

---

3. Por qué el intercambio de claves híbrido es el enfoque común

Un intercambio de claves híbrido realiza un intercambio clásico (X25519) y uno post-cuántico (ML-KEM-768) en el mismo apretón de manos y deriva la clave de sesión de ambos. Un atacante debe romper ambos para recuperar la clave. Esto cubre dos modos de fallo: un fallo en el código o matemáticas post-cuánticas más nuevas, y una ruptura cuántica futura de la curva clásica.

Los gobiernos no están de acuerdo en si el híbrido es necesario:

• El BSI de Alemania y el ANSSI de Francia requieren o prefieren fuertemente combinaciones híbridas con algoritmos clásicos.
• La NSA afirma que no requiere despliegues híbridos para sistemas de seguridad nacional. Aceptará híbridos para interoperabilidad y busca algoritmos CNSA 2.0 puros para las fechas indicadas.
• NIST ha estado redactando guías sobre cómo combinar esquemas de establecimiento de claves (SP 800-227) en lugar de exigir híbridos.

Por lo tanto, el híbrido es la práctica dominante en internet público, especialmente en TLS, pero no es una obligación universal.

Cómo funciona en TLS 1.3

El grupo híbrido más usado es X25519MLKEM768. Está definido en un borrador de IETF, draft-ietf-tls-ecdhe-mlkem, que aún es un borrador (revisión 05, mayo de 2026). El borrador también define SecP256r1MLKEM768 y SecP384r1MLKEM1024. En el intercambio:

1. La clave compartida del cliente es la clave de encapsulación ML-KEM-768 seguida de su clave pública efímera X25519.
2. La clave compartida del servidor es el cifrado ML-KEM seguido de su clave pública efímera X25519.
3. Ambos lados calculan el secreto compartido ML-KEM y el secreto compartido X25519, los concatenan y alimentan el resultado en la rutina de claves de TLS 1.3 como entrada (EC)DHE.

Debido a que la rutina de claves no cambia, el resto del apretón de manos y el cifrado de registros simétricos funcionan igual.

Tamaños

Intercambio de claves	Clave del cliente	Clave del servidor
X25519	32 bytes	32 bytes
ML-KEM-768 (clave de encapsulación / cifrado)	1,184 bytes	1,088 bytes
X25519MLKEM768 (híbrido)	1,216 bytes	1,120 bytes

En comparación con X25519 simple, el híbrido añade 2,272 bytes (aproximadamente 2.2 KiB) en las dos claves compartidas.

---

4. Qué significa esto para las herramientas de túneles

El soporte post-cuántico varía mucho entre herramientas, así que revisa cada una en lugar de asumir.

Túneles SSH reversos. OpenSSH 10.0, lanzado el 9 de abril de 2025, hizo que el acuerdo de claves híbrido mlkem768x25519-sha256 fuera el predeterminado para el cliente. Si usas ssh -R para exponer un puerto local a través de un servidor con una versión reciente de OpenSSH, la negociación ya es híbrida post-cuántica por defecto. La versión 10.1 añadió una advertencia si la conexión no usa un intercambio de claves post-cuántico.

Túnel Cloudflare. Cloudflare introdujo un modo post-cuántico para cloudflared en octubre de 2022, usando los borradores Kyber híbridos que precedieron al estándar final. Cuando está habilitado, cloudflared no vuelve a un modo no post-cuántico. Al inicio, Cloudflare señaló que la conexión de control y la autenticación del túnel aún no eran post-cuánticas. También reportaron que más del 60% del tráfico de clientes en su red usaba cifrado post-cuántico en febrero de 2026, frente a menos del 3% a principios de 2024. Para el comportamiento exacto de tu versión del túnel, revisa la documentación de Cloudflare.

Herramientas basadas en WireGuard. La documentación de Tailscale indica que su implementación de WireGuard no es segura post-cuántica. También explica que WireGuard evita deliberadamente la agilidad en el protocolo, por lo que ML-KEM no puede simplemente intercambiarse. Si una herramienta está basada en WireGuard, consulta al proveedor sobre su plan.

Herramientas que construyes o ejecutas en Go. Go 1.24 (febrero de 2025) habilitó X25519MLKEM768 por defecto en crypto/tls cuando Config.CurvePreferences es nil. Un cliente o borde de túnel basado en Go con Go 1.24 o superior negocia automáticamente el grupo híbrido sin cambios en el código. Kubernetes v1.33, construido con Go 1.24, adoptó esto automáticamente. Puedes desactivarlo con GODEBUG=tlsmlkem=0, útil si un middlebox o servidor con errores maneja mal el handshake más grande.

Otros proveedores. No encontré documentación pública que confirme el intercambio de claves post-cuántico en varios servicios populares de túneles. Si usas uno, consulta al proveedor si la pata pública y la del agente negocian un grupo híbrido y qué pasa en caso de fallback.

Un punto arquitectónico a verificar

Si un proveedor termina TLS en su borde, la pata pública y la del agente son sesiones TLS separadas. La protección post-cuántica en una no protege a la otra, así que necesitas ambas. Incluso con ambas protegidas, el borde del proveedor ve texto plano. Para datos realmente sensibles, la encriptación de extremo a extremo dentro del túnel importa más que la elección del intercambio de claves en cualquiera de las patas.

---

5. Configuración de TLS híbrido en Go

Para Go 1.24 y posteriores, el preferido ya es el grupo híbrido. Si quieres expresar la preferencia explícitamente, para documentación o para fijarlo, haz esto:

package main

import (
	"crypto/tls"
	"log"
	"net/http"
)

func newServer() *http.Server {
	cfg := &tls.Config{
		MinVersion: tls.VersionTLS13,
		// Prefiere el híbrido post-cuántico; mantiene X25519 simple para que los clientes
		// que no soportan ML-KEM puedan aún conectarse.
		CurvePreferences: []tls.CurveID{
			tls.X25519MLKEM768,
			tls.X25519,
		},
	}
	return &http.Server{
		Addr:      ":443",
		TLSConfig: cfg,
	}
}

func main() {
	srv := newServer()
	log.Fatal(srv.ListenAndServeTLS("cert.pem", "key.pem"))
}

Dos detalles a tener en cuenta:

• Los conjuntos de cifrado TLS 1.3 no son configurables en crypto/tls de Go, así que no es necesario listar CipherSuites para un servidor solo TLS 1.3. El grupo de intercambio de claves es lo que determina la protección post-cuántica.
• Mantener tls.X25519 como fallback significa que clientes antiguos aún se conectan, pero también permite una caída a intercambio clásico. Si controlas ambos extremos, como en tu propio cliente y borde de túnel, puedes eliminar el fallback y hacer obligatorio el híbrido. Esa fue la estrategia de Cloudflare con su bandera --post-quantum.

El grupo híbrido solo aplica a TLS 1.3. Un cliente que negocie TLS 1.2 obtiene un apretón de manos puramente clásico, por eso importa que MinVersion: tls.VersionTLS13.

---

6. Rendimiento: qué muestran las mediciones

El costo del intercambio de claves híbrido proviene casi totalmente de los bytes extras en el apretón de manos, no del cálculo. Los números a continuación provienen de implementaciones a gran escala, no de una prueba específica de túnel, así que tómalo como indicativo.

• Latencia del apretón de manos. Ingenieros de Chrome reportaron en una lista de correo de IETF que agregar Kyber al apretón de manos TLS aumentó la latencia en unos 4% en escritorio y 9% en Android en la mediana, y mucho más en el percentil 95. Las mediciones de Cloudflare encontraron que cada KB adicional en la respuesta del servidor aumentaba la latencia media del apretón en unos 1.5%. Estos son aumentos porcentuales solo en el apretón, no en el tiempo total de carga o solicitud.
• Compatibilidad con middleboxes y servidores. El tamaño mayor del ClientHello puede activar bugs en servidores y middleboxes mal escritos. Cloudflare encontró que alrededor del 0.34% de los orígenes que escaneó no completaron un apretón cuando se envió primero una clave de post-cuántico. La documentación de Go indica tlsmlkem=0 como solución para servidores con errores en el manejo de registros grandes.
• Costo de reintento. Si un cliente adivina mal qué grupo soporta un servidor, TLS 1.3 necesita una ronda adicional (HelloRetryRequest). Cloudflare reportó reducir estos reintentos en orígenes escaneados del 52% a 3.7%, eliminando más de 150 ms en la latencia de p90.
• Después del apretón. Los datos en bloque se protegen con el mismo cifrado simétrico que antes (AES-GCM o ChaCha20-Poly1305), así que el rendimiento por byte no cambia. El análisis de AWS sobre TLS híbrido señala que el costo extra se paga una vez por conexión y se amortiza en la sesión, y el pooling de conexiones reduce aún más su impacto.

Para túneles, esto es favorable. La pata del agente suele ser una conexión multiplexada de larga duración, así que se paga el costo del apretón una sola vez. Para la pata pública, el costo recae en cada conexión nueva, pero los remitentes de webhooks y navegadores que reutilizan conexiones lo pagan menos a menudo. No tengo mediciones específicas en milisegundos para vistas previas de túneles, y debes desconfiar de artículos que citen uno sin describir la configuración de prueba. Si esto te importa, mide tu propio túnel con el grupo híbrido activado y desactivado.

---

7. Pasos prácticos para tu pila

1. Inventario de tus túneles. Lista todas las herramientas que usas para exponer servicios locales (SSH, un proveedor comercial, un agente propio) y revisa la documentación de cada una para soporte de ML-KEM o X25519MLKEM768 en ambas patas.
2. Prefiere herramientas que por defecto usen el híbrido. OpenSSH 10.0 o superior y Go 1.24 o superior ya lo hacen. Actualiza clientes y servidores en lugar de configurar esto manualmente.
3. Verifica, no asumas. Inspecciona un apretón real desde el lado del cliente con OpenSSL o una captura de paquetes y confirma que el grupo negociado sea híbrido. Considera como hallazgo una caída silenciosa a X25519.
4. Requiere TLS 1.3 en ambos extremos. Los apretones TLS 1.2 siempre son clásicos.
5. No confíes solo en cifrado en tránsito para secretos. Mantén credenciales de producción fuera de entornos locales, usa tokens de corta duración y evita enviar datos reales de clientes por túnel. Esto limita el daño de cualquier tráfico grabado, sea cual sea el algoritmo que lo protegió.
6. Planifica la autenticación por separado. Los certificados y firmas post-cuánticos son una migración más difícil y aún no están ampliamente desplegados en la web pública. Los certificados de corta duración son buena higiene, pero no abordan store-now-decrypt-later, que apunta al intercambio de claves.
7. Mantente ágil en criptografía. FN-DSA y HQC aún están en proceso de estandarización, y el híbrido TLS sigue siendo un borrador de Internet. Elige herramientas que puedan cambiar algoritmos mediante configuración o actualización, sin necesidad de reconstruir.

---

Conclusión

El panorama práctico para túneles locales es mejor de lo que sugieren los titulares. El intercambio de claves post-cuántico ya está estandarizado, se distribuye por defecto en software ampliamente usado como OpenSSH 10 y Go 1.24, y su costo en el apretón es moderado. El trabajo restante es principalmente verificación y selección de herramientas. Verifica si ambas patas de tu túnel negocian un grupo híbrido, mantén secretos fuera del tráfico del túnel y considera la autenticación post-cuántica como el siguiente paso, no el primero.

---

Referencias

• NIST FIPS 203, 204, 205 (finalizados el 13 de agosto de 2024) y estado de FIPS 206 y HQC: Encryption Consulting – Decoding NIST PQC Standards; NIST PQC overview slides
• NIST IR 8547 línea de tiempo (desuso en 2030, prohibición en 2035, propuesta): Encryption Consulting – NIST IR 8547 Explained
• Borrador de intercambio de claves híbrido TLS: draft-ietf-tls-ecdhe-mlkem
• Tamaños de ML-KEM-768: facil.io ML-KEM-768 reference
• Posiciones de políticas híbridas (NSA, BSI, ANSSI): PostQuantum.com – Global PQC Requirements; PQShield – CNSA 2.0 update
• Go 1.24 predetermina híbrido: Go GODEBUG documentation; Kubernetes blog – PQC en Kubernetes
• Notas de lanzamiento de OpenSSH 10.0: openssh.com
• Modo post-cuántico en Cloudflare Tunnel: Introducing post-quantum Cloudflare Tunnel
• Datos de adopción de Cloudflare: Bringing more transparency to post-quantum usage
• Tailscale y WireGuard: Tailscale post-quantum cryptography documentation
• Datos de latencia en apretón: IETF TLS list – Chrome y mediciones de Cloudflare; AWS Security Blog – Rendimiento de TLS híbrido post-cuántico; InfoQ – Preferencias TLS en Cloudflare
• Estimación de recursos RSA-2048: Gidney, “How to factor 2048 bit RSA integers with less than a million noisy qubits”