Keeping it to X25519/Ed25519 for now, but arguably we could pick "raw"
options for most of our keys. The problem is just when there's a couple
different options. (ECPrivateKey or just the serialized scalar for EC
keys, compressed vs uncompressed points.)
Bug: 42290364
Change-Id: I1e1a0a3fa971f27a962946301091ebe11bac2725
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/81667
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
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>
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>
These seem to no longer be needed? Over time we have gotten a bit more
measured about enabling all of MSVC's warnings (MSVC is just not
designed to be used with -Wall), so I'm guessing that's what changed.
Change-Id: If71850136fb83841a423b63bdf65c2d546ba0223
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/77887
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@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>
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 <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
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 <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
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 <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: Bob Beck <bbe@google.com>
Now that we don't depend on external CRYPTO_library_init calls or the
static initializer to initialize CPU capabilities, we can drop a ton of
code.
This makes CRYPTO_library_init, and all its wrappers, into no-ops and
drops the (non-FIPS) static initializer. I've added an internal
OPENSSL_init_cpuid function for the places where the library actually
needs to initialize the CPU vector.
Note this slightly changes the default, previously
static-initializer-full build: previously, CRYPTO_library_init was a
no-op and we relied on the static initializer. Now we uniformly use
CRYPTO_once. This should be an atomic read in the steady state and
essentially free. We can restore the static initializer by default if
this ends up being a problem, but having only one mode is more
straightforward. This also avoids problems if an application calls into
BoringSSL during its own static initializer. Static initializers are not
coherently ordered.
Update-Note: The BORINGSSL_NO_STATIC_INITIALIZER build option and
CRYPTO_library_init are now unnecessary. Once updating past this
revision, those options can now be cleaned up from downstream projects.
Fixed: 40644931
Change-Id: Idc2e6ea7a73d6352e0360fd886c46d88dba3568c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/69508
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Kyber will be changing once the standardization of ML_KEM
is finalized by NIST.
Update-Note: The use of Kyber functions from
<openssl/experimental/kyber.h> will not compile unless the build
using them defines an appropriate preprocessor define.
As this interface will change once NIST finalizes the
standardization of ML_KEM. Users of this code must be aware, and be
prepared to make changes when this happens
Change-Id: I159bae38e58dd059b3fcccf69ae9f3d5fb03bd46
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/66868
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
This reverts commit a56407d27d.
On top of this it then makes changes to make dilithium work without
consuming excessive stack space..
This makes DILITHIUM_sign and DILITHIUM_generate_key and friends
fallible for malloc failures. It removes the abort() calls that
were previously present if CBB allocations did not work and
rolls them into the malloc failure case.
Change-Id: Ibcd70a98bb500c76df8885c0a7d06f8e9f5b18c3
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67027
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Reviewed-by: Guillaume Endignoux <guillaumee@google.com>
Reviewed-by: Sophie Schmieg <sschmieg@google.com>
Since we are saying this will die when standardized, let us
ensure users of this code from this location take notice
and action before using it.
We then selectively allow it in the speed tool and in our tests.
If we like this approach, I'll go back and apply it to kyber
(which will have some other fallout consequences to fix) but this
one should be painless right now.
This can also be applied to Dilithium when it comes back.
Future experimentals could be added in this manner.
Change-Id: Ie3b41cf16278868562ef1c8b28f2caed5e0e2dd1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/66887
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Although the round-3 specification has a variable-length output, the
final ML-KEM construction is expected to use a fixed 32-byte output. To
simplify the future transition, we apply the same restriction.
Update-Note: The Kyber public APIs have changed slightly, but we do not
believe there are any users of them yet.
Change-Id: Iea4fb1b13ecfcc3fead62989cee79de011f413c5
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/64349
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
The implementation is based on the current round 3 specification with
the modifications to FORS indices generation suggest on the mailing
list. The implementation passes test vectors and uses the default SHA256 implementation of BoringSSL.
Change-Id: Iab2dbaf5f692d490577dc940d9f3e298a72e9193
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60965
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
This adds "group" versions of our codepoint-based APIs. This is mostly
because it looks weird to switch terminology randomly in the
implementation. See I7a356793d36419fc668364c912ca7b4f5c6c23a2 for
additional context.
I've not bothered renaming the bssl_shim flags. That seems a waste of
time.
Change-Id: I566ad132f5a33d99efd8cb2bb8b76d9a6038c825
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60207
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This is inspired somewhat from how https://github.com/google/benchmark's
threaded benchmark support works. (It seems to spawn a bunch of threads,
latch them all together, and then run.)
This adds a TimeFunctionParallel which runs multiple copies of the
benchmark in parallel, after waiting for all the threads to synchronize.
Some functions had to be tweaked so they don't write to a single, shared
output buffer.
This probably could use some improvement. In playing with it, the
numbers are pretty unstable. We also don't currently benchmark anything
that captures EVP's internal refcounts. But hopefully it's enough to get
a start. I am able to measure impacts from the PRNG locks at least.
Bug: 570
Change-Id: I92c29a05ba082fc45701afd6f0effe23f7b148bd
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59845
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
EC_RAW_POINT is a confusing name. It's mostly about whether this is
stack-allocated EC_POINT without the EC_GROUP pointer. Now that we have
EC_AFFINE, EC_JACOBIAN captures what it's doing a bit better.
Fixed: 326
Change-Id: I5b71a387e899a94c79be8cd5e0b54b8432f7d5da
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59565
Reviewed-by: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
This was added with the generated symbol-prefixing header. But it
seems to be sufficient for crypto to have a dependency on the
generated header, along with some of the stray bits of delocate.
It's a little unclear from CMake documentation how these are processed;
normally .o files can be built before libraries are built or linked,
only the link step depends on.
But, empirically, if A links B, and B has a dependency on C, then CMake
seems to run C before building any of A. I tested this by making a small
project where the generation step slept for three seconds and running
with enough parallelism that we'd have tripped.
Interestingly, in the Makefile output, the individual object file
targets didn't have that dependency, but the target itself did. But this
was true on both A and B, so I think that just might not work.
Also fix the dependency in the custom target. The old formulation broke
when using an absolute path to the symbols file.
Change-Id: I2053d44949f907d465da403a5ec69c191740268f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56928
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
It's unclear to me whether doing it target-by-target is an improvement
in crypto/fipsmodule, but this otherwise does seem a bit tidier. This
aligns with CMake's documentation and "modern CMake" which prefers this
pattern.
Change-Id: I36c81842bff8b36eeaaf5dd3e0695fb45f3376c9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56585
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Also add public APIs for this, now that the specification is no longer
expected to change, and because a project external to the library wishes
to use it.
For now, I've kept the P-256 version using the generic felem_exp, but we
should update that to use the specialized field arithmetic.
Trust Tokens will presumably move to this later and, in the meantime,
another team wants this.
Bug: chromium:1414562
Change-Id: Ie38203b4439ff55659c4fb2070f45d524c55aa2a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/57147
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
The ws2_32 dependency comes from BIO, which is in libcrypto. Once it's
added there, it should get inherited by anything downstream, so we don't
need to keep listing it.
We also no longer need -lrt. We tried to remove it in
https://boringssl-review.googlesource.com/4622, but had to revert it in
https://boringssl-review.googlesource.com/4894 because of clock_gettime.
clock_gettime, per the Linux man page, is now in libc, not librt, as of
glibc 2.17. THat was released December 2012, well past our five year
watermark, so clean this part of the build up.
Change-Id: Ie6a07434b0cb02fe916b32ab8c326ec33d40bcb6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56606
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This aligns with upstream OpenSSL, so it's hopefully more compatible.
Code search says no one outside of the project uses this function, so
it's unlikely to break anyone.
Whether it makes things better is a bit of a wash: OBJ_dup and
OPENSSL_strdup loose a pointless wrapper. X509_NAME_dup gains one, but
hopefully that can be resolved once we solve the X509_NAME
const-correctness problem. CRYPTO_BUFFER_up_ref gains one... really
FOO_up_ref should have type const T * -> T *, but OpenSSL decided it
returns int, so we've got to cast.
Change-Id: Ifa6eaf26777ac7239db6021fc1eafcaed98e42c4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56032
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
We were mixing uint64_t and unsigned, which flagged -Wshorten-64-to-32.
While I'm here, switch the iteration count to uint64_t to cut down on
uses of 'unsigned'. While we have no real risk of overflow a u32 here,
counting the number of times we perform some operation in a loop would
probably best be u64.
(I'm guessing we originally used unsigned mostly so that %u worked. But
PRIu64 exists, though it's wordy.)
Bug: 516
Change-Id: I6abc24ecb029c2c223bb940c903d497868bab9fc
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55455
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
I had a rewrite of the decrepit ciphers (CAST and Blowfish) to use
CRYPTO_{load,store}_u32_be and drop the old macros, but this is probably
not worth the effort to review. Instead, just fix the type in the macro.
Bug: 516
Change-Id: I1cdecc16f6108a6235f90cf9c2198bc797c6716e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54985
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CMake versions newer than ~3.1x automatically determine the subdirectory under CMAKE_INSTALL_PREFIX using the type of the installed target. Older versions need this to be manually computed using the GNUInstallDirs library.
Since we override the CMAKE_INSTALL_PREFIX default, this just controls
the internal layout of the install/ directory generated underneath the
boringssl checkout.
Bug: 488
Change-Id: I97b02006301e463bb0cfd54acb2b27656484cc85
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52345
Reviewed-by: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
The HEAD version of Clang fails to build boringssl due to the following
warning triggered at -Werror:
/usr/local/google/home/dthorn/curl/boringssl/tool/digest.cc:229:12:
error: variable 'bad_hash_lines' set but not used
This change removes the variable.
Change-Id: I25009925d9a2dfc5b1783accab19e4b861db4ec2
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52265
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
This creates an install directory under the top level source directory.
The install contains a CMake config file that produces variables and
targets compatible with FindOpenSSL, or the directory can be scanned by
FindOpenSSL via -DOPEN_SSL_ROOT. This allows using BoringSSL with
third-party dependencies that find an SSL implementation via CMake.
Change-Id: Iffeac64b9cced027d549486c98a6cd9721415454
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52205
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
David Benjamin