Nexus-Q: motor open source de cifrado post-cuántico

¿Qué es Nexus-Q y qué problema resuelve?

NEXUS-Q es, según sus propios benchmarks, entre 2 y 4,5 veces más lento que AWS-LC, liboqs y CIRCL en las operaciones de ML-KEM y ML-DSA. Y lo publica sin maquillar. Ese detalle dice más sobre su propuesta que cualquier promesa de rendimiento: es un motor de criptografía post-cuántica de código abierto, escrito en Rust, que apuesta por la corrección y el borrado seguro de secretos antes que por la velocidad.

Su primer rasgo distintivo es arquitectónico: es una biblioteca antes que un producto. El núcleo es un crate de Rust que concentra toda la criptografía, y encima se apoyan una interfaz de línea de comandos, un servidor HTTP con endpoints de salud y métricas, y SDKs para C, Python, Go, PHP y Ruby. Ninguna de esas capas implementa criptografía propia.

El caso de uso es concreto: aplicaciones y servidores que necesitan proteger secretos durante años, no durante una sesión. Para eso cubre tres frentes. Cifrado autenticado de archivos y flujos con cifrado de sobre (formato F-02), de modo que el contenido queda protegido bajo una clave que a su vez está protegida. Ciclo de vida completo de claves —generación, rotación, revocación y destrucción— dentro de una bóveda cifrada (formato F-01) con escrituras atómicas. E identidades: firmas digitales, verificación, rotación y revocación, más credenciales verificables firmadas.

El proyecto publicó su v1.0.0 el 7 de octubre de 2026, congeló la v2.0.0 el 8 de octubre y liberó la V3 el 9 de octubre de 2026 vía el PR #45, ya integrada en la rama principal. La V4 está planificada, no publicada: núcleos optimizados para AVX2 y NEON que solo pasarían a ser predeterminados después de tests diferenciales, vectores de prueba, fuzzing y una revisión de tiempo constante.

¿Qué algoritmos post-cuánticos usa?

Seis familias y nada más. Esa es la regla del propio repositorio: cualquier primitiva fuera de esas familias —RSA sin envoltorio o MACs caseros, por ejemplo— está prohibida por diseño.

• Intercambio de claves: ML-KEM-768 y ML-KEM-1024, en modo híbrido con X25519.
• Firmas: Ed25519, ML-DSA-65 y SLH-DSA-SHAKE-128f.
• Cifrado simétrico: AES-256-GCM y ChaCha20-Poly1305.
• Derivación de claves: Argon2id para contraseñas y HKDF para material de clave.
• Hashing: SHA-2 y SHA-3.
• Aleatoriedad: CSPRNG del sistema operativo, con soporte de TRNG y chequeos de salud.

La elección del híbrido ML-KEM + X25519 tiene una lógica defensiva explícita: el intercambio queda protegido mientras al menos uno de los dos esquemas resista. Es el criterio habitual mientras los algoritmos post-cuánticos siguen madurando en despliegue.

Sobre el proceso, el proyecto es inusualmente explícito: "no inventamos criptografía". Cada primitiva es un algoritmo estandarizado implementado por una biblioteca mantenida, y cualquier desviación exige un registro de decisión de arquitectura por escrito. Los algoritmos planificados no se describen como disponibles hasta estar implementados y probados.

¿Qué tan rápido es Nexus-Q frente a AWS-LC y liboqs?

Más lento. Y lo dice el propio proyecto, que se define abiertamente como no líder de rendimiento. Los números salen del Arena del repositorio, ejecutado sobre una misma carga de trabajo en CI con Linux x86_64 (20 iteraciones, 3 de calentamiento):

• ML-KEM-768 keygen: 33,94 µs frente a 11,44 µs de AWS-LC — 2,97 veces más lento.
• ML-KEM-768 encaps: 27,97 µs frente a 12,11 µs — 2,31 veces más lento.
• ML-KEM-768 decaps: 34,62 µs frente a 15,07 µs — 2,30 veces más lento.
• ML-KEM-1024 keygen: 53,89 µs frente a 22,60 µs de liboqs — 2,38 veces más lento.
• ML-KEM-1024 encaps: 46,05 µs frente a 22,71 µs — 2,03 veces más lento.
• ML-DSA-65 keygen: 168,69 µs frente a 44,21 µs de AWS-LC — 3,82 veces más lento.
• ML-DSA-65 sign: 600,73 µs frente a 134,75 µs — 4,46 veces más lento.
• ML-DSA-65 verify: 101,20 µs frente a 22,92 µs de CIRCL — 4,42 veces más lento.

Dos advertencias que el repositorio pone en negrita: los resultados dependen de CPU, planificador, compilador y runner, y las cifras provienen de un único runner de CI alojado. Son observaciones, no afirmaciones universales. La decisión de la V3 fue mantener el borrado de secretos y el endurecimiento de seguridad y aceptar el costo, en lugar de debilitar la limpieza de memoria para ganar latencia. La v2.0.0, de hecho, no registra ninguna mejora de rendimiento sobre la v1.0.0.

¿Por qué la criptografía post-cuántica dejó de ser un tema de 2035?

Porque los plazos regulatorios ya están escritos. El 22 de junio de 2026 la Casa Blanca firmó la Orden Ejecutiva 14409, que fija que las agencias civiles federales migren sus activos de alto valor para establecimiento de claves a criptografía post-cuántica antes de que termine 2030, y sus sistemas de firma digital antes del cierre de 2031. Los contratistas federales cubiertos quedan sujetos al mismo estándar, y NIST debe completar un proyecto piloto antes del 31 de diciembre de 2027 (Tech Times).

El calendario se apoya en estándares que ya existen: NIST finalizó ML-KEM (FIPS 203) y ML-DSA (FIPS 204) en agosto de 2024. Y la presión no viene solo de Washington. Google fijó internamente un plazo de migración para 2029 —un año antes que el federal—, con Android 17 ya integrando protección de firmas ML-DSA, y Microsoft apunta a una transición completa en 2033 (Tech Times).

En Europa el movimiento es paralelo. La hoja de ruta coordinada de la UE llama a comenzar la transición antes de que termine 2026 y a que la infraestructura crítica avance hacia PQC en 2030, mientras el NCSC británico fijó hitos en 2028, 2031 y 2035 (Forbes). El Español reportó que Rodrigo Martín, responsable técnico de criptografía post-cuántica en Indra, fue elegido presidente del comité técnico de seguimiento de Open Quantum Safe, y que gobiernos y grandes tecnológicas ya adelantaron sus planes oficiales de migración a 2029.

La razón de la urgencia es la doctrina "capturar ahora, descifrar después": un adversario puede almacenar hoy tráfico cifrado y descifrarlo cuando disponga de cómputo cuántico. Una vez capturado el dato, no se puede des-capturar. El Mundo reportó que Apple fue pionera en 2024 con iMessage y que Telefónica anunció servicios quantum-safe para proteger comunicaciones entre centros de datos y sedes corporativas.

Hay además un detalle operativo que suele subestimarse. Microsoft lanzó el 27 de agosto de 2026 su programa piloto de TLS post-cuántico con ML-DSA-87 y siete raíces piloto operadas por ComSign, DigiCert, HARICA, IdenTrust, Sectigo, Shanghai Electronic Certification Authority y SSL.com. La autenticación, advierte la compañía, es un problema distinto al de la confidencialidad: los certificados post-cuánticos son más grandes y obligan a revisar PKI, HSM y dispositivos embebidos (Microsoft Security Blog).

¿Qué NO afirma el proyecto (y por qué eso importa)?

Esta es la parte más interesante para quien evalúa dependencias criptográficas. NEXUS-Q publica una lista explícita de lo que no reclama: no tiene auditoría externa independiente, no tiene validación FIPS ni Common Criteria, no tiene verificación formal, no se declara listo para producción, no está publicado en crates.io ni PyPI, y su backend de software por defecto no ofrece aislamiento por hardware.

Tampoco promete liderazgo de rendimiento, y aclara que un release en GitHub no implica auditoría, certificación ni disponibilidad en un registro de paquetes. La licencia es dual, MIT o Apache-2.0, la misma que usa buena parte del ecosistema Rust.

En un sector donde el marketing suele adelantar la realidad, publicar los límites antes que las capacidades es una señal de madurez de ingeniería. También es un recordatorio útil: una librería cripto open source con buenos gates de CI sigue sin ser una librería cripto auditada.

¿Qué significa esto para tu startup?

Haz el inventario criptográfico antes de elegir herramienta. El primer paso que recomienda el sector es mapear cada sistema, protocolo y certificado que depende de RSA o de criptografía de curva elíptica. Tech Times cita estimaciones de la industria que sitúan el costo de migración entre 50.000 y más de 250.000 dólares para organizaciones medianas, y bastante más para empresas con infraestructura criptográfica distribuida. El inventario es lo que convierte esa cifra en un plan y no en una sorpresa.

Trata la criptoagilidad como requisito de compra. Utimaco e InfoSec Global cerraron una alianza precisamente para eso: descubrir e inventariar activos criptográficos y habilitar la agilidad de algoritmos (Interempresas). Si vas a firmar con un proveedor de identidad, pagos o infraestructura, pregunta cómo cambia de algoritmo sin reescribir código.

Prueba el modo híbrido en tus flujos más sensibles. NEXUS-Q combina ML-KEM con X25519 por una razón que aplica a cualquier stack: si uno de los dos esquemas falla, el canal sigue protegido. Correr clásico y post-cuántico en paralelo donde el dato es crítico es la ruta de menor riesgo.

Si vas a construir sobre NEXUS-Q, hazlo desde el código fuente y con expectativas realistas. Necesitas Rust 1.85 o superior (edición 2024) y Git; los objetivos soportados son Linux x86_64 y aarch64, Android/Termux aarch64 y RISC-V (riscv64gc) con build verificado. El proyecto pide ayuda concreta: reproducir el Arena en tu propio hardware, revisar el modelo de amenazas y reportar qué falta. Si encuentras una vulnerabilidad, el canal es GitHub Security Advisories, no un issue público.

Conclusión

NEXUS-Q no es el proyecto que gana una comparativa de microsegundos, y no pretende serlo. Es un motor que ordena la criptografía post-cuántica alrededor de cuatro decisiones defendibles: una biblioteca primero y capas delgadas encima, algoritmos estandarizados sin invenciones propias, política de denegación por defecto con registro de auditoría a prueba de manipulación, y una declaración pública de lo que no está auditado. Con plazos regulatorios ya activos en Estados Unidos y Europa, y con el riesgo de "capturar ahora, descifrar después" operando hoy, ese tipo de proyecto vale la pena mirarlo de cerca aunque todavía no lo pongas en producción.

Fuentes

• https://nexus-q.link (fuente original)
• Repositorio oficial de NEXUS-Q
• Tech Times: Post-Quantum Encryption Mandate
• Forbes: AI Agents Are Pulling The Post-Quantum Deadline Forward
• Microsoft Security Blog: Post-quantum authentication
• El Mundo: La computación cuántica impulsa la mayor transición de la criptografía
• Interempresas: Utimaco e InfoSec Global se asocian para facilitar la criptografía post-cuántica
• El Español: Rodrigo Martín lidera el organismo mundial de criptografía postcuántica