The crypto library behind Python now ships quantum-resistant algorithms

On 30 June 2026 Trail of Bits announced that it has added the post-quantum algorithms ML-KEM and ML-DSA to pyca/cryptography, the library that performs cryptographic operations across much of the Python world. The work was funded by the Sovereign Tech Agency. ML-KEM corresponds to the NIST standard FIPS 203 for key encapsulation, and ML-DSA to FIPS 204 for digital signatures. According to Trail of Bits the library is the eleventh most downloaded package on PyPI, with 1.2 billion downloads in the past month.

What happens technically

The sources disagree about which version matters, and the difference is worth knowing. The blog post points to version 48. The project's own changelog places the modules in 47.0.0, released on 24 April 2026, but at that point only with AWS-LC and BoringSSL as the cryptographic backend. It was 48.0.0, released on 4 May 2026, that made the primitives available to ordinary users by shipping OpenSSL 3.5.0 as a backend. The practical answer is therefore that you need 48 or later unless you build the library against a different backend yourself. Under the hood these are Rust bindings over an underlying C backend, not a new cryptographic implementation written in Python. Calls the backend does not support fail explicitly rather than falling back quietly on something older. The documentation describes the parameter sets ML-KEM-768 and ML-KEM-1024 for key encapsulation, and ML-DSA-44, ML-DSA-65 and ML-DSA-87 for signatures. The third NIST standard, SLH-DSA, is not supported, and no source states when it arrives.

Trail of Bits stresses that this is not a straight swap of one algorithm for another. ML-KEM is not a Diffie-Hellman exchange, and therefore cannot be dropped in where such an exchange sits today without changing the protocol. The volume of data that has to travel on the wire also grows considerably compared with today's keys and signatures, while the performance cost of the computation itself is described as imperceptible in ordinary use. The consequence is that systems with fixed field lengths for today's keys and signatures have to change the format, not merely the algorithm. Trail of Bits ties the urgency to a United States presidential action, Executive Order 14412 of 22 June 2026, which sets deadlines for federal systems and justifies them on the basis that data is collected now to be decrypted later. The company is equally clear that users do not get this in practice until the protocols adopt it, and that the library is merely the link that had to be in place first.

What this means for you if you keep secrets with a long life

It is easy to dismiss post-quantum cryptography as something that becomes urgent in ten years. The argument that makes this wrong sits in the executive order itself: data collected today can be decrypted later. If you hold information that must still be secret in 2035, the thing to assess is not security in 2035 but whether somebody can store your traffic today. Our assessment is nevertheless that the most valuable short term gain is a different one. A system that has changed cryptographic algorithm once has demonstrated that it can do so again. That capability is what is worth having, regardless of when a quantum machine may arrive.

So check where Python actually sits in your systems, because this library sits beneath more than people assume. The sources name Ansible, Certbot, Apache Airflow and paramiko as projects where it is this library doing the cryptographic work. Upgrading it does not change your algorithm, but without the upgrade you cannot change at all. If you have your own protocols or file formats with fixed field lengths for today's keys, that is where the work lies, and it is bigger than a package update. If your organisation is covered by NIS2, cryptography belongs in the assessment of your measures, and one question you should be able to answer is how long the data you protect today actually has to stay protected.

Berigo recommends

• Work out which of your data must still be secret in ten years. That list decides how urgent this is.
• Map where pyca/cryptography sits underneath your own systems, and which version is in use. You need 48 or later for the primitives to be available.
• Look for your own protocols and file formats with fixed field lengths for keys and signatures. That is where a transition costs most.
• Plan for keys and signatures growing larger on the wire, and check that message limits and buffer sizes tolerate it.
• Treat this as an exercise in changing cryptographic algorithm, and write down what it takes. Next time the pressure may be greater.