We benchmarked wolfSSL’s post-quantum algorithms against OpenSSL on a Toradex SMARC iMX95 Hexa 8GB module running Torizon OS 7.7.0. Both stacks ran on the same silicon, one Cortex-A55 core, governor pinned at 1800 MHz, one second per measurement. Torizon ships OpenSSL 3.5.7, which has native ML-KEM and ML-DSA, so this compares two builds you can actually get on the platform rather than a tuned build against a reference one.
wolfSSL runs 2.3x to 4.4x faster
| Algorithm | operation | OpenSSL 3.5.7 | wolfSSL 5.9.2 |
|---|---|---|---|
| ML-KEM-768 | key gen | 4,647 | 19,917 |
| ML-KEM-768 | encap | 5,963 | 17,112 |
| ML-KEM-768 | decap | 3,971 | 12,464 |
| ML-DSA-87 | sign | 157 | 689 |
| ML-DSA-87 | verify | 722 | 1,711 |
The gap comes from engineering investment in the platform rather than from the algorithms themselves. wolfSSL ships hand-written Arm64 NEON assembly for ML-KEM and ML-DSA, while OpenSSL’s Arm64 path for both is portable C.
Key establishment: ML-KEM against ECDHE P-256
ML-KEM-768 encapsulation runs at 17,112 ops/sec against 2,865 for an ECDHE P-256 agreement, a 6x speedup. Even ML-KEM-1024, the highest security level, is over 3x faster than P-256.
That carries through to the handshake. Holding the ECDSA P-256 server certificate constant and varying only the key-exchange group, TLS 1.3 with X25519MLKEM768 completes in 9.90 ms against 11.43 ms for classical SECP256R1, so the post-quantum hybrid is 13% faster, repeatable to better than 0.5%. That is the same codepoint Chrome and OpenSSL use, making it an interoperable configuration rather than a wolfSSL-only mode.
Signatures: ML-DSA against ECDSA and RSA
| Algorithm | key gen | sign / encap | verify / decap |
|---|---|---|---|
| ML-KEM-512 | 31,397 | 26,762 | 18,775 |
| ML-KEM-768 | 19,917 | 17,112 | 12,464 |
| ML-KEM-1024 | 11,695 | 10,522 | 8,173 |
| ML-DSA-44 | 5,221 | 1,324 | 4,440 |
| ML-DSA-65 | 2,959 | 865 | 2,811 |
| ML-DSA-87 | 1,857 | 689 | 1,711 |
| ECDSA P-256 | 6,710 | 2,667 | |
| ECDHE P-256 | 2,865 (agree) | ||
| RSA-2048 | 154 (private) | 6,094 (public) |
ML-DSA-44 verifies 1.7x faster than ECDSA P-256 (4,440 vs 2,667), and ML-DSA-87 verify is only about 1.6x slower than P-256. That is a comfortable place to be for any workload that verifies far more often than it signs, such as certificate chains, firmware validation, or V2X message authentication.
Signing is where you pay: ML-DSA-44 signs roughly 5x slower than ECDSA P-256. Against RSA-2048 the comparison flips, with ML-DSA-87 signing 4.5x faster (689 vs 154/sec). The real migration cost on this class of device is size rather than cycles, since ML-DSA-87 carries a 4,627-byte signature and 2,592-byte public key against 64 bytes each for ECDSA P-256.
Scaling and methodology
Six processes pinned across the A55 cluster scale essentially linearly, reaching 99,897 ML-KEM-768 encapsulations per second at 97% of 6x single-core, with ML-DSA-87 verify and ECDSA P-256 sign both at 100%. There is no shared bottleneck in wolfCrypt’s post-quantum paths.
These are pure software results with no cryptographic hardware acceleration. ML-KEM and ML-DSA are both bottlenecked on SHA-3 (Keccak), and the Armv8.2 SHA-3 instruction extension is optional in the architecture and is not present on this SoC, so wolfCrypt uses its NEON SHA-3 implementation throughout. Expect better figures on an Arm64 part that does provide those instructions, particularly for ML-DSA. Everything above also ran inside a container on Torizon OS, within about 1% of the native figures.
Try it
./configure --enable-armasm --enable-mlkem --enable-mldsa --enable-sp-asm make ./wolfcrypt/benchmark/benchmark -ml-kem -ml-dsa
Note that –enable-mldsa is off by default. wolfSSL is dual licensed under GPLv3 or a commercial license. Questions, or want help with an i.MX95, SMARC or Torizon integration? Contact facts@wolfssl.com or support@wolfssl.com.
If you have questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.
Download wolfSSL Now