Envío de criptografía post-cuántica a Python

Post-cuántica, la criptografía ahora está a un “pip-install” para todo el ecosistema de Python. Con financiación de la Agencia Tecnológica Soberana, hemos implementado el soporte para ML-KEM, el primitivo clave-establecimiento estándar de NIST, y ML-DSA, el primitivo de firma digital estándar de NIST, en pyca/cryptography. El 22 de junio de 2026, la Casa Blanca ordenó al gobierno de EE. UU. acelerar su transición a la criptografía post-cuántica. El orden dice que las computadoras cuánticas a gran escala, especialmente en manos adversas, amenazarán a los sistemas criptográficos ampliamente utilizados, y que los atacantes ya pueden estar recopilando datos encriptados para desencriptarlos más tarde. También establece plazos de migración concretos: los sistemas federales de alto valor e impacto deben utilizar la creación de claves post-cuántica para el 31 de diciembre de 2030, y las firmas digitales post-cuánticas para el 31 de diciembre de 2031. Incluso si no te preocupan la resistencia a la cuántica, eso no es un problema porque la resistencia a la cuántica no es el principal beneficio de la criptografía post-cuántica. Esa transición no puede ocurrir solo a nivel de política. Cada aplicación que firma paquetes, valida certificados, establece canales seguros, o protege secretos de larga duración depende de las bibliotecas criptográficas. Si esas bibliotecas no exponen algoritmos post-cuánticos, no se puede migrar el stack de software. Cerca de cada programa de Python que toca la criptografía pasa por pyca/cryptography. Actualmente es el paquete más descargado número 11 en PyPI, obteniendo 1.2 mil millones de descargas en el último mes solo. El paquete pyca/cryptography maneja las operaciones criptográficas de proyectos como Ansible, Certbot (el cliente de Let’s Encrypt), Apache Airflow, paramiko (el cliente SSH de Python), y muchos otros. Si pyca/cryptography no proporciona primitivas post-cuánticas, el ecosistema de Python no puede comenzar a migrar. El soporte post-cuántico ahora está a un “pip-install” de distancia. Hasta cryptography>=48, el soporte para algoritmos post cuánticos está a un “pip-install” de distancia. La versión 48 incluye nuestros enlaces de Rust para ML-KEM y ML-DSA, la API de enlace cruzado y pruebas, y soporte para AWS-LC como backend criptográfico. También incluye el trabajo de los mantenedores de pyca/cryptography para apoyar otros backends criptográficos. Lamentablemente, esto no es suficiente para una migración post-cuántica “drop-in”. Estas primitivas tienen diferentes compromisos de tamaño, rendimiento e integración en comparación con los algoritmos clásicos que reemplazan. Ajustes de algoritmos post-cuánticos Las primitivas post-cuánticas mantienen la misma fuerza de seguridad, pero cambian el tamaño de los datos en el bus. Las claves públicas, las firmas y los textos cifrados suelen ser 1–2 órdenes de magnitud más grandes que los valores clásicos que reemplazan. Las operaciones también son más complejas y, por lo tanto, más lentas, pero en el hardware moderno todavía son imperceptibles para el uso regular, y es probable que se vuelvan más rápidas con un hardware y algoritmos mejorados. Para las firmas, aquí hay una comparación de la primitiva clásica (Ed25519) con su equivalente post-cuántico (ML-DSA-65): Algoritmo Clave pública Clave privada Sal Ed25519 32 B 32 B 64 B sig ML-DSA-65 1,952 B 32 B 3,309 B sig Y para el intercambio de claves y el cifrado, aquí hay una comparación de X25519 con su equivalente post-cuántico (ML-KEM-768): Algoritmo Clave pública Clave privada Sal X25519 32 B 32 B 32 B compartido ML-KEM-768 1,184 B 64 B 1,088 B texto cifrado Si mantienes un protocolo o formato de bus que codifica firmas o claves públicas de tamaño Ed25519 o X25519, la migración post-cuántica implica más que un simple intercambio de primitivas. Los campos circundantes, los prefijos de longitud y las suposiciones de fragmentación deben crecer con él. Usando ML-DSA (FIPS 204): Firmas resistentes a la cuántica ML-DSA es el esquema de firma basado en retículos que reemplaza a RSA, ECDSA y Ed25519. La API de Python refleja las primitivas asimétricas existentes: from cryptography.hazmat.primitives.asymmetric import mldsa private_key = mldsa.MLDSA65PrivateKey.generate() public_key = private_key.public_key() signature = private_key.sign(bmessage) public_key.verify(signature, bmessage) # lanza InvalidSignature en caso de fallo. Usando ML-KEM (FIPS 203): Encapsulado de clave para la era post-cuántica ML-KEM es un mecanismo de encapsulamiento de clave (KEM) para establecer secretos compartidos. La construcción es diferente, aunque. ML-KEM es un mecanismo de encapsulamiento de clave, no un intercambio de Diffie-Hellman. En lugar de que ambas partes combinen las partes clave para derivar un secreto compartido, una parte encapsula un secreto compartido para la clave pública del receptor, y el receptor lo decapsula con la clave privada correspondiente. Estas operaciones permiten que ambas partes intercambien un secreto, pero de una manera fundamentalmente diferente a Diffie-Hellman, y resistentes a los ataques de factorización cuántica. from cryptography.hazmat.primitives.asymmetric import mlkem # El receptor genera una clave y publica la clave pública. private_key = mlkem.MLKEM768PrivateKey.generate() public_key = private_key.public_key() # El emisor encapsula un secreto compartido para esa clave pública. shared_secret_sender, ciphertext = public_key.encapsulate() # El receptor decapsula el mismo secreto compartido desde el texto cifrado. shared_secret_receiver = private_key.decapsulate(ciphertext) assert shared_secret_sender == shared_secret_receiver. El camino por delante: SLH-DSA e integración de protocolos. Todavía hay dos áreas que están en progreso: una tercera norma de NIST, y el trabajo de integrar estas primitivas en protocolos reales. SLH-DSA SLH-DSA (FIPS 205) es el estándar de firma digital basado en hash de NIST. Al igual que ML-DSA, está destinado a reemplazar los esquemas de firma clásicos como RSA, ECDSA y Ed25519. Su compromiso es diferente: SLH-DSA tiene firmas y firmas muy grandes y lentas, pero se basa únicamente en las propiedades de seguridad de las funciones hash, que se han estudiado durante décadas. Esto lo convierte en un respaldo conservador si la criptoanalítica futura debilita las firmas basadas en retículos. SLH-DSA aún no está soportado en pyca/cryptography 48, pero ya estamos trabajando en ello. Post-cuántica en protocolos. Las primitivas son la base, pero la migración post-cuántica estará completa solo cuando los protocolos utilicen los algoritmos resistentes a la cuántica. Es poco probable que uses los algoritmos PQ directamente en herramientas como Certbot o Ansible hasta que los protocolos comunes los soporten. Si bien están bien diseñados para reemplazar las implementaciones existentes, los cambios de algoritmos requieren un desarrollo, pruebas y auditoría cuidadosos. Estamos trabajando activamente en ayudar a los mantenedores a integrar algoritmos PQ en las aplicaciones. Reconocimientos Este trabajo fue financiado por la Agencia Tecnológica Soberana, cuya misión es apoyar la infraestructura de código abierto que dependen los sistemas digitales públicos. También estamos agradecidos a los mantenedores de pyca/cryptography, Paul Kehrer y Alex Gaynor, quienes ofrecieron comentarios y revisiones constantes durante todo el proceso de desarrollo, y que continúan administrando este software de código abierto crítico.