Due to the risk of quantum computing attacks on classical cryptography, the world needs to switch to post-quantum cryptography. In August 2024, NIST standardized three post-quantum cryptography schemes: ML-KEM (FIPS 203), ML-DSA (FIPS 204) and SLH-DSA (FIPS 205). This was a great milestone, as we now have audited, standardized schemes that we can rely on. So, one year later, are these post-quantum schemes ready for use in production Rust applications?
We’ve been investigating that while building products at Project Eleven, and in this post we’re going to open-source our findings.
Choosing a package to use for cryptography is difficult, especially when the schemes are only recently standardized. We think the following criteria are useful when evaluating which package to choose.
Some packages only support a subset of the standardized schemes. The ideal package should provide all required schemes to ensure API consistency and maintain compatibility across dependencies.
NIST provides test vectors for each of the standardized schemes, e.g. the ML-KEM test vectors. If packages run tests against these vectors, it guarantees that their key generation and signature implementations comply at least with the standard test vectors.
When choosing a cryptography package to use, it's helpful if engineers can see a stamp of approval from professional auditors, e.g. cure53.
I've seen packages deployed in production despite clearly marked “DO NOT USE IN PRODUCTION”. While these packages could be secure, it’s bad practice to use a package in production that carries such a stark warning. And if it ever turns out to be vulnerable, what excuse will you give your customers?
We’ve reviewed the most popular Rust cryptography packages, as well as those designed specifically for post-quantum cryptography.
aws-lc-rs provides bindings to the AWS libcrypto package, which is written in C.
Support?
They currently support ML-KEM and ML-DSA, but not SLH-DSA. Their ML-DSA implementation is currently behind an unstable build flag.
Audited?
aws-lc-rs is currently pending FIPS review, and it hasn’t had any other independent audit yet for its post-quantum implementations. However, it is maintained by AWS, so it may have undergone a stricter internal review than typical open-source packages.
NIST Test Vectors?
It looks like aws-lc-rs only has NIST test vectors for ML-DSA, not ML-KEM. It seems that the underlying AWS libcrypto tests against NIST test vectors for ML-KEM also, though it’s less clear.
“Not for production” Warnings
aws-lc-rs is built to be used in production. Their ML-DSA implementation being gated behind an unstable flag seems to be the only relevant warning.
libcrux is a formally verified cryptographic library in Rust.
Support?
libcrux has packages for ML-KEM and ML-DSA, but not SLH-DSA.
Audited?
libcrux hasn’t received an independent audit for its post-quantum implementations, but the maintainers have performed formal verification on them using hax and F*.
NIST Test Vectors?
libcrux tests against the NIST vectors for both its ML-KEM and ML-DSA implementations.
“Not for production” Warnings
We didn’t spot any warnings against using these in production.
liboqs-rust provides Rust bindings to the Open Quantum Safe liboqs C library.
Support?
liboqs-rust has support for ML-KEM and ML-DSA, but not SLH-DSA. Their SPHINCS+ implementation is mostly the same as SLH-DSA, but they haven’t adapted it yet to match the full specification.
Audited?
liboqs-rust hasn’t undergone an independent audit. liboqs likely did get a lot of eyes from researchers during the NIST standardization process though.
NIST Test Vectors?
They test against the NIST test vectors for ML-KEM and ML-DSA.
“Not for production” Warnings
The liboqs README currently says WE DO NOT CURRENTLY RECOMMEND RELYING ON THIS LIBRARY IN A PRODUCTION ENVIRONMENT OR TO PROTECT ANY SENSITIVE DATA.
pqcrypto provides Rust bindings to the C project PQClean.
Support?
Like liboqs-rust, pqcrypto provides specification-compliant implementations of ML-KEM and SLH-DSA, but is still holding onto the ghost of SPHINCS+.
Audited?
pqcrypto hasn’t undergone an independent audit. The underlying package PQClean was likely read by lots of researchers during the NIST standardization process though.
NIST Test Vectors?
There do not appear to be any tests against NIST vectors, and this issue seems to confirm their absence.
“Not for production” Warnings
The underlying PQClean package states the following: PQClean offers reference and contributed implementations of cryptographic algorithms, primarily for academic and experimental purposes.
ring is one of the most popular cryptography packages in Rust and has been downloaded over 250 million times.
Support?
ring doesn’t support any of the post-quantum schemes. This issue appears to be the closest it has come to addressing integration of the post-quantum schemes.
rust-openssl provides Rust bindings to the C library OpenSSL, one of the most widely used cryptographic libraries in the world..
Support?
OpenSSL 3.5 was released earlier this year, which includes support for ML-DSA, ML-KEM, and SLH-DSA. There has been a pull request open on rust-openssl for a while to implement the appropriate bindings, but progress on it appears to have stalled.
Audited?
The post-quantum schemes in OpenSSL haven’t undergone an independent audit yet, but some modules that use OpenSSL are FIPS pending, which could include an audit of the post-quantum components.
NIST Test Vectors?
OpenSSL itself tests each of the schemes against the appropriate NIST test vectors.
“Not for production” Warnings
OpenSSL is built for production usage.
RustCrypto provides pure Rust implementations of cryptographic algorithms. Many of their packages have tens of millions of downloads.
Support?
RustCrypto has packages for ML-DSA, ML-KEM, and SLH-DSA.
Audited?
None of their post-quantum packages have undergone an independent audit.
NIST Test Vectors?
All of their packages are tested against the appropriate NIST test vectors.
“Not for production” Warnings
Each of the packages includes a warning in its README stating: the implementation contained in this crate has never been independently audited! USE AT YOUR OWN RISK!
rust-openssl and ring have each been downloaded hundreds of millions of times. These packages are likely used in many security-critical applications, yet neither has support for the post-quantum schemes – nor do they seem to be prioritizing them very much. This isn’t a criticism of the maintainers, many of whom are likely volunteers. To me, it’s another interesting example of complex systems relying on critical, underfunded nonprofit entities.
There’s no Rust post-quantum cryptography implementation you can point to and say, 'Great, cure53 has audited it.’ While formal verification and test vectors are valuable, engineers would still benefit from a stamp of approval by a professional cryptography auditing firm. Unfortunately, that kind of audit doesn't seem to exist yet for any of these implementation.
None of the packages check all the boxes. Software engineers will be looking for a go-to package. Right now, there's an opportunity for one to claim that top spot by closing the remaining gaps, and potentially end up running on every Rust engineer’s server.
It seems that RustCrypto could be best positioned to achieve that by securing funding for an independent audit. libcrux is also well positioned, and them taking the belt could be the best outcome for all of us, since they also prioritize formal verification. rust-openssl could also make a comeback, but then our CI builds would take 20 minutes 😭.
Post-quantum cryptography still has a way to go in Rust, but we’re getting there. Some packages are usable in production, but there's still a burden on engineers to understand the risks and evaluate whether their chosen package meets their requirements.
Here are a couple of actionable steps that could improve the situation:
- Fund an independent audit of one of the implementations.
- Contribute an implementation to one of the listed packages that doesn’t yet have one (SLH-DSA is calling you).
Unfortunately, doing one of these will cost you either time or money, but volunteering can be very fulfilling!
Let us know if we’ve missed anything. Next week, we’ll be posting a bonus for those looking to migrate their Rust servers to post-quantum TLS.