| commit | 5e73d0302c50cc38324686f937a75233d13ae4f0 | [log] [tgz] |
|---|---|---|
| author | Adam Langley <agl@chromium.org> | Fri Feb 14 15:44:03 2025 +0000 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Mon Mar 03 16:02:03 2025 -0800 |
| tree | 0f3cd68e60782f8d8fdf3b465d8e54e27c329a73 | |
| parent | 673e61fc215b178a90c0e67858bbf162c8158993 [diff] |
Add ML-KEM self-tests. For some reason I had thought that NIST weren't doing this stuff for new algorithms, but they are. The following quote is from IG 10.3.A: > if the module implements ML-KEM decapsulation, the module shall have a CAST for the ML-KEM decapsulation mechanism. The decapsulation algorithm of ML-KEM accepts a decapsulation key (dk) and a ML-KEM ciphertext (c) as input, does not use any randomness, and outputs a shared secret (K’). The CAST shall use the ML-KEM decapsulation algorithm (i.e., Algorithm 21 in FIPS 203), and for a KAT, using fixed/predetermined dk and c values, to compare the resulting outputs to precomputed value of K'. Note21: The ML-KEM decapsulation CASTs shall cover both the implicit rejection and (unnamed) non-rejection paths. > > The above CASTs shall be performed on at least one of the following parameter-sets for MLKEM that are implemented in the approved mode: ML-KEM-512, ML-KEM-768, or ML-KEM-1024. > > if the module implements ML-KEM key generation, the module shall have an ML-KEM key generation CAST. The ML-KEM key generation does not take input and outputs an encapsulation key (ek) and a decapsulation key (dk). The CAST shall use the ML-KEM key generation algorithm (i.e., Algorithm 19 in FIPS 203), and for a KAT, using a fixed/predetermined random values (i.e., z and d), to compare the resulting outputs to the pre-computed values of ek and dk. > > For key pairs generated for use with approved KEMs in FIPS 203, the PCT (described by the tester in TE10.35.01) shall consist of applying the encapsulation key ek to encapsulate a shared secret K leading to ciphertext c, and then applying decapsulation key dk to retrieve the same shared secret K. The PCT passes if the two shared secret K values are equal. Change-Id: Ic5704e1e59fb9876ce666a88518a37f61fd7d6b9 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/76387 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>
BoringSSL is a fork of OpenSSL that is designed to meet Google's needs.
Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.
Programs ship their own copies of BoringSSL when they use it and we update everything as needed when deciding to make API changes. This allows us to mostly avoid compromises in the name of compatibility. It works for us, but it may not work for you.
BoringSSL arose because Google used OpenSSL for many years in various ways and, over time, built up a large number of patches that were maintained while tracking upstream OpenSSL. As Google's product portfolio became more complex, more copies of OpenSSL sprung up and the effort involved in maintaining all these patches in multiple places was growing steadily.
Currently BoringSSL is the SSL library in Chrome/Chromium, Android (but it's not part of the NDK) and a number of other apps/programs.
Project links:
To file a security issue, use the Chromium process and mention in the report this is for BoringSSL. You can ignore the parts of the process that are specific to Chromium/Chrome.
There are other files in this directory which might be helpful: