Shipping post-quantum cryptography to Python

What Happened

A widely used Python cryptography library has been updated to include new encryption methods designed to resist attacks from future quantum computers. This matters because a recent White House order requires U.S. government systems to switch to these quantum-resistant methods by 2030-2031, and attackers may already be storing encrypted data now to decrypt it later when quantum computers become available. The new methods produce much larger keys and signatures than current ones, meaning software developers will need to update their protocols and data formats, not just swap algorithms. Organizations that depend on Python software for security — including tools for server automation, certificate management, and SSH connections — should begin planning their migration to post-quantum cryptography and evaluating whether their systems can accommodate the larger data sizes involved.

Key Takeaways

• pyca/cryptography version 48 now ships Rust bindings for ML-KEM (FIPS 203) and ML-DSA (FIPS 204), making post-quantum primitives available to the entire Python ecosystem via pip install.
• A White House order dated June 22, 2026 mandates federal systems adopt post-quantum key establishment by December 31, 2030 and post-quantum digital signatures by December 31, 2031.
• Post-quantum primitives have significantly larger data sizes than classical equivalents — ML-DSA-65 signatures are ~3.3 KB vs 64 B for Ed25519, and ML-KEM-768 public keys are ~1.2 KB vs 32 B for X25519 — requiring protocol and wire format updates beyond a simple algorithm swap.
• SLH-DSA (FIPS 205), a hash-based signature standard serving as a conservative backstop, is not yet supported but development has started.
• pyca/cryptography is the 11th most-downloaded PyPI package with 1.2 billion monthly downloads, underpinning Ansible, Certbot, Apache Airflow, paramiko, and many other projects.

Affected Systems

• Python applications using pyca/cryptography (version >=48 for PQ support)
• Protocols and wire formats that hardcode classical key/signature sizes (Ed25519, X25519, RSA, ECDSA)
• Federal systems subject to the White House post-quantum migration order

Attack Chain

N/A — This article describes a defensive cryptographic library enhancement, not an attack chain. It covers the addition of ML-KEM and ML-DSA post-quantum primitives to pyca/cryptography version 48, the size and performance tradeoffs of these algorithms compared to classical equivalents, and the remaining work to integrate them into real-world protocols.

Detection Availability

• YARA Rules: No
• Sigma Rules: No
• Snort/Suricata Rules: No
• KQL Queries: No
• Splunk SPL Queries: No
• EQL Queries: No
• Other Detection Logic: No

No detection rules are provided. This article is about cryptographic library development, not threat detection.

Detection Engineering Assessment

EDR Visibility: None — This article does not describe attacker behavior or endpoint indicators; it covers a cryptographic library update. Network Visibility: None — No network-based detection indicators are discussed. Future protocol-level integration of PQ algorithms may produce observable changes in TLS handshake sizes, but this is not yet implemented. Detection Difficulty: N/A — Not applicable — this is a defensive capability announcement, not a threat detection scenario.

Hunting Hypotheses

Control Gaps

• Protocols and wire formats with hardcoded classical key/signature sizes will not accommodate post-quantum primitives without modification.
• Applications using pyca/cryptography versions prior to 48 lack access to NIST-standardized post-quantum primitives.

Key Behavioral Indicators

• Python applications importing cryptography.hazmat.primitives.asymmetric.mldsa or cryptography.hazmat.primitives.asymmetric.mlkem indicate post-quantum primitive usage.
• TLS handshakes or SSH negotiations with significantly larger key exchange or signature payloads may indicate post-quantum algorithm negotiation once protocol integration is complete.

False Positive Assessment

• N/A — This article does not describe detection logic or indicators of compromise.

Recommendations

Immediate Mitigation

• Verify against your organization's incident response runbook and team escalation paths before acting. No immediate mitigation is required — this is an informational announcement about a cryptographic library enhancement.
• Consider inventorying Python applications that depend on pyca/cryptography to establish a baseline for future post-quantum migration planning.

Infrastructure Hardening

• Evaluate whether your organization's protocols, wire formats, and data schemas can accommodate the larger key, signature, and ciphertext sizes of ML-KEM-768 and ML-DSA-65.
• Consider upgrading Python environments to cryptography>=48 where appropriate to gain access to post-quantum primitives for testing and integration work.
• If your organization is subject to U.S. federal requirements, consider aligning migration plans with the December 31, 2030 (key establishment) and December 31, 2031 (digital signatures) deadlines.

User Protection

• No direct user protection actions are indicated at this time; post-quantum algorithm support in end-user-facing protocols is still in progress.

Security Awareness

• Consider briefing development teams on the size and performance tradeoffs of post-quantum primitives so they can plan protocol and data format changes proactively.
• If applicable, consider raising awareness of the 'harvest now, decrypt later' threat model where attackers may store encrypted data for future decryption with quantum computers.