{"slug": "shipping-post-quantum-cryptography-to-python", "title": "Shipping post-quantum cryptography to Python", "summary": "The pyca/cryptography package now supports post-quantum cryptography with ML-KEM and ML-DSA, making it pip-installable for the Python ecosystem. This follows a White House order mandating federal migration to post-quantum standards by 2030-2031, as quantum computers threaten current encryption. The update affects 1.2 billion monthly downloads and projects like Ansible and Let's Encrypt, though larger key sizes require protocol adjustments.", "body_md": "Post-quantum cryptography is now one `pip-install`\n\naway for the entire Python ecosystem. With funding from the [Sovereign Tech Agency](https://www.sovereign.tech/), we implemented support for ML-KEM, the NIST-standard key-establishment primitive, and ML-DSA, the NIST-standard digital-signature primitive, in `pyca/cryptography`\n\n.\n\nOn June 22, 2026, the White House [ordered](https://www.whitehouse.gov/presidential-actions/2026/06/securing-the-nation-against-advanced-cryptographic-attacks/) the U.S. government to accelerate its transition to post-quantum cryptography. The order says large-scale quantum computers, especially in adversarial hands, will threaten widely used cryptographic systems, and that attackers may already be collecting encrypted data now so they can decrypt it later. It also sets concrete migration deadlines: high-value and high-impact federal systems must use post-quantum key establishment by **December 31, 2030**, and post-quantum digital signatures by **December 31, 2031**. And even if you don’t care about quantum resistance, that’s not a problem because [quantum resistance isn’t the main benefit of post-quantum crypto.](https://blog.trailofbits.com/2024/07/01/quantum-is-unimportant-to-post-quantum/)\n\nThat transition cannot happen only at the policy layer. Every application that signs packages, validates certificates, establishes secure channels, or protects long-lived secrets depends on cryptographic libraries. If those libraries do not expose post-quantum algorithms, the software stack cannot migrate.\n\nAlmost every Python program that touches cryptography goes through `pyca/cryptography`\n\n. It’s currently the [eleventh most-downloaded package on PyPI](https://pypistats.org/top), pulling 1.2 billion downloads in the last month alone. The `pyca/cryptography`\n\npackage handles the cryptographic operations of projects like Ansible, Certbot (the Let’s Encrypt client), Apache Airflow, paramiko (the Python-only SSH client), and [many others](https://deps.dev/pypi/cryptography/48.0.0/dependents). If `pyca/cryptography`\n\ndoesn’t ship post-quantum primitives, the Python ecosystem can’t begin to migrate.\n\nAs of `cryptography>=48`\n\n, support for post quantum algorithms is just a `pip install`\n\naway. The version 48 release includes our Rust bindings for ML-KEM and ML-DSA, the cross binding API and tests, and support for AWS-LC as a cryptographic backend. It also includes work from pyca/cryptography’s maintainers to support the other cryptographic backends. Sadly, this is not enough for a post-quantum migration drop-in swap. These primitives have different size, performance, and integration tradeoffs than the classical algorithms they replace.\n\nPost-quantum primitives keep the same security strength, but they change the size of the data on the wire. Public keys, signatures, and ciphertexts are often 1–2 orders of magnitude larger than the classical values they replace. The operations are also more complex and therefore slower, but on modern hardware they are still imperceptible for regular use, and are likely to get faster with improved hardware and algorithms.\n\nFor **signatures**, here’s how the classical primitive (Ed25519) compares to its post-quantum equivalent (ML-DSA-65):\n\n| Algorithm | Public key | Private key | Output |\n|---|---|---|---|\n| Ed25519 | 32 B | 32 B | 64 B sig |\nML-DSA-65 |\n1,952 B |\n32 B |\n3,309 B sig |\n\nAnd for **key exchange and encryption**, here’s how X25519 compares to its post-quantum equivalent (ML-KEM-768):\n\n| Algorithm | Public key | Private key | Output |\n|---|---|---|---|\n| X25519 | 32 B | 32 B | 32 B shared |\nML-KEM-768 |\n1,184 B |\n64 B |\n1,088 B ciphertext |\n\nIf you maintain a protocol or wire format that hardcodes Ed25519-sized signatures or X25519-sized public keys, the post-quantum migration involves more than a primitive swap. The surrounding fields, length prefixes, and chunking assumptions need to grow with it.\n\nML-DSA is the lattice-based signature scheme that replaces RSA, ECDSA, and Ed25519. The Python API mirrors the existing asymmetric primitives:\n\nML-KEM is a key encapsulation mechanism (KEM) for establishing shared secrets. The construction is different, though. ML-KEM is a key encapsulation mechanism, not a Diffie-Hellman exchange. Instead of both parties combining key shares to derive a shared secret, one party encapsulates a fresh shared secret to the receiver’s public key, and the receiver decapsulates it with the matching private key. These operations allow both parties to exchange a secret but in a manner fundamentally different from Diffie-Hellman, and resistant to quantum factoring attacks.\n\nTwo areas are still in progress: a third NIST standard, and the work of integrating these primitives into real protocols.\n\nSLH-DSA ([FIPS 205](https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.205.pdf)) is NIST’s hash-based digital signature standard. Like ML-DSA, it is meant to replace classical signature schemes such as RSA, ECDSA, and Ed25519. Its tradeoff is different: SLH-DSA has very large signatures and slow signing, but it relies only on the security properties of hash functions, which have been studied for decades. That makes it a conservative backstop if future cryptanalysis weakens lattice-based signatures. SLH-DSA is not supported in `pyca/cryptography`\n\n48, but we’ve started working on it.\n\nPrimitives are the foundation, but the post-quantum migration will be complete only when protocols use the post-quantum resistant algorithms. You’re unlikely to use PQ algorithms directly in tools like Certbot or Ansible until common protocols add support for them. While well-designed to replace existing implementations, algorithm changes require cautious development, testing, and auditing. We are actively working on helping maintainers integrate PQ algorithms into applications.\n\nThis work was funded by the [Sovereign Tech Agency](https://www.sovereign.tech/), whose mission is to support the open-source infrastructure that public digital systems depend on.\n\nWe’re also indebted to pyca/cryptography’s maintainers, [Paul Kehrer](https://langui.sh/) and [Alex Gaynor](https://alexgaynor.net/), who offered constant feedback and review throughout the development process, and continue to steward this critical piece of open-source software.", "url": "https://wpnews.pro/news/shipping-post-quantum-cryptography-to-python", "canonical_source": "https://blog.trailofbits.com/2026/06/30/shipping-post-quantum-cryptography-to-python/", "published_at": "2026-06-30 11:00:00+00:00", "updated_at": "2026-06-30 11:22:44.343921+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-policy", "ai-safety"], "entities": ["Sovereign Tech Agency", "White House", "NIST", "pyca/cryptography", "Python", "Ansible", "Let's Encrypt", "AWS-LC"], "alternates": {"html": "https://wpnews.pro/news/shipping-post-quantum-cryptography-to-python", "markdown": "https://wpnews.pro/news/shipping-post-quantum-cryptography-to-python.md", "text": "https://wpnews.pro/news/shipping-post-quantum-cryptography-to-python.txt", "jsonld": "https://wpnews.pro/news/shipping-post-quantum-cryptography-to-python.jsonld"}}