In the STL, <iterator> has a std::size for arrays. Some of these could
also just be ranged for loops. One static_assert could not use
std::size(out->whatever) because out was not a compile-time value, but
std::extent_v<decltype(out->whatever)> works instead.
Change-Id: I28007c79f5583e09167b81a34a447e205ee6dd9b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/81658
Reviewed-by: Adam Langley <agl@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>
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>
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 use the standard Apache 2.0 file header, described in "APPENDIX: How
to apply the Apache License to your work."
This was primarily automated by running:
git ls-tree -r --name-only HEAD | xargs go run ./util/relicense.go
See go/boringssl-relicensing-triage for the results of triaging the
output of the tool.
As part of this, switch from taking fiat-crypto under MIT license to
Apache 2.0. (It is licensed under MIT OR Apache-2.0 OR BSD-1-Clause.)
The copyright_summary tool can also be used to confirm we didn't
accidentally drop any copyright lines:
# Run before the CL
git grep -l Copyright | xargs go run ./util/copyright_summary.go -out /tmp/old.json
# Run after the CL
git grep -l Copyright | xargs go run ./util/copyright_summary.go -compare /tmp/old.json
Bug: 364634028
Change-Id: I17c50e761e9d077a1f92e25969e50ed35e320c59
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/75852
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Following the guidance in
https://opensource.google/documentation/reference/releasing/authors,
start maintaining an AUTHORS file.
Update all existing Google copyright lines to 'The BoringSSL Authors'
per the document. This CL also changes the styling to match the new
guidance: removed the '(c)' and the comma.
All other existing copyright lines are left unmodified. Going forward,
our preference will be that new contributions to BoringSSL use 'The
BoringSSL Authors', optionally adding to the AUTHORS file if the
contributor desires.
To avoid being presumptuous, this CL does *not* proactively list every
past contributor in the BoringSSL half of the AUTHORS file. Past
contributors are welcome to send us a patch to be added, or request that
we add you. (Listed or not, the commit log continues to be a more
accurate record, and any existing non-Google copyright lines were left
unmodified.)
The OpenSSL half of the AUTHORS file is seeded with the contents of the
current OpenSSL AUTHORS file, as of writing. The current contents in the
latest revision of the 1.1.1 branch
(b372b1f76450acdfed1e2301a39810146e28b02c) and master
(d992e8729ee38b082482dc010e090bb20d1c7bd5) are identical, just formatted
in text vs Markdown.
Note when reviewing: CONTRIBUTING.md and AUTHORS contain non-mechanical
changes.
Bug: 364634028
Change-Id: I319d0ee63ec021ad85e248e8e3304b9cf9566681
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74149
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This change switches nearly all of BoringSSL to use C++. The public
functions still use the C ABI, and so code written in C can still use
BoringSSL. Also the use of the C++ standard library is minimal and no
run-time requirement for it is intended.
Change-Id: I902d2f51a3c8d6bd0dc4aabe1b192a15d7b788e8
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/72747
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
It's useful for auditing purposes if modulewrapper can print information
about the FIPS module within it. Also, we have a function,
`CRYPTO_has_asm`, which reports whether assembly code is enabled or not.
But that function wasn't implemented within the FIPS module and thus
it reported the condition of libcrypto instead. This change moves it into
the FIPS module so that it reports the condition there, which is what we
care about.
Change-Id: I66ac8936c6d8dd7b5260ec7a68405d58a63990fb
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/72327
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: Adam Langley <agl@google.com>
Having the files named .c but included causes a ton of problems with
build systems. Many of our build systems care about three categories of
files:
- public headers, available to downstream targets
- source files, each of which is compiled as a compilation unit
- internal headers, not available to downstream targets
There is usually a check, in Bazel called layering_check that enforces
source files only include headers that are declared somewhere
appropriate. The bcm.c fragments, under this classification, are
internal headers.
However, in both GN and Bazel, internal headers and sources
both go in the source list. They are distinguished only by file
extension. When FIPS fragments have a .c file extension, they are
misinterpreted as source files, and many things break.
Rename them. Either .h and .inc would be sufficient. Because we had to
disable Bazel's parse_headers feature, there is no difference (AFAICT)
in their handling. Also, these files actually pass the parse_headers
feature, even though they don't have an include guard. Still, the tech
of the style guide suggests that .inc is probably the better file
extension.
https://google.github.io/styleguide/cppguide.html#Self_contained_Headers
I used .c.inc rather than plain .inc so that we can easily
rename them back to .c when we solve https://crbug.com/362530616.
Note that, as .inc is not as common of a file extension, people working
on BoringSSL may need to reconfigure their editors to map .inc to C/C++.
Update-Note: Some downstream builds have been working around this by
building the fragments individually and excluding bcm.c. This change
will break those workarounds but also remove the need for it. It should
now be consistently possible to build BoringSSL without modifying the
file list.
Bug: 362664827
Change-Id: I933115c37843317a066e24a1092728c9afce35f5
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70689
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
This CL adjusts the libcrypto <-> BCM ECDSA interface. Previously, we
used ECDSA_do_sign and ECDSA_do_verify. This meant we have an allocated
BIGNUM-based type (ECDSA_SIG) at the boundary.
Instead use the fixed-width P1363 format at the boundary, which is nice
and straightforward. For now, I haven't exported it out of anything,
though we do have some things (Channel ID, WebCrypto) which actually
want this format, so that may be worth revisiting later.
Bug: 42290602
Change-Id: Ifbe0600fd23addc5f05141d18baad21a669ceca8
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/66829
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
This fixes b/342634459.
enums are weird. They're neither tight sum types, nor ints with
designated values but something in between.
By default (i.e. if you do not say `enum Foo : int`, which isn't in C
until very new versions), an enum's range of valid values is the
smallest hypothetical-bit-width signed or unsigned integer that can fit
all the values. So, the following enum can only hold 0, 1, 2, or 3, and
all values outside that range are UB.
enum E {
A = 0,
B = 2,
}
Meanwhile, enum is signed and can hold values -2, -1, 0, 1:
enum E {
A = -1,
B = 1,
}
This is incredibly bizarre. This has two consequences. First, clang
emits a warning like the following:
.../boringssl/crypto/fipsmodule/self_check/fips.c:75:15: error: result of comparison of unsigned enum expression < 0 is always false [-Werror,-Wtautological-unsigned-enum-zero
-compare]
75 | if (counter < 0 || counter > fips_counter_max) {
| ~~~~~~~ ^ ~
Second, this loop over enum values in the unit test trips UBSan.
[----------] 1 test from CryptoTest
[ RUN ] CryptoTest.FIPSCountersEVP_AEAD
.../boringssl/crypto/crypto_test.cc:51:8: runtime error: load of value 4, which is not a valid value for type 'fips_counter_t'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /usr/local/google/home/davidben/boringssl/crypto/crypto_test.cc:51:8
To avoid this, just do our arithemetic in integer space and only move to
enums at the edges.
Change-Id: Icbd0e41604ce2aa67be8d394b03c7de50062199c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/68768
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Reviewed-by: Adam Langley <agl@google.com>
OpenSSL added a similar helper function. It's very, very common for us
to malloc something an then zero it. This saves some effort. Also
replace some more malloc + memcpy pairs with memdup.
Change-Id: I1e765c8774a0d15742827c39a1f16df9748ef247
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/63345
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Disable blinding for boringssl_self_test_rsa() to avoid an entropy draw like
the 'k' value for ECDSA is fixed to avoid an entropy draw in boringssl_self_test_ecc().
The boringssl_self_test_rsa() use entropy to generate the blinding factor and
the inverse of blinding factor. Running boringssl_self_test_rsa() from init stage of OS
on some devices as the kernel's entropy pool is not yet initialized, causing the process
to block for seconds.
Bug: None
Change-Id: I4c1119c9950553eec030bedf36ec22ab41088f20
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55545
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
We need a function that returns a version that links to a certificate.
Previously we have used the git hash as the version of our modules but
the source cannot contain its own hash. Thus this change defines a new
format for FIPS module versions which will be filled in once we're ready
to define a version.
Change-Id: Ie4641945119106bc47e8da94ed8a45a86abb6f92
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51986
Reviewed-by: David Benjamin <davidben@google.com>
FIPS validation requires showing that the continuous and start-up tests
are effective by breaking them. Traditionally BoringSSL used #defines
that tweaked the expected values. However, 140-3 now requires that the
inputs be changed, not the expected outputs.
Also, the number of tests is going to increase. Since slower platforms
already took too long to compile BoringSSL n times (once for each test
to break) we want something faster too.
Therefore all the known-answer tests (KATs) are changed such that a Go
program can find and replace the input value in order to break them.
Thus we only need to recompile once to disable the integrity test.
The runtime tests still need a #define to break, but that #define is now
put in a header file so that only the module need be recompiled, not
everything as in the previous system.
Change-Id: Ib621198e6ad02253e29af0ccd978e3c3830ad54c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51329
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
AS10.20 requires that the self-test for the integrity algorithm pass
before the integrity check itself. IG 10.3.A requires an HMAC self-test
now. Therefore run these tests before the integrity check.
Since we also need the ability to run all self-tests, both SHA
self-tests and the HMAC test are run again when running self-tests.
I'm assuming that they're so fast that it doesn't matter.
Change-Id: I6b23b6fd3cb6107edd7420bc8680780719bd41d2
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51328
Reviewed-by: David Benjamin <davidben@google.com>
The provision of FIPS that allowed the tests to be skipped based on a
flag-file has been removed in 140-3. Therefore we expect to run the fast
KATs on start-up, but to defer to slower ones until the functionality in
question is first used. So this change splits off the fast KATs and
removes support for skipping KATs based on a flag-file.
Change-Id: Ib24cb1739cfef93e4a1349d786a0257ee1083cfb
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51326
Reviewed-by: David Benjamin <davidben@google.com>
There are a few places where it is useful to run ECDSA with a specified
nonce:
- An ECDSA KAT in the module self-check
- Unit tests for particular test vectors
- Fuzzing the implementation (requested by the cryptofuzz project)
This replaces the fixed_k machinery with a separate function. Although
they are effectively the same, I've used two different functions.
One is internal and only used in the module self-check. The other is
exported for unit tests and cryptofuzz but marked with a for_testing.
(Chromium's presubmits flag uses of "for_testing" functions outside of
unit tests. The KAT version isn't in a test per se, so it's a separate
function.)
Bug: 391
Change-Id: I0f764d89bf0ac2081307e1079623d508fb0f2df7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45867
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
test_fips probably needs to exercise everything that we have self-tests
for.
(The following change will eliminate the duplication of the code to
create the FFDH group. For reasons, that can't be done in this change.)
Change-Id: Ia72064db77381e7cf396a34b4723b2607f26f00b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45404
Reviewed-by: Adam Langley <alangley@gmail.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
David Benjamin