Import ML-KEM from mlkem-native/PQ code package #2041
Conversation
Signed-off-by: Basil Hess <[email protected]>
bhess
force-pushed
the
bhe-mlkem-native
branch
from
7f66f23 to
274d30c
Compare
| @@ -334,19 +334,43 @@ endif() | |||
|
|
|||
| if(CMAKE_SYSTEM_NAME MATCHES "Linux|Darwin") | |||
| if(OQS_DIST_X86_64_BUILD OR (OQS_USE_AVX2_INSTRUCTIONS AND OQS_USE_BMI2_INSTRUCTIONS AND OQS_USE_POPCNT_INSTRUCTIONS)) | |||
| cmake_dependent_option(OQS_ENABLE_KEM_ml_kem_512_avx2 "" ON "OQS_ENABLE_KEM_ml_kem_512" OFF) | |||
| cmake_dependent_option(OQS_ENABLE_KEM_ml_kem_512_x86_64 "" ON "OQS_ENABLE_KEM_ml_kem_512" OFF) | |||
There was a problem hiding this comment.
Could the naming change here cause issues? e.g. with our filter_algs logic.
There was a problem hiding this comment.
Thanks for spotting this @SWilson4. I'll review and update the logic.
Signed-off-by: Basil Hess <[email protected]>
bhess
force-pushed
the
bhe-mlkem-native
branch
from
959c697 to
1eebf31
Compare
Signed-off-by: Basil Hess <[email protected]>
Signed-off-by: Basil Hess <[email protected]>
Signed-off-by: Basil Hess <[email protected]>
Signed-off-by: Basil Hess <[email protected]>
bhess
requested review from
dstebila,
baentsch,
alexrow and
praveksharma
as code owners
There was a problem hiding this comment.
Thanks for the PR, @bhess. I surely didn't check all 540 files but focused on the integration logic: Please see the single comments. In general, the patch is way too large in my opinion: Isn't it possible that the upstream uses fewer hard-coded include paths and also provides a YML documentation of their implementation? "copy_from_upstream" ideally should be easy to run to regularly follow the upstream without the need to always create new patches: the latter only creates unnecessary work for OQS and consequently reduces the motivation for keeping the code up-to-date. Of course, if there is no further development expected in PQCP (is it?) this point is moot.
| } | ||
| }, | ||
| "components": [ | ||
| { | ||
| "type": "library", | ||
| "bom-ref": "pkg:github/open-quantum-safe/liboqs@69a80f8a66988521d51e94d716cff8c936c07b8d", | ||
| "bom-ref": "pkg:github/open-quantum-safe/liboqs@d0d0413dc9fff538296ab86bac492cb4bf54dedb", |
There was a problem hiding this comment.
Just for my understanding: Why is there no reference to PQCP in this CBOM, just a reference to liboqs? Also, the updates here look like the new code provides fewer features (only deletions) -- is this so? Also no use of SHA3 any more. But I may completely misunderstand the purpose of this CBOM (probably incorrectly thinking this is documenting dependencies), so apologies for the probably stupid question.
| --- /dev/null | ||
| +++ b/ML-KEM-1024_META.yml | ||
| @@ -0,0 +1,63 @@ | ||
| +name: ML-KEM-1024 |
There was a problem hiding this comment.
This is information that describes the implementation loaded: IMO this is stuff that must come from the upstream and not be provided by OQS as a patch.
| } | ||
| { | ||
| Rejection sampling to produce public "A" matrix | ||
| <insert_a_suppression_name_here> |
There was a problem hiding this comment.
Missing documentation? Interesting to see how closely mlkem-native resembles the reference implementation.
This PR tracks the integration of ML-KEM from the mlkem-native upstream repository.
It replaces the current ML-KEM implementation in liboqs, which was previously imported from pq-crystals, with the mlkem-native implementation from PQCP.
Some features of mlkem-native:
The upstream code recently had a v1.0.0-alpha release and is actively maintained. The goal is to synchronize the PR with an upcoming tagged release of mlkem-native.
Additionally, the upstream code includes enhanced key validation as defined by FIPS 203 by default, which resolves issue #1951.
Closes #1951.
TODOs: