Kyber was the prestandard version of ML-KEM. Callers should be using
ML-KEM now. For now, keep the implementation behind an internal header
for libssl, but we expect to remove that soon too.
Update-Note: <openssl/experimental/kyber.h> is gone. Use
<openssl/mlkem.h> instead.
Bug: 438787615
Change-Id: I02919e5d627dcbe863e70e433c79e360a556d462
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/81287
Reviewed-by: Lily Chen <chlily@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Upcoming NIST rule changes are expected to effectively require us to
pass in larger entropy inputs to the DRBG, which requires us to use the
"derivation function" option from 800-90A.
This change implements the derivation function and splits the entropy
and nonce arguments out, as needed for this style of DRBG.
Since we have external users of the existing CTR-DRBG mode, that is
still supported, but all internal uses will now use a derivation
function.
Change-Id: I8079e9f4c6238e91c68fef1e40189211f4142555
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/79768
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
In 17164ff, it was asserted that checkout_rust did not need to actually
run util/bot/tools/clang/scripts/update.py, only to pull in the python
script.
This seems incorect after all, as bindgen must be able to find system
header files which it gets from libclang, so for consistency just run
the clang hook so that those header files are in a predictable location.
Change-Id: Ifc577d2847c5da2aa02f7a49b130243e599cb18c
Bug: 42290446
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/80787
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: Lily Chen <chlily@google.com>
Use gclient with the condition 'checkout_rust' to pull in the
update_rust.py script from Chromium. Add a hook to run update_rust.py
to download a copy of the Rust toolchain from GCS.
Because update_rust.py depends upon the tools/clang/scripts/update.py
script, this modifies the condition for boringssl/util/bot/tools/clang
to also fetch the clang script whenever we 'checkout_rust' (but it does
not need to actually run tools/clang/scripts/update.py).
Change-Id: I8e10d99ef6bdad04796eff4a0b98fdf5e0e7c6f0
Bug: 42290446
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/80507
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: Lily Chen <chlily@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
I've kept the LLVM things back for now because Chrome seems to be in
some weird halfway point where libc++abi depends on a macro that libc++
doesn't have yet? I'm not really sure what's going on there and why it's
building for Chrome, but hopefully next time it will have settled.
I've also, for now, kept bazel at 7.5.0. We probably shouldn't update to
8.x on CI until that's our minimum version. There is a 7.6.1, but CIPD's
Bazel packages seem to only make a build for a version if newer than the
latest one, so all 7.x versions after 8.0.0's release are missing.
We may need to do something about this later, but ignoring the problem
for now.
Change-Id: Id17a3b394f68659e91a6dc563aaa40cd6912c1db
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/79327
Commit-Queue: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
The compiler may want to load than one word. When loading into a
register of the same size, aarch64 mostly sticks to the LDR mnemonic,
but sometimes you need to load into a larger destination register. In
that case, there is a family of suffixed instructions.
(There is no LDRW because LDR W0 would be the same as LDRW X0. LDRSW X0
is needed because you might want to sign-extend instead of zero-extend.)
Change-Id: I1b6d9ab860b13c7ef91d4f9ee79b519367703ac0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/78967
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
The one remaining external reference was in an unused parameter where it
was impossible to obtain a non-null value. Remove the last of that
machinery from the public API. This leaves us free to completely rework
LHASH_OF(T) internally, including making it a template that understands
whether it owns its values.
(If we end up needing to revert it, we can still make the real
LHASH_OF(T) into a template. It just won't be called LHASH_OF(T)
anymore.)
Update-Note: Calling code which references LHASH_OF(T) will no longer
compile. We have had no public APIs that allow a caller to usefully
construct an LHASH_OF(T) for some time, so this only ever came up in odd
cases around bindings APIs.
Change-Id: I5a44310b04d8f8f3599f0f356b64786e62db5fbf
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/78787
Reviewed-by: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
There was no real organization to which files I looked at here. Mostly
just bounced around. At some point we'll probably need to set up some
more infrastructure though:
- For functions to return UniquePtr, they need to stop being C linkage,
which is something we want to do anyway.
- For types to use UniquePtr, we need to get them out of malloc/free and
into the realm of constructors and destructors. That probably means
moving some of the helpers from ssl/internal.h to crypto/internal.h.
- UniquePtr is not very good at buffers. We should probably move Array
Vector, and InPlaceVector to crypto/internal.h.
Change-Id: I90ebc917051d354c0e447598f382db6b22eb8813
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/78687
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Support fetching and uploading vectors and results for arbitrary NIST
algorithms. Enabled by removing the algorithm check when parsing the
middleware's advertised configuration. This check still exists prior to
sending test vectors to the middleware for execution.
Change-Id: I77212b414a8f880f57d9834427f98b303ef06e57
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/77648
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: Brian Orr <brianorr@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This moves test_fips and modulewrapper up to the build directory like
most of our other targets. Also integrate modulewrapper's source list
into build.json since it has more than one file.
Change-Id: I45335630c9bfe4be8293ce03dd3aef5c4963e3bf
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/78609
Reviewed-by: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This requires importing CTest to declare the BUILD_TESTING option (in
particular default it to ON). I've not registered our tests with CTest
or anything, though that may be something to explore and perhaps retire
all_tests.go.
Bug: 389897612
Change-Id: I5e9a853f6a5fea9229bcd3a2a202c91627f6d3de
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/78608
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
99bd1df99b removed MAC truncation from ACVP but the ACVP tests aren't
run on the commit queue and so I missed updating the tests accordingly.
This change fixes them.
NIST appears to include tests with huge messages and keys now, so the
trimming script it updated to ignore those so that we aren't checking in
megabytes of test vectors.
Change-Id: I09b0eae2fb9b4d5865d51e17e95b1e61e38a5726
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/78628
Commit-Queue: Adam Langley <agl@google.com>
Auto-Submit: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This fixes the SDE builders after
https://boringssl-review.googlesource.com/c/boringssl/+/75008/
VS comes with some runtime dlls for things like the debug version of
their C runtime. These are not generally available on Windows machines
(notably not on our CI machines), so debug builds need to get them from
MSVC.
Annoyingly, those directories are not part of the SetEnv.{arch}.json
files in MSVC, so I had to put them in by hand elsewhere. I attempted to
match what the old package and the GN goop was doing, but it resulted in
a mysterious error on 64-bit debug builds. So the version I landed just
filtered by CPU.
This worked except that win64_sde broke with a different error. Looks
like the sde.exe launcher is 32-bit (though why it needs MSVC dlls, I'm
not sure).
After some more wrestling, it turns out the problem was the directory
order! Due to a bug and some incorrect sorting, I put them in order
sysarm64, sys64, sys32. The correct order is sys64, sys32, sysarm64.
The order is actually significant. There are some x86_64 dlls in
sysarm64 that confuse Windows. (arm64ec perhaps?)
Anyway, go back to putting them all in there. This is probably also
wrong, to be honest, but this matches what we were doing before. We can
dig into this further later.
Change-Id: Id8108f40baa761b50e30135f21a72345130ef729
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/78547
Commit-Queue: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This isn't updated as frequently, but is much less of a hassle to use.
In particular, the vs_toolchain.py and depot_tools version seems to have
broken recently for some mysterious reason. Current theory is that
something about
https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/6288233
broke, but given the report of bots with bad caches and past issues, I
think a CIPD package might be more straightforward.
There's a windows_sdk recipe module that we could use alongside it, but
then we cannot preview MSVC updates on the CQ, so I opted to keep our
goofy vs_env.py script. Also LUCI is very, very bad at atomic recipe +
code changes, so keeping it is convenient.
As a bonus, this removes the last Chromium license file in util/bot so
the LICENSE file can get a hair shorter. (Now the only source of
weirdness is ssl/test/runner.)
Change-Id: I2ec269c178829660978e6a9e1a9e14477382d82d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/75008
Reviewed-by: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
This implements just the small subset of OpenSSL's CMS API to support
the Linux kernel's sign-file.c tool. It is nowhere close to a full CMS
implementation and is not intended to become one. In particular, it does
not implement enough of CMS to support S/MIME. That requires much, much
more infrastructure than was implemented here.
CMS is, like PKCS#7, an over-engineered and cryptographically unsound
set of nestable combinators to support just about any configuration of
cryptographic operations. Profiling CMS down to a usable subset is, as a
result, more complicated, more risky, and less efficient than just
designing a bespoke structure for your use case. It is derived from
PKCS#7, and largely overlaps. However, both PKCS#7 and CMS use the v1
version number, but CMS made incompatible changes in some corner cases
that, so far, do not matter to us. (It is incompatible if you try to
layer SignedData atop another combinator, where the lack of proper
domain separation in this badly designed format is of extra risk.)
In the case of the kernel, sign-file.c wants an "external signature",
which is when the data to be signed lives elsewhere. This is, as a
result, a very, very inefficient way to concatenate an enum with a byte
string. But this is what the kernel chose, so here we are.
Because PKCS#7 and CMS are broadly the same structure, I've generalized
the internal PKCS#7 function rather than duplicating all this code. If
we ever hit the cases where PKCS#7 and CMS v1 are incompatible, plumbing
an extra boolean will be the least of our worries.
Test data was generated by compiling the actual sign-file.c against
OpenSSL and saving the output.
Change-Id: Idb0874d2b5294bfad564f3a00458c3fd044d9da5
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/78452
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This is only valid in ACVP if the truncation occurs within the FIPS
module. But that's not a useful service: the caller can always discard a
few bytes and is better positioned to do so.
Change-Id: Id5e6459c9fa6d8b1b8f7a398feab6c4816adf8ab
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/78247
Commit-Queue: Adam Langley <agl@google.com>
Auto-Submit: Adam Langley <agl@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
GCS support adds a ton of dependencies, so hide it behind a "gcs" build
tag. To build with GCS support, pass "-tags gcs" to "go build".
While I'm here, remove the old +build style of build constraint. We can
depend on go:build now.
Also while I'm here, fix some style issues with the GCS support: Go
style is "GCS" not "Gcs" for acronyms, and ioutil.ReadAll has been
replaced with io.ReadAll.
Change-Id: I409a87f3b7b0d99995fad55edc0d8e61ab77232d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/77367
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Originally I thought the problem was that weak symbols need renaming,
but actually delocate is fine with those. The local_target business
(somewhat accidentally) routes around this problem.
The problem is that GCC emits C1 and C2 constructors for unique_ptr as
aliases of each other using .set foo, bar and we don't recognize that
pattern as defining a symbol.
The linker script version of this pipeline will need to do it with
renaming instead, but we'll get to that later. Renaming symbols is
actually quite annoying in delocate.
Fixed: 397980180
Change-Id: I378c759c07a41af1155acf3f41889a0bd52b002f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/76967
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
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>
We need to demangle because the backing storage for a delocated BSS
symbol is declared static. The compiler seems to be always give it a
C++-mangled name. But we relied on those names to infer the names of the
bss_get functions that the rest of the code wanted.
Instead, if we make the backing storage non-static, we get the name we
want. Ideally we would avoid having to extract those names (see
https://boringssl-review.googlesource.com/c/boringssl/+/70849), but
faking the linker script behavior in delocate seemed tricky, so I opted
to do this and then we can finish up the linker script version later.
While I'm here, prefix the underlying names with 'bcm_' so we're not
squatting as much of the namespace.
Change-Id: I1ce9a189e620c872511dbce09d23e655f1593d34
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/76847
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Both Conscrypt (more correctly, //external/boringssl) and Cronet in AOSP
rely on generate_build_files.py to create their Android.bp. This results
in build target name clashes. Cronet currently solves this by
namespacing its own build target names, but this is not
common/recommended practice in AOSP.
By introducing a way to prefix the build target name, Cronet will be
able to generate build targets that differ from Conscrypt's.
Bug: b:396593141
Change-Id: I34971e8973d5215eb9bb18601c7940910033ce36
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/76447
Commit-Queue: Stefano Duo <stefanoduo@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Currently, trying to "go install" something from BoringSSL's Go module
fails because the proxy-reachable name is
boringssl.googlesource.com/boringssl.git, but the go.mod name is
boringssl.googlesource.com/boringssl.
$ go install -v boringssl.googlesource.com/boringssl.git/util/fipstools/acvp/acvptool@master
go: downloading boringssl.googlesource.com/boringssl.git v0.0.0-20250122182937-e056f59c7dfd
go: boringssl.googlesource.com/boringssl.git/util/fipstools/acvp/acvptool@master: version constraints conflict:
boringssl.googlesource.com/boringssl.git@v0.0.0-20250122182937-e056f59c7dfd: parsing go.mod:
module declares its path as: boringssl.googlesource.com/boringssl
but was required as: boringssl.googlesource.com/boringssl.git
Using boringssl.googlesource.com/boringssl fails because without the
.git hint, the go tool will fetch
https://boringssl.googlesource.com/boringssl/util/fipstools/acvp/acvptool?go-get=1
which is not implemented by gitiles.
Adding .git to the module name makes the first command work.
Change-Id: I6a6a4656a34fac424114a5d65d23df677ca7de47
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/76107
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Adam Langley