How every algorithm compares
Every measured algorithm ranked on each metric, with no single baseline and no faster/slower verdict. Key exchange & KEM on the left, signatures on the right; each row is one metric. The reply row is a KEM ciphertext or a DH ephemeral public key, and wire total counts both protocol messages (the apples-to-apples size). Pick a single NIST level for a like-for-like comparison. Bar length is proportional to the value by default; the scale toggle switches every card to log-scaled bars, where equal steps in length are equal ratios, which spreads out the slow tail. The exact number is labeled on each bar either way.
How the three KEM operations map to OpenSSL EVP calls
The three KEM operations map to different OpenSSL EVP calls depending on the family. Native KEMs (ML-KEM, HQC, FrodoKEM, BIKE, and RSA via RSASVE) use the encapsulate/decapsulate API directly. ECDH and X25519 are not KEMs in OpenSSL, so they are mapped in as DHKEM (RFC 9180) built from keygen + derive. Same roles, so they share the KEM axes:
| Step | Native KEM (ML-KEM, HQC, RSA via RSASVE) | ECDH / X25519 (DHKEM, RFC 9180) |
|---|---|---|
| Keygen | EVP_PKEY_keygensample the private key, compute the
public key from the scheme trapdoor (lattice t = A·s + e, code, or RSA
modulus) |
EVP_PKEY_keygenpick a scalar d, compute the
recipient point d·G |
| Encapsulate | EVP_PKEY_encapsulatedraw a random shared secret, wrap
it under the recipient public key to make the ciphertext |
EVP_PKEY_keygen + EVP_PKEY_derivegenerate
an ephemeral keypair e, compute e·P; the ephemeral public key
e·G is the ciphertext. The ephemeral keygen is timed here, which is why ECDH
encapsulate is slower than its own keygen. |
| Decapsulate | EVP_PKEY_decapsulaterecover the shared secret from the
ciphertext with the private key |
EVP_PKEY_derivecompute d·(e·G), the same shared
point d·e·G |
Keygen + encapsulate + decapsulate together are one full two-message exchange, split by who pays each cost, not double-counted.
KEM / key exchange
Signatures
Symmetric context
Secondary section: hashes and AEADs measured through the same EVP path, for a Grover-era reference point.
Why a hash can beat AES-GCM at 16 B and lose heavily at 64 KB
The two ends of this table measure different things. At large buffers the numbers reflect the core primitive: on hardware with dedicated instructions, AES blocks pipeline in parallel while a hash compression function is one serial dependency chain, so bulk AES-GCM throughput typically runs several times past SHA-256.
At the smallest buffer the payload work is negligible and the number is dominated by fixed per-call cost, which is intrinsically higher for an AEAD seal than for a digest. One digest call initializes eight words of state, runs one compression, and is done. One GCM seal sets the nonce and derives the initial counter block, encrypts its single block, then closes out GHASH with the mandatory length block and encrypts the authentication tag, through a heavier EVP cipher-context setup path. That bookkeeping is the same regardless of payload, and at 16 B it is most of the call, which is how a hash can post a faster small-message time than an AEAD it loses to in bulk.
The same effect stacks for a cipher without dedicated instructions on the host CPU (SM4-GCM on most non-Chinese silicon): GCM overhead plus a software block cipher. This is why each row is measured at several buffer sizes: small buffers rank per-call overhead, large buffers rank the primitive.
Appendix: skipped / error results
Records that did not reach status: ok this run (missing provider, build tier not present, or a failed correctness gate).
Standards
Published specification for each algorithm family present in this run, with its NIST PQC process history where applicable. Links open in a new tab.
| AES | FIPS 197, SP 800-38D (GCM) |
|---|---|
| AIMer | KpqC (Korea) Korea KpqC competition winner (2025); not part of the NIST PQC process. |
| BIKE | not standardized (research / competition candidate) NIST PQC round-4 KEM candidate; not selected (round 4 closed Mar 2025). |
| CROSS | not standardized (research / competition candidate) NIST additional-signatures on-ramp, round 2 (2024); not yet selected. |
| ChaCha20 | RFC 8439 |
| ECDH | FIPS 186-5 |
| ECDSA | FIPS 186-5 |
| Ed25519 | RFC 8032 |
| Ed448 | RFC 8032 |
| Falcon | FIPS 206 (draft) NIST PQC round-3 finalist; selected Jul 2022; FIPS 206 (FN-DSA) in draft. |
| FrodoKEM | ISO/IEC 18033-2 Amd 2 NIST PQC round-3 alternate; not advanced — continued on the ISO track. |
| HAETAE | KpqC (Korea) Korea KpqC competition winner (2025); not part of the NIST PQC process. |
| HQC | NIST selection (2025) NIST PQC round-4 KEM; selected Mar 2025 as the fifth standardized KEM. |
| MAYO | not standardized (research / competition candidate) NIST additional-signatures on-ramp, round 2 (2024); not yet selected. |
| ML-DSA | FIPS 204 NIST PQC round-3 finalist (CRYSTALS-Dilithium); selected Jul 2022. |
| ML-KEM | FIPS 203 NIST PQC round-3 finalist (CRYSTALS-Kyber); selected for standardization Jul 2022. |
| NTRU+ | KpqC (Korea) Korea KpqC competition winner (2025); not part of the NIST PQC process. |
| RSA | FIPS 186-5 |
| SHA- | FIPS 180-4 |
| SHA3 | FIPS 202 |
| SLH-DSA | FIPS 205 NIST PQC round-3 alternate (SPHINCS+); selected Jul 2022. |
| SM2 | ISO/IEC 14888-3, RFC 8998 (TLS) |
| SM3 | ISO/IEC 10118-3 |
| SM4 | ISO/IEC 18033-3, RFC 8998 (TLS) |
| SMAUG-T | KpqC (Korea) Korea KpqC competition winner (2025); not part of the NIST PQC process. |
| SecP256r1MLKEM768 | draft-ietf-tls-ecdhe-mlkem, FIPS 203 |
| X25519 | RFC 7748 |
| X25519MLKEM768 | draft-ietf-tls-ecdhe-mlkem, FIPS 203 |
| X448MLKEM1024 | draft-ietf-tls-ecdhe-mlkem, FIPS 203 |
Referenced building block, not benchmarked as a standalone row: the SHAKE extendable-output function (FIPS 202 (SHAKE)), used to expand the public seed into the module/lattice matrix inside ML-KEM and FrodoKEM. The AES rows run in GCM mode, whose specification is linked alongside the AES block cipher above.
Standardized but not benchmarked: Classic McEliece (ISO/IEC 18033-2 Amd 2, classic.mceliece.org), a NIST PQC round-4 KEM candidate not selected by NIST (round 4 closed Mar 2025) but standardized in the same ISO/IEC 18033-2 amendment as FrodoKEM and recommended by BSI (Germany). No OpenSSL provider currently exposes it (oqs-provider carries the liboqs implementation but has no provider mapping for it), and this suite only measures algorithms reachable through the OpenSSL EVP call path. It will be added when a provider exposes it.