ml-kem-native performance

[ram-singh-git]

Hello Team,

I understand that starting from version 0.13.0, the pq-crystals package for ML-KEM has been replaced by ml-lem-native.

Could you please let me know if there are any documented performance benchmarks or comparisons available between the two implementations? Specifically, I’m interested in understanding whether the native package is faster, slower, or has any other relevant performance characteristics compared to the pq-crystals implementation.

If such data is available, I would appreciate it if you could point me to the appropriate documentation or resources.

Thank you in advance for your support.

[dstebila]

See this thread for performance of the preliminary version of mlkem-native a few months ago.

[ram-singh-git]

@dstebila thanks for the quick response.

I had a look at the thread and the tests seem to be run on an intel device and it seems the performance seems to be at par with pq-crystals package with the additional sanity check introduced in the native package. Correct ?

just another stupid question : are you aware of similar tests runs that uses ‘reference’ implementations and not intel based avx2 implantations?

Thanks and wish you a nice evening

[dstebila]

@mkannwischer Have you any further results?

[mkannwischer]

That thread also has performance results on the "generic implementation" which is the C backend implementation, i.e., no AVX2 assembly. That should be exactly what you are looking for. It's significantly faster than the previous C implementation in liboqs. Something like 1.3-1.5x.

Another data point is a recent pqm4 integration: mupq/pqm4#394
This provides performance results on the Arm Cortex-M4 microcontroller. If you compare mlkem-native (mlkem-native, C backend) to clean (pqcrystals reference implementation), you'll see a 1.2x-1.3x improvement.

[ram-singh-git]

@mkannwischer thank you for the reply.

may I know the fips-202 backend code for SHA-3 and SHAKE used for the generic C implementation without AVX2.
Is it the six FIPS-202 files here : https://github.com/pq-code-package/mlkem-native/tree/main/mlkem/src/fips202 ?

and the thread corresponds to the beta-release. Are the results same for the stable release v1.0 added last week ?

thanks in advance for your time.

[mkannwischer]

@mkannwischer thank you for the reply.

may I know the fips-202 backend code for SHA-3 and SHAKE used for the generic C implementation without AVX2. Is it the six FIPS-202 files here : https://github.com/pq-code-package/mlkem-native/tree/main/mlkem/src/fips202 ?

OQS comes with it's own SHA-3 implementation, so the files you are pointing to are not actually used in OQS. If you use mlkem-native directly, then yes, these files are the generic C backend for FIPS202.
@dstebila what implementation are you using?

and the thread corresponds to the beta-release. Are the results same for the stable release v1.0 added last week ?

Very good point. You can see performance changes over time here. For the generic implementation you can look at "no-opt". Between March 3, 2025 (v1.0.0-beta) and now, I cannot see a lot of performance changes. The biggest one appears to be this change resulting in a 1-3% improvement.

[dstebila]

OQS comes with it's own SHA-3 implementation, so the files you are pointing to are not actually used in OQS. If you use mlkem-native directly, then yes, these files are the generic C backend for FIPS202. @dstebila what implementation are you using?

Depends on how the library is built. We have an AVX2 and plain C implementation from XKCP, and can also use the OpenSSL SHA3 implementation if available. Running one of the OQS test programs (test_kem or test_sig) will print which implementation is used.