The term on this page
- PQCpost-quantum cryptography
- algorithms that run on ordinary computers and are believed to resist quantum attack
Also mentioned
ML-KEMML-KEMModule-Lattice-based Key Encapsulation MechanismModule-Lattice-Based Key-Encapsulation Mechanism, the NIST-standardized post-quantum KEM derived from CRYSTALS-Kyber and specified in FIPS 203.Read the full entry (new tab), ML-DSAML-DSAModule-Lattice-based Digital Signature AlgorithmModule-Lattice-Based Digital Signature Algorithm, the NIST-standardized post-quantum signature scheme derived from CRYSTALS-Dilithium and specified in FIPS 204.Read the full entry (new tab), TLSTLSTransport Layer SecurityTransport Layer Security, the protocol that encrypts and authenticates most internet traffic, including HTTPS. It uses key exchange, certificates, and symmetric encryption to protect a session.Read the full entry (new tab), FIPSFIPSFederal Information Processing StandardFederal Information Processing Standards, publicly announced standards developed by NIST for use in U.S. government computer systems, including cryptographic algorithms and modules.Read the full entry (new tab) are defined in the glossary.
Read this first
OpenSSL published 4.1.0-beta1 on 23 September 2026 with architecture-specific acceleration for ML-KEM and ML-DSA across ppc64le, s390x and x86-64. The changes target number-theoretic transforms and SHAKE sampling, two expensive parts of the standardized algorithms. The release is a beta, and its upstream benchmarks are hardware-specific, so this is a signal to benchmark representative systems rather than a production upgrade recommendation.
OpenSSL's 4.1.0-beta1 release makes post-quantum performance a processor question. The release notes list optimized ML-KEM and ML-DSA number-theoretic transform operations on ppc64le, optimized ML-DSA operations on s390x and x86-64, and a four-way AVX-512 SHAKE path for ML-DSA on x86-64.
That is a different milestone from simply exposing the algorithms. OpenSSL 3.5 brought standardized ML-KEM and ML-DSA into the library. OpenSSL 4.1 beta starts tailoring the arithmetic to specific server CPU families, while retaining portable implementations for systems that do not meet the runtime capability checks.
Four optimization paths, three CPU families
| Platform | Algorithm | Optimized work | Upstream evidence |
|---|---|---|---|
| ppc64le | ML-KEM | Forward and inverse NTT | PR 30709 reports about 1.9x over the portable C path on its test system |
| ppc64le | ML-DSA | NTT, inverse NTT, polynomial multiply, add and subtract | Merged commit 96b16b9 reports about 3.6x overall on its test system |
| s390x | ML-DSA | 128-bit vector NTT and inverse NTT | Runtime dispatch uses IBM Z vector capability checks with a portable fallback |
| x86-64 | ML-DSA | AVX2 NTT plus AVX-512VL SHAKE x4 | Separate capability checks select the accelerated paths |
The NTT is the structured polynomial transform used by both lattice-based standards. It converts polynomial multiplication into operations that can be carried out efficiently in the transform domain. OpenSSL's new paths do not change ML-KEM or ML-DSA parameter sets. They change how the same required arithmetic is executed on processors that can do more work in parallel.
The SHAKE x4 change attacks another part of ML-DSA. Signing and verification use SHAKE-based sampling. OpenSSL PR 31090 adds a four-lane SHAKE implementation and dispatches to it when AVX-512VL is available. The pull request also added cross-validation tests against scalar SHAKE paths and an Intel SDE workflow for Linux and Windows.
The upstream numbers are useful, but not portable
The ppc64le ML-KEM change reports ML-KEM-768 encapsulation rising from 23,118.8 to 43,731.1 operations per second and decapsulation from 15,198.3 to 31,254.7 on its benchmark system. The associated commit was merged in April 2026 and is included in the 4.1 release notes.
For ML-DSA on ppc64le, the merged implementation reports much larger gains over the original C path. ML-DSA-65 signing increased from 679.6 to 2,500.2 operations per second in that test. On x86-64, the AVX2 NTT and AVX-512 SHAKE changes publish their own results on specific Xeon systems.
Do not turn one benchmark into an estate-wide ratio
These are upstream microbenchmarks on named systems, not a service-level forecast. The gain depends on processor generation, compiler and assembly support, OpenSSL build options, runtime dispatch, algorithm level, message mix and whether the application bottleneck is cryptography at all. Reproduce the workload on each representative CPU class before using a performance number in a capacity plan.
What migration teams can verify now
- Build the beta in an isolated performance environment and record the exact tag, compiler, Configure target and CPU capability output. A package labelled OpenSSL 4.1 is not enough evidence.
- Run
openssl speedfor the ML-KEM and ML-DSA levels the application will actually use, then repeat with representative message sizes and concurrency in the application. - Separate key generation, encapsulation, decapsulation, signing and verification. An optimization that helps one operation does not prove the same gain for the others.
- Include older nodes and virtual-machine types in the sample. Runtime dispatch should preserve correctness through the portable path, but their throughput may differ sharply from newer servers.
- Test the FIPS and non-FIPS configurations you deploy. Inclusion in the source tree does not by itself establish the validation status of a particular module, build or operating boundary.
The OpenSSL enablement guide now includes this beta boundary. Hybrid TLS rollout still starts with negotiated-group evidence, certificate paths and application compatibility. The new release adds a separate question: which CPU path is serving the standardized primitive, and is the performance claim reproducible on the machines that carry production traffic?
The beta changes implementation cost, not wire compatibility
Architecture-specific assembly and vector code are internal implementation choices. A peer does not negotiate AVX2, AVX-512, Power or IBM Z instructions. It negotiates algorithms and protocol parameters. That means a mixed fleet can keep the same wire-level ML-KEM or ML-DSA identifiers while different hosts use different local implementations.
This separation is operationally useful. Interoperability tests establish that the protocol and encodings still work across implementations. Performance tests establish whether the chosen hosts can carry the expected load. Combining the two into a single 'PQC supported' checkbox hides both failure modes.
It is still a prerelease
The OpenSSL project marks 4.1.0-beta1 as a prerelease. Its download page lists the beta with a 23 September 2026 release date, while the final 4.1 line remains future work. Teams can use the beta to establish a benchmark baseline, exercise runtime dispatch and identify architecture gaps. Production adoption should wait for the release and the organization's normal dependency, support and validation gates.
References
- OpenSSL 4.1.0-beta1 release, published 23 September 2026.
- OpenSSL 4.1 beta announcement, including the release scope and beta status.
- OpenSSL PR 30709, ppc64le ML-KEM NTT implementation and benchmark evidence.
- OpenSSL commit 96b16b9a, merged ppc64le ML-DSA implementation and benchmark evidence.
- OpenSSL PR 30812, s390x ML-DSA vector NTT and runtime fallback.
- OpenSSL PR 31090, x86-64 AVX-512VL SHAKE x4 integration and tests.