Change-Id: I4f349d2215c9cdea947f2e982b1601d022744c98
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70167
Auto-Submit: David Benjamin <[email protected]>
Reviewed-by: Bob Beck <[email protected]>
Commit-Queue: Bob Beck <[email protected]>

Section 5.9 of RFC 9147 changes the TLS 1.3 key schedule for DTLS 1.3 by
changing the label prefix from "tls13 " to "dtls13".

Bug: 715
Change-Id: Ia3c84d27145a225d27dd5bc082361273ce7e6dbc
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70007
Reviewed-by: Bob Beck <[email protected]>
Auto-Submit: Nick Harper <[email protected]>
Commit-Queue: Bob Beck <[email protected]>

The comment says something about adding assembly for other ISAs, but it
seems most ISAs don't actually have double-wide division instructions.
(Despite this, the division-based BN_MONT_CTX_set still seems to beat
the Montgomery one on Arm. Less drastically than before
https://boringssl-review.googlesource.com/c/boringssl/+/60686, but
division still makes things faster.)

Also update the bug links post LLVM's GitHub migration. Finding the
corresponding GitHub issue is not always trivial.

Bug: 358687140
Change-Id: Iafb5118461a2c09c66840a44fbd257320a8d98b4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70168
Auto-Submit: David Benjamin <[email protected]>
Reviewed-by: Bob Beck <[email protected]>
Commit-Queue: David Benjamin <[email protected]>

This is part of the public API and should be documented as such.

Bug: 358687140
Change-Id: I1d736f39c5cff18f7c8e3ff8207a4b60ee96cd18
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70169
Commit-Queue: David Benjamin <[email protected]>
Reviewed-by: Bob Beck <[email protected]>

After spending a while trying to divine where all the bounds came from,
and coming up with some of the messy proofs for why it works, I found
this exact algorithm in Knuth, Volume 2, with... different messy proofs.
Sadly, this algorithm seems to just be messy. Cite it as reference
rather than trying to repeat it in code.

As part of this, update the discussion on branches. That was added in
https://boringssl-review.googlesource.com/c/boringssl/+/9105, back when
BN_div was used on secret inputs. It no longer is and, back then, the
function still wasn't constant-time anyway.

We could, in principle, restore the special cases now. But this would be
more complicated and diverge from Knuth's formulation, so let's just
keep it simple. (Although it might actually be a hair faster. We care
about this function to compute R^2 mod n, and the special case would
save an extra iteration through the loop. Though I think that
optimization could actually be restored with much, much less code than
OpenSSL originally did it. Probably not worth the fuss.)

Subsequent CLs will clean this code up in reference to Knuth's
formulation.

Bug: 358687140
Change-Id: I56da99c560b845f1736ab86edc79b8e711890fe3
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70170
Reviewed-by: Bob Beck <[email protected]>
Commit-Queue: David Benjamin <[email protected]>

82f9853 replaced ssl_seal_align_prefix_len with two functions,
tls_seal_align_prefix_len and dtls_seal_align_prefix_len. This change
updates documentation that referred to the old ssl_seal_align_prefix_len
function to refer to the correct function.

Change-Id: Ieb8891eff03efc3d894aa56729ae6e47f4be3288
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70207
Commit-Queue: Bob Beck <[email protected]>
Reviewed-by: Bob Beck <[email protected]>
Auto-Submit: Nick Harper <[email protected]>

By having the caller provide the sequence number and the record header
length, the decrypt function doesn't need to know anything about the
format of the record header.

Change-Id: If3389e79d6823c63c884bb9ddb764fa68223e765
Bug: 715
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/69948
Commit-Queue: Bob Beck <[email protected]>
Reviewed-by: Bob Beck <[email protected]>

The length of the DTLS record header isn't a constant - update variables
and functions to match that reality.

Change-Id: Ib6abc3af98a15994c72a22b8fdd8e230e87b966a
Bug: 715
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/69949
Reviewed-by: Bob Beck <[email protected]>
Commit-Queue: Bob Beck <[email protected]>

This was just checking the bn_correct_top invariant. But since we got
rid of the bn_correct_top invariant and dynamically compute
bn_minimal_width anyway, bn_minimal_width will always be computed such
that the check succeeds.

Bug: 358687140
Change-Id: Idc1abbc46c38d47f319ee5835a5a601a8a3d9c0e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70171
Commit-Queue: David Benjamin <[email protected]>
Reviewed-by: Bob Beck <[email protected]>

Also add an assert for the invariant it is maintaining.

Bug: 358687140
Change-Id: I3bcb9838198735b6f42e4f732b00e0fc990c5ffd
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70172
Reviewed-by: Bob Beck <[email protected]>
Commit-Queue: David Benjamin <[email protected]>

Bug: 358687140
Change-Id: Ifbc8bf34a93543c6035bfee29d915818ef2875db
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70173
Reviewed-by: Bob Beck <[email protected]>
Commit-Queue: David Benjamin <[email protected]>

Although Knuth iterates the index forwards, it makes more sense for us
to do it backwards because he numbers words big-endian and we use
little-endian. Ultimately each loop iteration i is about computing
res->d[i] in the quotient.

Once we do that, we can assert some pointer invariants. Subsequent CLs
will remove some of the pointers. The compiler can figure it out and
they make it harder to even confirm we stay within bounds.

Bug: 358687140
Change-Id: I159489fafb8b071725c0e49a6fea66d6006f5a78
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70174
Commit-Queue: David Benjamin <[email protected]>
Reviewed-by: Bob Beck <[email protected]>

We can use bn_resize_words, which zeros the extra words and updates the
width in one step. Also clarify what this is achieving. It's to
establish a bunch of invariants that the loop cares about.

Bug: 358687140
Change-Id: Id78e81bc08a1ca506b5d6ef6b01936f860fddd86
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70175
Commit-Queue: David Benjamin <[email protected]>
Reviewed-by: Bob Beck <[email protected]>

It's much clearer if we just reference res->d[i] directly. Note that the
removed res->neg clearing is a no-op because bn_set_minimal_width fills
the value in anyway. It was also impossible for res->width to be zero
because of the resizing step (see the bn_resize_words call). Even if it
were possible for it to be zero, that would mean the loop doesn't run,
and the resp pointer was only read outside the loop. So we can treat the
function as if it unconditionally decremented resp.

Bug: 358687140
Change-Id: I5e2d4ca03fd808cacd4f4647843a7894bf7a2f05
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70176
Commit-Queue: David Benjamin <[email protected]>
Reviewed-by: Bob Beck <[email protected]>

We allocated two more words than were needed. Sizing it more than
the width is suspicious and with the confusing pointer indirection
removed, it becomes clear that, throughout the entire function, we only
ever write to indices 0 through loop-2. That is, it should be sized for
loop-1.

Bug: 358687140
Change-Id: I9e33ce7d2c4e5b6fae9ec59bdee34b2d3480addc
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70177
Commit-Queue: David Benjamin <[email protected]>
Reviewed-by: Bob Beck <[email protected]>

According to Intel's documentation, if not all the AVX512 bits in XCR0
are set (meaning that the operating system doesn't fully support
AVX512), then no AVX512 feature can be used, even on xmm and ymm
registers.  Make OPENSSL_cpuid_setup() correctly handle this case by
clearing all the AVX512 feature bits when this situation is detected.

Change-Id: I2774dbc28bfbac1196e405c0920ba2909e7f0eb3
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/68907
Reviewed-by: David Benjamin <[email protected]>
Reviewed-by: Bob Beck <[email protected]>
Commit-Queue: Adam Langley <[email protected]>
Auto-Submit: Eric Biggers <[email protected]>

Change-Id: Icdd1192a24d3bdc62198ca9243f4bbf9f64f3c29
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70287
Reviewed-by: Adam Langley <[email protected]>
Commit-Queue: Adam Langley <[email protected]>

This is necessary to avoid the following error when building with MSVC
using the latest STL:

    error C2039: 'string': is not a member of 'std'

Change-Id: I4c926f7a020c2e920bcc78667bc04951cdab4cf1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70272
Reviewed-by: David Benjamin <[email protected]>
Commit-Queue: David Benjamin <[email protected]>

With reference to Knuth.

I'm not sure what the comment about overflowing when q = 0 is about. The
bounds in "the first part of the loop" imply that we've either computed
q+1 or q and the borrow check exactly captures the q+1 case.

Moreover, this addition is expected to *always* overflow. It cancels out
the underflow from subtracting too many.

Bug: 358687140
Change-Id: I24bf8c9c37dcd1145667d7f0e8457c0e63e8783c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70178
Reviewed-by: Bob Beck <[email protected]>
Commit-Queue: David Benjamin <[email protected]>

These files were derived from CAVP, which used DOS line endings. Several
environments will automatically convert line endings and this leads to a
mismatch if strictly comparing against the offical FIPS source
distribution tarballs.

Thus convert these files to UNIX line endings, matching the rest of the
repository.

Change-Id: If0f5835108a6b26bba5de0b6b950a69a4faa1410
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70307
Auto-Submit: Adam Langley <[email protected]>
Commit-Queue: Adam Langley <[email protected]>
Commit-Queue: David Benjamin <[email protected]>
Reviewed-by: David Benjamin <[email protected]>

This is needed to cover the 512-bit code path in the new AES-GCM code.

Change-Id: I1a0eeb7cd6f330d82577159a1e0055f2ff6ec4ce
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70247
Commit-Queue: David Benjamin <[email protected]>
Reviewed-by: David Benjamin <[email protected]>

This extra word was allocated so that the fixup portion of quotient
estimation could read from wnump[-2] without checking if div_n > 1. This
was actually subtle because the value it got back was wrong. It just
didn't matter because the loop was a no-op.

As a result of all this, all the indices into snum were off, and the
remainder needed to be shifted down by one word to compensate.

Really, if div_n > 1, we could just call BN_div_word, but the calling
conventions are different enough that it didn't seem worth the effort.

Bug: 358687140
Change-Id: Id694a33003f51536ee836a5bdb75ff8006b11a51
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70179
Reviewed-by: Bob Beck <[email protected]>
Commit-Queue: David Benjamin <[email protected]>

The DTLS 1.3 record header is formatted differently than the old record
header, but the code to read/process a DTLS record mixes record header
parsing with other record processing code. This change provides a clear
delineation between processing the record header and processing the
record, which will assist in adding support for the DTLS 1.3 record
header.

Bug: 715
Change-Id: I13a0bb5c184e79b88f064e9ac8ecbc82eb56750a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/69950
Commit-Queue: Bob Beck <[email protected]>
Reviewed-by: Bob Beck <[email protected]>

Expressing everything in terms of i makes it at lot easier to tell what
words are being written to where, and convince oneself that everything
stays in bounds. I kept a wnum variable in there since it's used so
frequently but added a note about the bounds. In a higher-level
language, wnum would be a slice of width div_n + 1.

Bug: 358687140
Change-Id: Iae39b1915f80008ab5ed91e1e7fc5cd1349e8c1e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70227
Reviewed-by: Bob Beck <[email protected]>
Commit-Queue: David Benjamin <[email protected]>

Tidy up the setup. Also we can simplify all the sign management. If snum
and sdiv just preserve the sign bits of numerator and denominator, the
remainder will have the correct sign from the start.

(The original code called BN_cmp and BN_add in places, which is
sensitive to the sign.)

Fixed: 358687140
Change-Id: I2d5f952814c9910552330b18462796ffc3fe5dab
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70228
Reviewed-by: Bob Beck <[email protected]>
Commit-Queue: David Benjamin <[email protected]>

Bug: 342657857
Test: Validated pulling & using
Change-Id: I5b6dda58b21cf237e66064a7da2fdc8003fa047b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70273
Reviewed-by: David Benjamin <[email protected]>
Commit-Queue: David Benjamin <[email protected]>

This change implements FIPS 204.

Change-Id: I0043850767c93cc7235a15c701798fee6e1af1bf
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/69987
Reviewed-by: Bob Beck <[email protected]>
Commit-Queue: Adam Langley <[email protected]>
Reviewed-by: David Benjamin <[email protected]>

Bug: 715
Change-Id: I69c82eed41946da404fb13129aa790d61ec0fb78
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/69689
Auto-Submit: Nick Harper <[email protected]>
Reviewed-by: Bob Beck <[email protected]>
Commit-Queue: Bob Beck <[email protected]>

Now that ML-DSA has been standardized, code should be using
<openssl/mldsa.h> not <openssl/experimental/dilithium.h>.

This marks the dilithium functions as OPENSSL_DEPRECATED
and removes the dilithium speed from bssl.

The code remains in the library for a short while to allow
anyone who used it to transition to mldsa.

Change-Id: I5c9fab376185dc045d7d588eff4b6a626527aff5
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70329
Reviewed-by: David Benjamin <[email protected]>
Commit-Queue: David Benjamin <[email protected]>
Auto-Submit: Bob Beck <[email protected]>

This change implements FIPS 203.

This marks the first use of C++ in libcrypto. If you can't compile C++
in this context, please reach out to boringssl@ and filter out the .cc
files for now.

This also makes marshaling a private key an internal function and,
instead, exposes the seed from the generation process and a function to
calculate a private key from a seed. Seeds are significantly smaller
than NIST's format for private keys and don't require validation.

On an M1 Pro:

Did 22320 Kyber generate + decap operations in 1001900us (22277.7 ops/sec)
Did 39000 Kyber parse + encap operations in 1005523us (38785.8 ops/sec)
Did 22608 ML-KEM-768 generate + decap operations in 1010509us (22372.9 ops/sec)
Did 44000 ML-KEM-768 parse + encap operations in 1013729us (43404.1 ops/sec)
Did 15410 ML-KEM-1024 generate + decap operations in 1011500us (15234.8 ops/sec)
Did 29000 ML-KEM-1024 parse + encap operations in 1003919us (28886.8 ops/sec)

Change-Id: Ib563bd4d45228237b55cedbe7d7fdf0f0221a3cc
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/69928
Reviewed-by: David Benjamin <[email protected]>
Commit-Queue: Adam Langley <[email protected]>

Change-Id: I65d66a2334318fd47e3e045511c21eb625b38eaa
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70348
Reviewed-by: David Benjamin <[email protected]>
Commit-Queue: Adam Langley <[email protected]>

There are two ways to save an ML-DSA or ML-KEM private key:

NIST specifies a partial serialization of the contents of the keys and this takes up several kilobytes.

But one can also save the seed that the key was generated from and simply regenerate the private key as needed.

* The seed is approximately two orders of magnitude smaller.
* It is fast to expand a private key from a seed.
* The NIST format requires validating several aspects of the partially expanded private key.

Because of this, seeds seem clearly better and having two different
serializations in the API is a bit weird when currently neither of them
are used anywhere.

Thus this change emphasizes using seeds to save private keys and moves
the marshalling function for the NIST format into the internal API.
ML-KEM already follows this pattern, although saving the seed is still
optional there because ephemeral keys are a major use case for ML-KEM.

Change-Id: I439224e745ad8747d26f57288f1d503593e0e52c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70407
Commit-Queue: Adam Langley <[email protected]>
Reviewed-by: David Benjamin <[email protected]>

Change-Id: I9407b2d4e754ef6cf8abf1631fe904ac7cd7cbc7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70410
Auto-Submit: Bob Beck <[email protected]>
Commit-Queue: Adam Langley <[email protected]>
Reviewed-by: Adam Langley <[email protected]>

Bug: 715
Change-Id: Ibb8ae0c152477eb5aa035582fac06368ef3c7c1e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70347
Auto-Submit: Nick Harper <[email protected]>
Reviewed-by: David Benjamin <[email protected]>
Commit-Queue: David Benjamin <[email protected]>

This is a bit of a mess because we actually build each fuzzer as a
separate target, but ah well. Migrating to FuzzTest will resolve that.

Bug: 42290412
Change-Id: Ia32287ce8b5947a339e966df9e55e2afabed08c1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70427
Reviewed-by: Bob Beck <[email protected]>
Commit-Queue: David Benjamin <[email protected]>
Auto-Submit: David Benjamin <[email protected]>

Change-Id: Ie2ae13569a9000ecc6143ab74b69d4f886e27789
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70447
Reviewed-by: David Benjamin <[email protected]>
Auto-Submit: Adam Langley <[email protected]>
Commit-Queue: Adam Langley <[email protected]>

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 <[email protected]>
Commit-Queue: Bob Beck <[email protected]>
Auto-Submit: David Benjamin <[email protected]>

This is in preparation for adding code to parse the tls_flags extension.

Change-Id: Ia82e7cd6a5d76663cfc817eb16271dd51bbfa26d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70487
Commit-Queue: Bob Beck <[email protected]>
Auto-Submit: David Benjamin <[email protected]>
Reviewed-by: Bob Beck <[email protected]>

The macros will participate in symbol prefixing. Not that symbol
prefixing particularly works, but let's be consistent.

Change-Id: I54043a849682e2ba2b8576b59241035e4d4effbe
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70387
Commit-Queue: David Benjamin <[email protected]>
Auto-Submit: David Benjamin <[email protected]>
Reviewed-by: Bob Beck <[email protected]>

This appears to perhaps have been a pasto and is confusing
to consumers of this API.

You share the same size secret with any mlkem

Change-Id: I6ddfa21b4f8d293f990064a2a54cda9ba6119d5a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70527
Commit-Queue: Adam Langley <[email protected]>
Auto-Submit: Bob Beck <[email protected]>
Reviewed-by: Adam Langley <[email protected]>
Commit-Queue: Bob Beck <[email protected]>

In principle this should be derivable from lib.rs directly, but Rust
made this surprisingly difficult, so we'll just do it with wildcards.

Bug: 42290412
Change-Id: I3153613bdddf62eaa0e752a4a24192e2c484a95c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70428
Commit-Queue: David Benjamin <[email protected]>
Reviewed-by: Bob Beck <[email protected]>

Change-Id: Ic13cfb17bc7be9aa7c25dec1b365dd092a5e3835
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70507
Reviewed-by: David Benjamin <[email protected]>
Commit-Queue: Adam Langley <[email protected]>

Change-Id: I2f3ced7723925542d2dbf0cff1a458b43c7bf48e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70587
Commit-Queue: Adam Langley <[email protected]>
Auto-Submit: David Benjamin <[email protected]>
Reviewed-by: Adam Langley <[email protected]>

Recommendation from Chrome security folks was to use the Chromium
process for security bugs. Also crbug.com/boringssl links work now.

Also since I guess the "bug tracker" is now an "issue tracker", I
suppose we can say "issue". Meh.

Change-Id: I6c4bb81165989b3ec5f98041e4c6c2cdf52fca2f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70588
Auto-Submit: David Benjamin <[email protected]>
Commit-Queue: Adam Langley <[email protected]>
Reviewed-by: Adam Langley <[email protected]>
Commit-Queue: David Benjamin <[email protected]>

ML-KEM is now finalized, so uses of Kyber should migrate to ML-KEM. This
adds the new codepoint for TLS, X25519MLKEM768 from
draft-kwiatkowski-tls-ecdhe-mlkem-01.

One detail to call out: where the Kyber hybrid put X25519 first, this
one places MLKEM768 first. Section 3 of the draft discusses why.

Bug: 40910498
Change-Id: I18862cd5d25d6ab6c4b38514e8333684dc5e3778
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70547
Reviewed-by: Adam Langley <[email protected]>
Commit-Queue: David Benjamin <[email protected]>

Bug: 42290412
Change-Id: Iac2641de0d0d7af79fd58dc7279ce21e54f6a023
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70429
Reviewed-by: Bob Beck <[email protected]>
Commit-Queue: David Benjamin <[email protected]>

Change-Id: Id8f6603e30d5a4289667f1089526bbb2a85543ac
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70607
Reviewed-by: Adam Langley <[email protected]>
Auto-Submit: David Benjamin <[email protected]>
Commit-Queue: Adam Langley <[email protected]>

Adding a C++ file into libcrypto triggered some more Bazel workarounds
in our build. For whatever reason, that's now being passed a "frozen"
list, so we cannot mutate the values.

This isn't sufficient to fix it, as we're also running into issues with
aes/aes.c being an internal "header". To fix that, I think we have to
bite the bullet and finally rename the FIPS fragments to .h, reflecting
the fact that they are intended to be #included.

Also the new Bazel seems to have a different MODULE.bazel.lock format,
so pick up that update.

Bug: 362664827
Change-Id: Ibf80fa389e0e1fd2b6f1ab110f0dea78a2a1a89b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70627
Commit-Queue: Adam Langley <[email protected]>
Auto-Submit: David Benjamin <[email protected]>
Reviewed-by: Adam Langley <[email protected]>

Add helper functions that check the AVX512BW, AVX512VL, VAES, and
VPCLMULQDQ feature bits in the CPU capability words.  Also, make sure
that OPENSSL_cpuid_setup() clears VAES and VPCLMULQDQ when they are
unsupported due to the operating system not supporting ymm registers.

Change-Id: I2d672556acc269ef09ab6f5e080d37cb9831e7ce
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/68908
Commit-Queue: Bob Beck <[email protected]>
Reviewed-by: Bob Beck <[email protected]>
Reviewed-by: David Benjamin <[email protected]>
Auto-Submit: Eric Biggers <[email protected]>

Add a CPU capability bit that identifies older Intel CPUs that support
AVX512 but where using zmm registers should be avoided.  This will be
used to select code that uses ymm registers instead.

Change-Id: I6bedc913960d0da3c5f3aae315c81f67da1667b4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/68909
Reviewed-by: David Benjamin <[email protected]>
Reviewed-by: Bob Beck <[email protected]>
Commit-Queue: Bob Beck <[email protected]>

For some reason, Bazel previously wasn't compiling our headers
standalone and now is. Doing so is now tripping a whole series of bugs
and deficiencies in Bazel that I'm still trying to figure out, but this
issue is at least legitimate.

Bug: 362664827
Change-Id: I3ca953a14ac36fa283fefcb42ff7805993247785
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70647
Auto-Submit: David Benjamin <[email protected]>
Reviewed-by: Adam Langley <[email protected]>
Commit-Queue: Adam Langley <[email protected]>

Bazel has a parse_headers feature which expects headers to be
independently buildable. While a nice way to partially enforce IWYU,
it's broken. See bazelbuild/bazel#23460.

Until the Bazel issue is fixed, we'll need to turn that off. In
particular, after bazelbuild/bazel#22369,
parse_headers is no longer silently inactive.

This does not remove the need to do something about the fips_fragment
filenames. Those come from the layering_check feature, rather than the
parse_headers feature. We also have a number of headers that don't
actually work standalone and, by the style guide, probably should be
named .inc:
https://google.github.io/styleguide/cppguide.html#Self_contained_Headers

But since the feature does not work anyway, just turn it off for now.

Bug: 362664827
Change-Id: I9646d722a59f92be81848cf5a586738cc5f3dac4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70687
Reviewed-by: Bob Beck <[email protected]>
Commit-Queue: Bob Beck <[email protected]>
Auto-Submit: David Benjamin <[email protected]>

These would be caught by parse_headers, if we didn't have to disable
parse_headers entirely.

Bug: 362664827
Change-Id: Ia7c10cae3fd082eb4b50dd9fad79d4631f95edea
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70688
Reviewed-by: Bob Beck <[email protected]>
Commit-Queue: Bob Beck <[email protected]>

To work around Bazel's bugs around mixed C/C++ targets
(bazelbuild/bazel#22041), we automatically
split all of our targets in two.

When we did this, we originally pulled the C files into their own
target. This had the side effect of building assembly files with the C
files instead of with the C++ files. In principle, this does not matter,
but Bazel likes to turn targets into shared libraries, and our assembly
files still contain a couple references to OPENSSL_ia32cap_P (see
https://crbug.com/42290548). Those references rely on OPENSSL_ia32cap_P
being a hidden symbol, and statically linked with the assembly files.

Pull the C++ out instead, to avoid this. Once
https://crbug.com/42290548 is done, either will work, but this is
needed for now.

Bug: 362664827
Change-Id: Icb929d194ee2311707fe1a0bb27ea0ccaf96a510
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70690
Reviewed-by: Bob Beck <[email protected]>
Commit-Queue: David Benjamin <[email protected]>

Also condition all the tools the Bazel builders won't need. (Perl and Go
aren't build dependencies anymore.) Given we've broken this build a
couple times, it's clear we need to just put it on CI.

This will be paired with a new recipe in the recipes repo.

Bug: 42290610
Change-Id: I90a4b376849dee9dde3dfcd12c8df60db1b0120c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70747
Commit-Queue: David Benjamin <[email protected]>
Reviewed-by: Bob Beck <[email protected]>

BCM uses only passive entropy, in that from BCM's
point of view, entropy is requested and obtained
from an external source, and fed to BCM's CTR_DRBG
as required. With this change entropy is always gathered
in an OS specific manner outside of BCM by libcrypto,
while the CTR_DRBG remains in BCM using that entropy.

BCM functions (but not yet the tests!) now no longer
use the public RAND_bytes function, but instead use
BCM_rand_bytes which uses the BCM module CTR_DRBG.
BCM_rand_bytes is in turn used by libcrypto to implement
the public RAND_bytes function. All public RAND_
functions are now implemented in rand_extra.

As part of this two new headers are introduced to
start defining the interface boundary between libcrypto
and BCM.

crypto/bcm_support.h <- Functions implemented by libcrypto
and used by bcm

fipsmodule/bcm_interface.h <- Functions implemented by
bcm and used by libcrypto.

Bug: 723

Change-Id: I6b618dfe4df257f67971e88cbd79126c837e21d6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/68147
Reviewed-by: David Benjamin <[email protected]>
Commit-Queue: Bob Beck <[email protected]>

This moves fork detection itself back into libcrypto.

BCM itself retains only the API to access the generation number
to know if stiring in more entropy is needed because a fork
happened.

Bug: 723
Change-Id: I9b38440e7243119de97f9c4653f0e91d71107501
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/68967
Reviewed-by: David Benjamin <[email protected]>
Commit-Queue: David Benjamin <[email protected]>

aes/internal.h got removed on accident in some reshuffling. All this
also really should be under the bcm target, rather than the crypto
target, but we'll sort that out later.

Also rand_test.cc got duplicated.

Change-Id: If77f1ff6149a764ccf96073166a5520b284b2dc7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70768
Reviewed-by: Bob Beck <[email protected]>
Commit-Queue: David Benjamin <[email protected]>

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 <[email protected]>
Commit-Queue: Bob Beck <[email protected]>

Compatibility mode is disabled in DTLS 1.3, but
https://boringssl-review.googlesource.com/c/boringssl/+/69947 missed a
spot where the test runner still sends a ChangeCipherSpec message.

Bug: 715
Change-Id: Ia7dda19e99fc427fb1ba18542b6ed6b4281656c0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70668
Reviewed-by: David Benjamin <[email protected]>
Commit-Queue: David Benjamin <[email protected]>
Auto-Submit: Nick Harper <[email protected]>

This aligns with openssl/openssl#6173 from
upstream OpenSSL. As part of this, I had to fix PEM_def_callback (which
is different in us vs BoringSSL) to use -1 as the error value, not 0.
Otherwise errors get misinterpreted as empty strings.

As part of this, make sure all the functions being fixed are covered by
tests.

Fixed: 362788352
Change-Id: I2b5071534c77944d473580fda98d23ae3b54e2d5
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70787
Auto-Submit: David Benjamin <[email protected]>
Commit-Queue: Bob Beck <[email protected]>
Reviewed-by: Bob Beck <[email protected]>

Bug: 715
Change-Id: I87f8a08e9a2258dede21cffb1cfde5802608d30d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70667
Reviewed-by: Bob Beck <[email protected]>
Commit-Queue: Bob Beck <[email protected]>

It used to be hand-written in assembly, so we tested it explicitly. But
it's now a thin wrapper over mul_mont. Remove the ABI tests (no longer
necessary) and convert the FromMont test vectors to MulMont.

Change-Id: I94696ac7d1f548072702a717183dec8001a47ecb
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70807
Auto-Submit: David Benjamin <[email protected]>
Commit-Queue: Bob Beck <[email protected]>
Reviewed-by: Bob Beck <[email protected]>

Looks like this landed by mistake

Change-Id: Ifbe775d172c0c6c9df2e656097c986d6f7bd55a3
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70827
Auto-Submit: David Benjamin <[email protected]>
Commit-Queue: Bob Beck <[email protected]>
Reviewed-by: Bob Beck <[email protected]>

If we have code like this, the compiler will not currently dedup the
capability check:

  void foo() {
    if (CRYPTO_is_AVX2_capable()) {
      foo_avx2();
    } else {
      foo_nohw();
    }
  }

  foo();
  foo();
  foo();

This is because a pure function may still inspect some globals and the
compiler doesn't know that foo_avx2() does not change the output of
CRYPTO_is_AVX2_capable(). We'd really like that to turn into:

  if (CRYPTO_is_AVX2_capable()) {
    foo_avx2();
    foo_avx2();
    foo_avx2();
  } else {
    foo_nohw();
    foo_nohw();
    foo_nohw();
  }

Strictly speaking, these functions are not const because they inspect a
global variable and a test might modify
OPENSSL_get_armcap_pointer_for_test(). However, that internal, test-only
function is already documented as needing to be resolved before any
other BoringSSL function is called. When that rule is heeded, const is
fine.

Bug: 42290548
Change-Id: I1737fd00d443e8854294dcc8446b7b0aa38ffc76
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70828
Reviewed-by: Bob Beck <[email protected]>
Commit-Queue: David Benjamin <[email protected]>

Bug: 42290548
Change-Id: I16c456fe04b5582210cb2915c5b3730ba5dc2f58
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70808
Commit-Queue: David Benjamin <[email protected]>
Reviewed-by: Bob Beck <[email protected]>

CPU dispatch is now all moved out of assembly.

Fixed: 42290548
Change-Id: Icbe5053255d4aa76406b5303ba515ec38d42cb0d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70809
Commit-Queue: David Benjamin <[email protected]>
Reviewed-by: Bob Beck <[email protected]>

These were getting by because bcm.c #includes everything together.

Change-Id: I1eb4aad891f0051c4f869202c6554f5864cd3a76
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70810
Reviewed-by: Bob Beck <[email protected]>
Commit-Queue: David Benjamin <[email protected]>

This'll eventually get reworked, but for now let's fix an IWYU issue by
just not depending on the structs.

Change-Id: Iacfe94dd5664975154006bd467fb8d29996a5d10
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70811
Reviewed-by: Bob Beck <[email protected]>
Commit-Queue: David Benjamin <[email protected]>

Some functions try to accomodate negative moduli by figuring out whether
to BN_add or BN_sub. Under the hood, those functions will do further
sign bits and comparisons to decide whether to BN_uadd or BN_usub. We
can just call the right one from the start.

Change-Id: I2e64b05522c93ee831f6d6e9f7d1380411fbb71b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70813
Reviewed-by: Bob Beck <[email protected]>
Commit-Queue: David Benjamin <[email protected]>

The inputs may be negative, it just ignores the sign bits.

Change-Id: Icaab47c159e45ab2e6fe2d770188767976aff521
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70812
Reviewed-by: Bob Beck <[email protected]>
Commit-Queue: David Benjamin <[email protected]>

I should have removed this when the OPENSSL_ia32cap_P dispatch was
removed from the ChaCha20-Poly1305 assembly.

Bug: 42290548
Change-Id: Ic2ca0f6a897c27974833155935e42189fcbc1494
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70887
Commit-Queue: Bob Beck <[email protected]>
Commit-Queue: David Benjamin <[email protected]>
Auto-Submit: David Benjamin <[email protected]>
Reviewed-by: Bob Beck <[email protected]>

The numerator is per shard, but the denominator wasn't.

Change-Id: I1afd784038c51b8db51192b9a2b391073675e390
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70867
Reviewed-by: Bob Beck <[email protected]>
Commit-Queue: Bob Beck <[email protected]>
Auto-Submit: David Benjamin <[email protected]>

We can't have two source files with the same name, it seems, so since
crypto/spx/ will be going away, move its files out of the way so that
SLH-DSA can use those names.

Change-Id: Iedee8453cb77291eeff5ec33aa9836ea5d00d9a2
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70908
Auto-Submit: Adam Langley <[email protected]>
Reviewed-by: David Benjamin <[email protected]>
Commit-Queue: David Benjamin <[email protected]>

This isn't part of fips, so we move it to digest_extra

Change-Id: Ia9aeb81c314bdb34c6c9bd567242c90821f372d0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70707
Commit-Queue: Bob Beck <[email protected]>
Reviewed-by: David Benjamin <[email protected]>

libssl's error-handling is one of the most difficult things to get right
with this API. Leave some more notes, in case the reader does not know
what "error queue" means.

Change-Id: I91464ccdc12bf9e05ac9ed61930bc733244a9b36
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70929
Commit-Queue: Bob Beck <[email protected]>
Auto-Submit: David Benjamin <[email protected]>
Commit-Queue: David Benjamin <[email protected]>
Reviewed-by: Bob Beck <[email protected]>

We weren't testing all kinds of load-bearing checks in the TLS stack
around key shares. Fix this.

- Rework runner's KEM abstraction so that all the operations can get at
  config. That saves a lot of manual plumbing.

- Make the bad ECDH point something not on the curve. That's a bit more
  interesting of a test case.

- Test X25519 low order point rejection.

- Test truncating and extending the key share for all cases.

- Run X25519 tests in X25519-based hybrids as well.

Bug: 40910498
Change-Id: I93907dbb4bd4177252376c8efb859de6db3c4189
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70927
Commit-Queue: Bob Beck <[email protected]>
Auto-Submit: David Benjamin <[email protected]>
Reviewed-by: Bob Beck <[email protected]>

MD5 is no longer approved as part of fips, so we
move it to digest_extra.

Change-Id: I504c3d0d381cba72345c615209b99d4451886d96
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70727
Commit-Queue: David Benjamin <[email protected]>
Reviewed-by: David Benjamin <[email protected]>
Auto-Submit: Bob Beck <[email protected]>

pregenerate does not ensure that now unused files are gone.

crbug.com/365169741

Change-Id: I3876fe60576c27dac9571e0473d807fd8c86fb80
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/71007
Reviewed-by: David Benjamin <[email protected]>
Auto-Submit: Bob Beck <[email protected]>
Commit-Queue: Bob Beck <[email protected]>

Bug: chromium:365320414
Change-Id: I5d18425257dd87fe33a72dece194c2fe1977e51d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/71067
Reviewed-by: David Benjamin <[email protected]>
Auto-Submit: Adam Langley <[email protected]>
Commit-Queue: David Benjamin <[email protected]>

add a note about Google's implementations of quantum-safe crypto algorithms

Signed-off-by: PI <[email protected]>