openbsd/src/lib/libcrypto/mlkem, branch masterA mirror of https://github.com/libressl/openbsd.git
https://git.lua4.win/openbsd/atom?h=master2026-04-20T08:14:29+00:00mlkem: use <openssl/mlkem.h> instead of "mlkem.h"2026-04-20T08:14:29+00:00tb2026-04-20T08:14:29+00:00urn:sha1:052c4cf7f1328bcebfedf3eb9c2c76290dad8e7d
patch from portable
ML-KEM: ensure that key_768 is only dereferenced with 768-bit keys2026-03-29T06:31:07+00:00tb2026-03-29T06:31:07+00:00urn:sha1:a05eb59f42ce4d1df74a595e48b369757dc58547
This looks like a NULL dereference that should crash, but for some reason
it doesn't, even with -O0 with all compilers i tried. At the very least it
may result in compilers deducing that key_768 != NULL and lead to incorrect
optimizations.
ok claudio jsing kenjiro miod
mlkem: use timingsafe_memcmp() in decapsulation2026-03-06T09:22:29+00:00kenjiro2026-03-06T09:22:29+00:00urn:sha1:e6b7b55ad0eccc084f5757d7c3e4380079fc99b8
Replace memcmp() with timingsafe_memcmp() when comparing the
re-encrypted ciphertext.
FIPS 203 Section 6.3 defines this comparison result as a secret piece
of intermediate data that must not be revealed in any form.
ok tb
mlkem: fix mklem_{generate_key,encap}_external_entropy() declarations2026-01-18T08:58:31+00:00tb2026-01-18T08:58:31+00:00urn:sha1:8c2e30618ba07e5c076d4f6492f61fe7dea05412
The prototypes used sized arrays appropriate only for MLKEM768 while the
declarations used pointers. For some reason clang doesn't flag this but
gcc does. In any case it was wrong. The callers of these functions check
that they pass in the correct size. Which is weird but the mlkem directory
has an unbelievable amount of mess and bad code.
found by/ok jsing
mlkem: garbage collect the unusd mlkem_{generate_key,encap}()2026-01-18T08:49:42+00:00tb2026-01-18T08:49:42+00:00urn:sha1:0b69c4a2b1ef8ad6b85503729d1bd0bc68541697
These are flagged by more recent gcc since declarations and definitions
don't match (sized array vs pointer). Also an array was checked for NULL.
found by/ok jsing
mlkem_internal.h: formate -> format2026-01-16T18:31:12+00:00tb2026-01-16T18:31:12+00:00urn:sha1:72dc54bbad1c240705b7047940026b4472f5dc2emlkem_internal.h: some very basic copy editing2026-01-16T18:29:58+00:00tb2026-01-16T18:29:58+00:00urn:sha1:dcbd53bcbd78c031d6d012192ac183de96a3082fmlkem.h: Thie -> This (2x)2026-01-16T18:28:04+00:00tb2026-01-16T18:28:04+00:00urn:sha1:591a62834f9696acafe181bbaa784aae617b260emlkem.c: becuase -> because2026-01-16T18:27:22+00:00tb2026-01-16T18:27:22+00:00urn:sha1:1288ad53eb2d1af968bfa2ba9cf0ac866955d8c7mlkem: clear a few (pointers to) secrets2026-01-01T13:36:09+00:00tb2026-01-01T13:36:09+00:00urn:sha1:2f3ff374dcb9558a8165a6b1cf17cc024522a212
The ML-KEM code is doing a pretty poor job at cleaning up secrets it no
longer needs. This commit clears a few stack-based arrays containing
secrets or not obviously public information and stack-based structs
containing pointers to secrets.
ok jsing kenjiro