PQ KEM comparison tool

[Thom Wiggers]

Hi all,

On suggestion of Frederik Vercauteren, I’ve expanded the scope of my “signatures zoo” website [1] by adding a page that compares KEMs [2].

While I have your attention, please also see the “advanced view” link below the graphs that will allow you to plot whatever you want on the X and Y axes!

I am open to suggestions for more things to include. For signatures I think I would like to keep the focus on the NIST on-ramp for now, but for KEMs I think that the discussion in CFRG benefits from a more open approach.

I hope this is helpful,

Thom

[1] https://pqshield.github.io/nist-sigs-zoo/

[2] https://pqshield.github.io/nist-sigs-zoo/kems/

N.B. Unfortunately, the NEV KEM (which is also very compact) did not appear to have an implementation available, so I have not added it. If anyone knows where I could find it, let me know. 

[John Mattsson]

Thanks Thom, Great work! 

>I am open to suggestions for more things to include. For signatures I think I >would like to keep the focus on the NIST on-ramp for now, but for KEMs I think >that the discussion in CFRG benefits from a more open approach.

For the KEMs, I think it would be nice with some isogeny-based KEM for comparison. It should fit nicely between ECDH-KEM and BAT.

Cheers,

John Preuß Mattsson

--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.
To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/D527D3F9-A057-49DD-A256-9B4D6A8A2124%40thomwiggers.nl.

[Thom Wiggers]

Hi all,

@John: any particular suggestions? 

@Aron: I’m not sure how to include these figures without overly cluttering the interface. Differing implementations is really one route I don’t want to get into (beyond using some “reasonably performant implementation” to have roughly apples-to-apples comparisons). The number of iterations for ML-DSA (and other schemes using rejection sampling) is really relevant and I would like to point people to my colleagues’ paper [1] — but again, in my opinion it’s way too complicated to meaningfully include in this high-level comparison.

Cheers,

Thom

[1] https://eprint.iacr.org/2026/1333  

Op 2 jul 2026, om 09:27 heeft Aron <bar...@freemail.hu> het volgende geschreven:

Hi Thom,

very useful site/diagram! Thanks for it!

One question/suggestion: since the measured running times are also shown/listed in the table for "Keygen", "Encaps", "Decaps", "Sign", "Verify", is it possible to use other crypto libraries as well? This would make possible to compare the currently used OpenSSL with Java JDK, BouncyCastle, .NET core. All of these could be used on the same OS. Also, for "Sign", is it possible to show avg. number of iterations to get one ML-DSA signature?

BR, Aron

-------- Eredeti levél --------

Feladó: John Mattsson <john.mattsson=40erics...@dmarc.ietf.org>

Dátum: 2026 július 2 07:26:11

Tárgy: [CFRG] Re: [pqc-forum] PQ KEM comparison tool

Címzett: Thom Wiggers <th...@thomwiggers.nl> IRTF CFRG <cf...@irtf.org> pqc-forum <pqc-...@list.nist.gov>

[Damien Robert]

Speaking of isogeny-based KEM, I would like to advertise our upcoming isogeny-based post-quantum Non-Interactive Key Exchange (NIKE), called **MIKE** (Module Isogeny Key Exchange), which we believe will be of great interest to this community.

- **Compact keys:** 64B for NIST Level 1, and 128B for NIST Level 5.
 
- **Fast key exchange:** For NIST Level 1, our Rust implementation requires <1 ms for key generation and <5 ms for the full key exchange (benchmarked on an AMD Ryzen 7 PRO 7840U @ 3.3GHz).

- **Simple Implementation:** Our implementation is simple ($$\approx 4200$$ LoC, excluding finite field arithmetic) and constant time

- **Active security:** It is an actively-secure NIKE. The timings above include public key validation, which is a supersingularity test over $$\mathbb{F}_{p^2}$$.
 
- **Provable security:** We prove MIKE's security (in the algebraic isogeny model) as a passively-secure NIKE or a KEM assuming only the supersingular endomorphism ring problem (the core assumption in isogeny-based cryptography).
 

We aim to release the paper and code by the end of August.

Damien, on behalf of the MIKE team: Andrea Basso, Pierrick Dartois, Max Duparc, Jonathan Komada Eriksen, Sabrina Kunzweiler, Michael Meyer, Giacomo Pope, Krijn Reijnders, Damien Robert, Ryan Rueger, and Sina Schaeffler.

[Demi Marie Obenour]

On 7/3/26 13:37, Damien Robert wrote:
> Speaking of isogeny-based KEM, I would like to advertise our upcoming
> isogeny-based post-quantum Non-Interactive Key Exchange (NIKE), called
> **MIKE** (Module Isogeny Key Exchange), which we believe will be of great
> interest to this community.
>
> - **Compact keys:** 64B for NIST Level 1, and 128B for NIST Level 5.
>
> - **Fast key exchange:** For NIST Level 1, our Rust implementation requires
> <1 ms for key generation and <5 ms for the full key exchange (benchmarked
> on an AMD Ryzen 7 PRO 7840U @ 3.3GHz).
>
> - **Simple Implementation:** Our implementation is simple ($$\approx 4200$$
> LoC, excluding finite field arithmetic) and constant time
>
> - **Active security:** It is an actively-secure NIKE. The timings above
> include public key validation, which is a supersingularity test over
> $$\mathbb{F}_{p^2}$$.
>
> - **Provable security:** We prove MIKE's security (in the algebraic isogeny
> model) as a passively-secure NIKE or a KEM assuming only the supersingular
> endomorphism ring problem (the core assumption in isogeny-based
> cryptography).
>
>
> We aim to release the paper and code by the end of August.

This looks like a drop-in replacement for ECDH, except for the messages
being twice as large. I'm very much excited!
--
Sincerely,
Demi Marie Obenour (she/her/hers)