¿Qué tan grandes son las llaves y firmas post-cuánticas y qué rompen en la práctica?

Al 7 de noviembre de 2026, las firmas y llaves públicas dentro de un handshake TLS típico pesan 1.248 bytes con la mezcla RSA/ECDSA de hoy — y pesarían 14.724 bytes si cada una pasara a ML-DSA-44, unas 12 veces más (Luke Valenta, Cloudflare, PKI Consortium PQC Conference, 15 de enero de 2025). Esa cuenta en bytes — no la matemática de retículos — es lo que tensiona presupuestos fijos como el techo UDP de ≈1.232 bytes de DNSSEC (borrador IETF, 16 de octubre de 2026) y las imágenes de firmware de kilobytes (NSA CNSA 2.0: firma de firmware solo post-cuántica para sistemas de seguridad nacional de EE. UU. al 2030). El registro público sigue mostrando 0 llaves RSA-2048 rotas por un computador cuántico y 0 brechas atribuidas a un ataque cuántico — ambos re-verificados hoy. Rosetta Quantum publica la aritmética de bytes con fuente al lado de cada número, para que un equipo de seguridad presupueste la migración en vez de temerle.

¿Qué tan grandes son las llaves y firmas post-cuánticas, de verdad?

Entre unas 2 y más de 120 veces sus contrapartes clásicas, según el esquema — y la dispersión es la historia. Según los estándares finalizados el 13 de agosto de 2024 y la tabla de tamaños que Cloudflare presentó en la conferencia del PKI Consortium (15 de enero de 2025): una firma Ed25519 mide 64 bytes y una RSA-2048 mide 256; una firma ML-DSA-44 (FIPS 204) mide 2.420 bytes con llave pública de 1.312 — unas 38 veces Ed25519; una firma SLH-DSA-128s (FIPS 205) mide 7.856 bytes — unas 123 veces — y la variante rápida 128f llega a 17.088; Falcon-512 es la excepción compacta con 666 bytes por firma y 897 por llave pública, pero su estándar, FIPS 206, no tenía borrador publicado a nuestro escaneo del 1 de noviembre de 2026. Del lado del intercambio de llaves, el híbrido ML-KEM-768 (FIPS 203) mueve unos 1.100 bytes por extremo donde X25519 movía 32 — «un aumento de más de 30 veces», en palabras del propio Google (blog de seguridad de Chrome, 23 de mayo de 2024).

Qué son ML-KEM, ML-DSA y SLH-DSA, y cuál corre ya tu navegador, está en su propia pieza de esta serie. Esta pieza es sobre la pregunta siguiente: un tamaño aislado no significa nada — solo significa algo contra el presupuesto de bytes del protocolo que tiene que cargarlo. Tres presupuestos dominan en la práctica: el handshake TLS, la respuesta DNSSEC y la imagen de firmware. Los totales, con fuente por fila:

¿Cuántas firmas viajan en un handshake TLS y qué cuestan?

Seis firmas y dos llaves públicas, en el conteo de Cloudflare para una carga de página típica (8 de noviembre de 2021): dos en la cadena de certificados, una firma de handshake, un OCSP staple y dos SCTs — el conteo de Google en 2024 es cinco y dos (blog de Chrome, 23 de mayo de 2024). Si todas pasan a ML-DSA-44, la carga criptográfica de un handshake va de 1.248 a 14.724 bytes; una mezcla Falcon-512 + ML-DSA-44 queda en 7.293 bytes (Valenta, 15 de enero de 2025). En más de la mitad de las conexiones, las firmas y llaves clásicas ya representan cerca del 25% de todos los bytes transferidos (misma charla).

El costo de esos bytes extra no es una conjetura — se midió. El experimento de Cloudflare de 2021 inyectó bytes de relleno en 964.499 conexiones TLS reales durante 24 días (blog, 8 de noviembre de 2021): con ≈+17 KB — el escenario todo-Dilithium2 de la época — el handshake mediano corrió un ≈20% más lento, con la cola peor; la curva mostró saltos cerca de 10 KB y 30 KB que los autores leyeron como clientes o middleboxes que no toleran esos tamaños; con +35 KB la mediana fue 40% más lenta. Y la única migración post-cuántica que SÍ se desplegó a escala confirma la sensibilidad desde el otro lado: el ML-KEM híbrido agrega ≈1 KB por extremo y costó un +4% medido en la latencia mediana del handshake en Chrome de escritorio — impacto que Google juzgó aceptable ahí pero que demoró el despliegue en Android (23 de mayo de 2024). Ese incremento de ≈1 KB ya cubre cerca del 70% del tráfico humano de navegadores en la red de Cloudflare (Cloudflare, 29 de septiembre de 2026; medido en esta serie).

La asimetría explica la brecha de despliegue. Los principios de diseño de Chromium, citados en la charla de enero de 2025, llaman implausible agregar ≈7 KB al handshake «salvo que un computador cuántico criptográficamente relevante sea tangiblemente inminente»; Google recomienda formalmente NO estandarizar ML-DSA para la Web PKI pública antes de que exista agilidad de anclas de confianza (23 de mayo de 2024). Consistente con eso, nuestro escaneo del 1 de noviembre de 2026 encontró 0 certificados post-cuánticos en la Web PKI de producción — el intercambio de llaves migró primero precisamente porque era 1 KB, no 14. La mecánica y los costos en bytes de ese handshake híbrido tendrán su propia pieza en esta serie.

¿Por qué DNSSEC es el presupuesto de bytes más apretado de internet?

Porque una respuesta DNS debe caber en ≈1.232 bytes de payload UDP — el techo práctico que la comunidad DNS adoptó alrededor de 2020 — y ninguna firma de retículos estandarizada hoy cabe con comodidad. El estudio de la Universidad de Waterloo que midió esto de punta a punta (Goertzen y Stebila, arXiv:2211.14196, 25 de noviembre de 2022) contó los bytes totales de una resolución DNSSEC completa: 504 bytes con ECDSA P-256 y 1.081 con RSA-2048, contra 3.112 con Falcon-512, 8.623 con Dilithium2 (el precursor de ML-DSA) y 26.073 con SPHINCS+-128s. Las respuestas que no caben se truncan y reintentan por TCP, que el paper considera frágil a escala del DNS — anota que un número no trivial de name servers ni siquiera soporta TCP — y hasta el mejor caso post-cuántico corrió cerca de 2 veces más lento que RSA o ECDSA en sus condiciones simuladas. Su veredicto: Falcon-512 es «la opción más adecuada disponible hoy» para DNSSEC.

Cuatro años después, el marcador de estandarización sigue en cero: ningún algoritmo post-cuántico tiene code point de algoritmo DNSSEC. El documento de estrategia vigente — un Internet-Draft del IETF firmado por Verisign Labs, Virginia Tech y NLnet Labs, fechado 16 de octubre de 2026 — esboza dos vías futuras: una conservadora (ML-DSA envuelto en modo Merkle Tree Ladder, Falcon, o los esquemas de hash XMSS/LMS) y una de reemplazo directo de bajo impacto construida sobre esquemas aún en evaluación en el onramp del NIST, como MAYO y SNOVA. Todo eso está escrito en futuro, y así lo escribiremos: esos registros podrán llegar, las mediciones tendrán que llegar primero, y lo que pasó con SIKE y Rainbow es el recordatorio de por qué nadie quiere cablear un esquema joven en la raíz del DNS.

¿Por qué la firma de firmware es el primer plazo duro?

Porque la NSA la convirtió en la fecha de «uso exclusivo» más temprana de CNSA 2.0 — firma de software y firmware solo post-cuántica para sistemas de seguridad nacional de EE. UU. al 2030, con soporte preferido desde 2025 — antes que los equipos de red y años antes que las fechas 2033 de navegadores y sistemas operativos (NSA, CNSA 2.0 y su FAQ; el detalle v2.1 leído en el análisis de PostQuantum.com, consultado el 7 de noviembre de 2026 — el PDF primario está en las fuentes). Las herramientas aprobadas son los esquemas de hash con estado LMS y XMSS en forma de árbol único, estandarizados en NIST SP 800-208 (octubre de 2020), con ML-DSA admitido cuando existan implementaciones validadas; SLH-DSA está explícitamente NO aprobado para sistemas de seguridad nacional en la lectura v2.1, y las variantes multi-árbol quedan excluidas.

La lógica vuelve a ser presupuestaria, con las restricciones más duras de todas. Un verificador en ROM de arranque tiene kilobytes de espacio de código, no se parcha, y debe verificar cada arranque durante la vida del dispositivo — 10 a 20 años en vehículos, controladores industriales y satélites. Las firmas que viven tanto enfrentan la imagen espejo de la aritmética harvest-now-decrypt-later cubierta antes en esta serie: no es el dato el que sobrevive a la transición, es el verificador grabado en silicio. Las firmas de hash calzan en ese nicho porque su seguridad descansa solo en funciones de hash — pero tienen estado: firmar dos veces con la misma llave de un solo uso colapsa la seguridad, y por eso su precio operativo es la gestión de llaves, no los bytes. Qué firma de verdad la cadena de suministro de software tendrá su propia pieza en esta serie.

¿Qué hace un CISO con estos números?

Primero, partir la «migración post-cuántica» en dos proyectos con física distinta. El intercambio de llaves es la mitad barata: +1 KB por extremo, +4% medido en la mediana del handshake, ya vivo en cerca del 70% del tráfico de navegadores vía Cloudflare (29 de septiembre de 2026). Las firmas son la mitad cara: 0 certificados post-cuánticos en la Web PKI, DNSSEC con 0 code points, y una cuenta de 12 veces en bytes esperando al primero que avance. Presupuestos, dueños y cronogramas no deberían compartirse entre las dos mitades.

Segundo, inventariar por dónde fluyen las firmas antes de comprar nada. Un inventario criptográfico (CBOM) que liste cada cadena TLS, zona DNSSEC, pipeline de firma de código e imagen de firmware — y marque cada ruta que cruce un techo fijo de bytes — convierte la tabla de este artículo en tu mapa de migración.

Tercero, comprar agilidad, no algoritmos. El ganador por nicho sigue genuinamente abierto: Falcon espera FIPS 206, las vías DNSSEC son borradores, y la lista CNSA ya cambió entre versiones del FAQ. El caso de la agilidad criptográfica por sobre la elección de algoritmo es este artículo en una frase.

Cuarto, ponerle fechas al trabajo. Los relojes que obligan son regulatorios, no cuánticos: el NIST depreca RSA/ECC en 2030 y los prohíbe en 2035 (IR 8547, final del 27 de octubre de 2026); la orden ejecutiva de EE. UU. fija 2030/2031 para activos federales de alto valor; CNSA 2.0 fija 2030 para firmware. La posición propia de Rosetta sobre el Q-Day (RQ-PRED-QDAY-001: piso 2031, ventana 2033–2039) es un juicio sellado y refutable — no una medición — y cae después de todos esos plazos. Los ceros de arriba son reales y son buena noticia; los plazos también son reales, y llegan primero.

Tablero PQC — estado al 2026-11-07

Qué no sabemos

Dónde terminan los números de este artículo: (1) Ninguna cadena de certificados toda-post-cuántica se ha medido en producción a escala de internet — la curva de lentitud viene de un experimento controlado de 2021 con bytes de relleno, y ningún navegador valida certificados post-cuánticos por defecto hoy. (2) Los umbrales de ruptura cerca de 10 KB y 30 KB se midieron en 2021 y, hasta donde sabemos, no se han re-medido públicamente; la tasa de falla de middleboxes de hoy es desconocida. (3) Qué algoritmo registrará DNSSEC sigue abierto — existen 0 code points, FIPS 206 no tenía borrador a nuestro escaneo del 1 de noviembre, y las vías MTL/MAYO/SNOVA son experimentales. (4) Los presupuestos reales de verificación en firmware (bytes de ROM, RAM, tiempo de arranque) no se publican por fabricante; el encuadre en kilobytes sale de las restricciones que citan los propios estándares. (5) El detalle del FAQ v2.1 de CNSA 2.0 lo leímos vía un análisis secundario; cualquier discrepancia se resuelve a favor del documento primario de la NSA, enlazado abajo. (6) Si propuestas como Merkle Tree Certificates o la negociación de anclas de confianza madurarán a tiempo para evitar la cadena ingenua de 14,7 KB — la posición de Google contra estandarizar ML-DSA temprano para la Web PKI es del 23 de mayo de 2024 y podrá cambiar.

Rosetta Quantum publica veredictos con datos crudos reproducibles y fuentes fechadas. Esto es contenido educativo — no un claim de producto, ni asesoría de compra o de inversión.