Benchmark ML-KEM #4653
Draft
Benchmark ML-KEM #4653
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
|
Maybe #4595 can help with estimating the stack usage? |
By zeroing the stack memory before the workflow runs, we can estimate how much of it has been used (by reading the stack memory and looking for the first non-zero value). [no changelog]
onvej-sl
force-pushed
the
onvej-sl/mlkem
branch
from
1b34e95 to
d86d76f
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The purpose of this pull request is to test the viability of running ML-KEM on Trezor. ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism, formerly known as CRYSTALS-Kyber) is a quantum computer-resistant key encapsulation mechanism algorithm that was standardized by NIST as a finalist in the NIST post-quantum cryptography competition.
ML-KEM is a post-quantum replacement for the Diffie-Hellman protocol. Unlike Diffie-Hellman, this protocol is not symmetrical. Only one person contributes to the entropy of the resulting shared secret.
There are three variants: ML-KEM-512, ML-KEM-768, and ML-KEM-1024, in the order of increasing security strength and decreasing performance.
I adopted this implementation because they claim it to be resistant to side-channel attacks. However, I have not conducted an in-depth survey of the implementations.
The benchmark was run on the trezor T.
I don't have a way to measure RAM usage, butI had to increase the size of the C stack from 16 KB to 32 KB. The implementation size includes an implementation of SHA-3 that is 5.5 kB and is probably duplicate.EDITED: Thanks to @romanz, I added stack usage.