When we have both crypto/foo/internal.h and
crypto/fipsmodule/foo/internal.h, it's important that we put FIPSMODULE
into the header guard.
At that point, we probably should just put CRYPTO in there too, and
indeed we have been putting it in a few places. Go ahead and rewrite
them all with some clever shell scripting.
Change-Id: If61586f1d49ed477023530c36e9ed74373d4d1e6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/77727
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@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>
The FIPS module will export a pair of general functions for the
prehashed modes. We'll split the non-standard and standard modes at the
public interface.
Change-Id: Ic824342678cd0ccbe3c9bd25c1a676268de6e367
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/73927
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Except for our public headers, our files no longer need to be consumed
by C. That means inline can just be inline, and with C++17,
OPENSSL_UNUSED can be [[maybe_unused]].
Bug: 42290600
Change-Id: Ibdb309bc413660e10d075fbb71d4d1dd87101c6d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74489
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
It looks like seeds will be the official private key format for ML-DSA
and ML-KEM. Thus parsing the weird private key format will only be
needed for processing NIST's test vectors.
Change-Id: Id6273214ba98b73aaf96640ec25ea289801b9bd7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/73848
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Adam Langley <agl@google.com>
This is deliberately not exported in the public interface. Obviously we
could add it in the future if we wished but, for now, our suggestion is
to use ML-DSA-65. However, if needed in the future, it will already be
ready and FIPS validated inside the module.
Change-Id: I38a59d4e58b76cf74004432e87143380691a722b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/73347
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: 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>
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 <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Bas Westerbaan