Quantum computing para el dev web que no estudió física: ¿cuándo preocuparse en serio?

Hay días que abrís Hacker News y encontrás un post que te hace sentir que sabés muy poco de algo que creías tener medianamente claro. Esta semana fue uno de esos días.

Un criptógrafo cuántico posteó un análisis técnico sobre el estado actual del quantum computing aplicado a criptografía. 289 puntos. 340 comentarios. Yo entendí quizás el 30% del hilo. Y eso que llevo más de una hora intentando seguirlo.

La pregunta que me quedó dando vueltas no es abstracta: ¿cuándo debería yo — un full-stack developer que deployea en Railway, piensa en milisegundos de response time y la semana pasada optimizó una app Next.js de 3 segundos a 300ms — empezar a preocuparme en términos prácticos?

No sé la respuesta. Pero eso es exactamente por qué vale la pena escribir este post.

El quantum computing es básicamente como tener un cerrajero que no intenta cada llave una por una, sino que de alguna manera prueba todas las llaves posibles al mismo tiempo. Y lo que hoy te lleva millones de años romper con fuerza bruta, con esa lógica podría llevar horas.

Una vez que lo ves así, entendés por qué los criptógrafos se ponen nerviosos.

El quantum computing timeline para desarrolladores web: el estado real en 2025

Primer aclaramiento importante: no estoy hablando de algo que pasa mañana. El quantum computing que existe hoy es ruidoso, inestable, y no escala bien. Las máquinas de IBM o Google tienen decenas o cientos de qubits "reales" pero con tasas de error que hacen que la mayoría de los algoritmos criptográficamente relevantes sean imposibles de correr.

Para romper RSA-2048 — el estándar que protege buena parte de HTTPS hoy — necesitarías aproximadamente 4000 qubits lógicos estables. Los qubits lógicos son distintos de los físicos; necesitás muchos físicos para hacer uno lógico confiable por culpa del error de corrección.

Hoy estamos, dependiendo de a quién le preguntés, entre 10 y 20 años lejos de tener máquinas con esa capacidad. Algunos dicen 15 años. Otros dicen que nunca llegamos. Otros dicen que ya hay actores estado-nación haciendo cosas que no vemos.

Ese rango de incertidumbre es exactamente el problema.

Lo que el post de HN me hizo entender

El hilo que mencioné giraba alrededor de algo que se llama "harvest now, decrypt later" (HNDL). La idea es: aunque hoy no podés romper el cifrado, podés interceptar tráfico cifrado ahora y guardarlo para cuando tengas la capacidad cuántica de descifrarlo en el futuro.

Eso cambia la ecuación dramáticamente. Si alguien está capturando tu tráfico HTTPS de 2025 para descifrarlo en 2035, el timeline "10 a 20 años" se convierte en ahora mismo.

¿Quiénes hacen eso? Principalmente actores estado-nación. ¿Le importa eso a mi API de Next.js que muestra recetas de cocina? Probablemente no. ¿Le importa a un sistema de salud, a comunicaciones de defensa, a transacciones financieras de largo plazo? Absolutamente sí.

Así que la primera respuesta práctica es: depende de qué estás construyendo.

Lo que como developer full-stack debería saber sobre post-quantum cryptography

Aquí está lo que aprendí intentando entender el hilo sin tener un PhD en física:

NIST ya tomó decisiones

En 2024, el NIST (National Institute of Standards and Technology) finalizó los primeros estándares de criptografía post-cuántica. Los algoritmos que pasaron son:

• ML-KEM (antes CRYSTALS-Kyber): para intercambio de claves
• ML-DSA (antes CRYSTALS-Dilithium): para firmas digitales
• SLH-DSA (antes SPHINCS+): para firmas digitales

Esto es importante porque significa que el trabajo de estandarización ya pasó. No estamos esperando que los matemáticos se pongan de acuerdo — ya lo hicieron.

TLS 1.3 ya está preparándose

Chrome, Firefox y algunos servidores ya están experimentando con hybrid key exchange — combinan el algoritmo clásico (X25519) con uno post-cuántico (ML-KEM) en el mismo handshake. Si uno falla, el otro sigue funcionando. Si el cuántico resulta tener vulnerabilidades no descubiertas todavía, el clásico te cubre.

Como dev web, probablemente esto te llegue transparentemente vía updates de OpenSSL, nginx, o Node.js. No tenés que hacer nada... todavía.

Lo que SÍ tenés que pensar activamente

// Esto es lo que MUCHOS proyectos hacen hoy
// y que puede ser problemático en un horizonte post-cuántico

// ❌ Algoritmos que eventualmente van a ser vulnerables
const jwt = sign(payload, secret, { algorithm: 'RS256' }) // RSA
const encrypted = crypto.publicEncrypt(rsaPublicKey, data) // RSA

// ✅ Algoritmos simétricos — estos están relativamente bien
// AES-256 sigue siendo seguro en un mundo cuántico
// (Grover's algorithm lo debilita pero no lo rompe — 256 bits -> 128 bits efectivos)
const hash = createHash('sha256').update(data).digest('hex') // OK por ahora
const cipher = createCipheriv('aes-256-gcm', key, iv) // Más seguro

// 🤔 La pregunta real: ¿tus secrets/tokens tienen que durar décadas?
// Si un JWT expira en 1 hora, el riesgo post-cuántico es casi nulo
// Si estás firmando contratos que tienen que ser válidos en 2040...
// ahí sí hay que pensar distinto

La clave práctica que saqué: el riesgo escala con el tiempo de vida de lo que firmás o cifrás. Un access token de 15 minutos y un certificado de firma de documentos legales tienen riesgos completamente distintos.

Los errores de framing más comunes cuando leés sobre quantum computing

Acá está lo que me parece que la mayoría de los posts de divulgación hacen mal — incluyendo probablemente este:

Error 1: Confundir "quantum advantage" con "quantum supremacy" con "cryptographically relevant"

Cuando Google o IBM anuncian un hito cuántico, los medios lo presentan como "ya pueden romper el cifrado". Casi nunca es eso. Quantum advantage significa que resolvieron algún problema específico más rápido que una computadora clásica. Ese problema específico suele ser artificioso y diseñado para que la computadora cuántica brille.

Cryptographically relevant quantum computing — el que realmente importa — es una barra mucho más alta.

Error 2: Pensar que bcrypt o Argon2 están muertos

El hashing de passwords como bcrypt, scrypt o Argon2 usa funciones hash simétricas. El algoritmo de Grover (el que aplica computación cuántica a búsqueda) efectivamente reduce su seguridad a la mitad — pero Argon2 con parámetros modernos tiene margen de sobra. No necesitás cambiar tu sistema de autenticación ahora mismo.

Error 3: Ignorarlo completamente porque "falta mucho"

Este es el error que me parece más peligroso para devs que construyen infraestructura de largo plazo. Si estás construyendo algo que va a manejar datos sensibles por décadas, el timeline importa.

Pensá en todo lo que construí durante el pivote a software development en 2020 — la infraestructura que elegís hoy puede seguir corriendo en producción en 2035. Cuando elegís un stack de autenticación o cifrado hoy, estás eligiendo para ese horizonte de tiempo también.

Error 4: Pensar que esto es solo un problema del devops o del sysadmin

En el ecosistema de 2025 que describí cuando armé mi stack para juanchi.dev, los developers full-stack tomamos decisiones de arquitectura que antes eran de ops. Eso incluye qué librería de crypto usás, cómo firmás tokens, qué tipo de certificados pedís.

No podés delegarlo completamente.

Código: qué revisar en tu proyecto hoy

// Auditoría rápida de superficie de ataque post-cuántica
// Revisá estos patrones en tu codebase

// 1. ALGORITMOS ASIMÉTRICOS — los más vulnerables
// Buscá: RSA, ECDH, ECDSA, DH
// ¿Dónde aparecen?
import { generateKeyPairSync, createSign } from 'crypto'

// ❓ RSA — vulnerable a Shor's algorithm
// Si estos datos tienen que ser válidos en 2035+, pensalo
const { privateKey, publicKey } = generateKeyPairSync('rsa', {
  modulusLength: 2048, // Esto eventualmente no va a ser suficiente
})

// ❓ ECDSA — también vulnerable, aunque más eficiente hoy
const ecKey = generateKeyPairSync('ec', {
  namedCurve: 'prime256v1',
})

// 2. ALGORITMOS SIMÉTRICOS — relativamente OK
// AES-256, ChaCha20-Poly1305, SHA-256/384/512
// Estos necesitan el doble de bits para ser vulnerables (Grover)
// pero con 256 bits tenés colchón de sobra

import { randomBytes, createCipheriv, createDecipheriv } from 'crypto'

const cifrarDatosLocales = (datos: Buffer, clave: Buffer): Buffer => {
  // AES-256-GCM — esto sigue siendo seguro post-quantum
  const iv = randomBytes(16)
  const cipher = createCipheriv('aes-256-gcm', clave, iv)
  
  const cifrado = Buffer.concat([
    iv,
    cipher.update(datos),
    cipher.final(),
    cipher.getAuthTag() // El tag de autenticación es importante
  ])
  
  return cifrado
}

// 3. JWT — el caso práctico más común
// La respuesta corta: si expira en horas, no te preocupés
// Si firmás algo permanente con JWT... cuestioná el diseño

const evaluarRiesgoJWT = (expiresInSeconds: number): string => {
  const años = expiresInSeconds / (365 * 24 * 3600)
  
  if (años < 1) return 'Riesgo post-cuántico prácticamente nulo'
  if (años < 5) return 'Riesgo bajo, monitoreá el timeline'
  if (años < 15) return 'Riesgo moderado, considerá migración'
  return 'Riesgo alto — rediseñá este componente'
}

console.log(evaluarRiesgoJWT(3600)) // "Riesgo post-cuántico prácticamente nulo"
console.log(evaluarRiesgoJWT(10 * 365 * 24 * 3600)) // "Riesgo moderado..."

La función evaluarRiesgoJWT es una simplificación obvia, pero captura el punto central: el tiempo de vida de lo que firmás es la variable más importante.

Cuando definís los patrones de TypeScript que usás en producción, incluir tipos explícitos para el contexto de seguridad — cuánto tiempo vive un token, qué nivel de sensibilidad tienen los datos — es el tipo de diseño que ayuda cuando tenés que hacer una auditoría de esto en el futuro.

Qué hacer concretamente hoy (sin entrar en pánico)

Esta es mi lista personal, honesta, sin exagerar el riesgo:

Ahora mismo (sin importar el tipo de proyecto):

• Usá TLS 1.3 — ya implementa algunas mejoras de seguridad y va a recibir actualizaciones post-cuánticas
• Preferí AES-256 sobre AES-128 para cifrado simétrico
• Mantenés las dependencias actualizadas — la migración post-cuántica va a llegar vía updates de librerías
• No implementés crypto propio — en serio, nunca, quantum o no quantum

En los próximos 1-2 años (si manejás datos sensibles de largo plazo):

• Inventariá qué en tu sistema usa criptografía asimétrica y cuánto tiempo tienen que vivir esos datos
• Empezá a leer sobre las librerías que van a adoptar los algoritmos NIST — Open Quantum Safe ya tiene implementaciones
• Considerá diseñar para "cripto-agilidad": que tu sistema pueda cambiar de algoritmo sin reescribir todo

Para el stack que elegiría en 2025: Hoy elegiría librerías activamente mantenidas por organizaciones que ya tienen planes de migración post-cuántica documentados. Node.js y OpenSSL están en ese camino. Es un criterio más para sumar a la evaluación.

FAQ: quantum computing y desarrollo web

¿HTTPS va a dejar de ser seguro por el quantum computing?

No en el corto plazo, y probablemente no de golpe. TLS ya está siendo actualizado con algoritmos post-cuánticos (hybrid key exchange en TLS 1.3). El browser que usás hoy ya está recibiendo estas actualizaciones gradualmente. Lo que sí es una amenaza real es el ataque "harvest now, decrypt later" para datos muy sensibles — pero eso aplica a actores estado-nación, no al tráfico web promedio.

¿Tengo que cambiar el sistema de login/passwords de mi app?

No urgentemente. bcrypt, Argon2, y scrypt usan funciones hash simétricas que son mucho más resistentes a quantum computing que los algoritmos asimétricos. Argon2id con parámetros modernos tiene margen de seguridad suficiente. La recomendación es seguir con las mejores prácticas actuales y mantenerte actualizado.

¿Los JWTs quedan obsoletos?

Depende de cómo los usés. Si firmás access tokens que expiran en 15 minutos o 1 hora, el riesgo es prácticamente nulo — para cuando exista quantum computing relevante, esos tokens llevan años vencidos. Si usás JWTs para firmar algo que tiene que ser válido por años (documentos, contratos), ahí sí hay que empezar a pensar en alternativas.

¿Qué es "post-quantum cryptography" y en qué se diferencia de "quantum cryptography"?

Post-quantum cryptography (PQC) son algoritmos clásicos — corren en computadoras normales — diseñados para ser resistentes a ataques de computadoras cuánticas. Quantum cryptography (QKD, quantum key distribution) usa principios cuánticos para la comunicación en sí. Como dev web, lo que te importa es PQC — es lo que vas a implementar en tu stack. QKD requiere hardware especializado y es un campo completamente distinto.

¿Cuándo debería empezar a usar las librerías post-cuánticas en producción?

Para la mayoría de las aplicaciones web: cuando lleguen via updates de tus dependencias actuales, que es probablemente lo que va a pasar. Node.js, OpenSSL y los providers de TLS van a implementar los estándares NIST gradualmente. Si manejás datos críticos de largo plazo, vale la pena explorar Open Quantum Safe hoy y empezar a hacer pruebas. Para el resto, mantenete actualizado y no entres en pánico.

¿El quantum computing afecta a blockchain y crypto también?

Sí, y bastante. Las criptomonedas usan ECDSA para firmar transacciones — vulnerable a Shor's algorithm. Bitcoin y Ethereum tendrían que migrar sus sistemas de firma antes de que quantum computing sea relevante. Es uno de los debates más activos en esas comunidades. Como dato de color: las wallets activas están más expuestas que las inactivas, porque las activas exponen la clave pública en cada transacción.

Conclusión: la ignorancia honesta como posición válida

Cuando empecé a escribir este post no sabía bien qué iba a concluir. Sigo sin saber si en 10 años estamos re-cifrando todo el internet o si el quantum computing sigue siendo una promesa que no termina de llegar.

Lo que sí saqué en limpio:

1. El timeline importa más que el tema. No es un problema binario de "hay que preocuparse" o "no hay que preocuparse". Es una función del tiempo de vida de tus datos y la sensibilidad de los mismos.

2. La industria ya se está moviendo. NIST finalizó estándares. TLS ya está experimentando con algoritmos híbridos. No vas a tener que hacer todo a mano — va a llegar via ecosistema.

3. La cripto-agilidad es la mejor inversión. Diseñar tus sistemas para que puedan cambiar de algoritmo sin reescritura total es buena práctica con o sin quantum computing. La historia de la criptografía es la historia de algoritmos que se rompen y se reemplazan.

4. Para la mayoría de los proyectos: mantenete actualizado y no entres en pánico. Si tu app maneja credenciales de usuarios que expiran, tokens de sesión normales, y datos que no tienen que ser válidos por décadas — el riesgo hoy es bajo. Aplicá las mejores prácticas actuales.

Lo que me queda pendiente es seguir leyendo. El hilo de HN que disparó esto tenía respuestas de gente con décadas de experiencia en criptografía que no se ponía de acuerdo. Eso me dice que la humildad epistémica es la postura correcta.

Si sos el tipo de developer que, como yo, viene de diagnosticar redes a las 11pm en un cyber o de tirar un servidor de producción con rm -rf en la primera semana de trabajo — sabés que la mejor preparación para los problemas grandes no es entrar en pánico cuando aparecen, sino construir sistemas que puedan adaptarse.

Eso aplica acá también.