With -march=haswell -DOPENSSL_SMALL=1 on cascadelake:
Did 9999 ECDH P-256 operations in 1062469us (9411.1 ops/sec) [+63.5%]
Did 25000 ECDSA P-256 signing operations in 1028302us (24311.9 ops/sec) [+48.9%]
Did 11004 ECDSA P-256 verify operations in 1072646us (10258.7 ops/sec) [+58.8%]
Same configuration measured no performance difference on haswell.
The added assembly code occupies 1352 bytes.
Change-Id: I42635b7a9bf24d942817976a5d4ce269f642251c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/63185
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Bug: chromium:1322914
Change-Id: Ic5a1349013bcfb279e5fee9f9838c63558d663b7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/63025
Auto-Submit: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Change-Id: I18ba860d28dd3fb55cc14904758d6a8dc95e3f89
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/62725
Auto-Submit: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Change-Id: I368e98f7484bdafac8d8600a6b4d5d7013e08817
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/62705
Auto-Submit: Bob Beck <bbe@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
While cmake does not care and happily build anyway, Bazel gets
very upset when faced with this in it's generated files from this.
Crbug: 1322914
Change-Id: Ia564be8dfd81bd206b80996bc660113da04de314
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/62505
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Auto-Submit: Bob Beck <bbe@google.com>
we do end up needing this for google3.
crbug: 1322914
Change-Id: I3788170521fff6a7a8075c58d929558b97820a34
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/62405
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Change-Id: I235d81c6e6b013b25488355ccd5de254e7c172b8
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/62306
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: Bob Beck <bbe@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Adds general_names and crl unittests to pki tests, with
associated data files for crl unittest.
Bug: chromium:1322914
Change-Id: Idda8e4a98ef3744a76717db32628db554c12e415
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61965
Auto-Submit: Bob Beck <bbe@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Change-Id: I690f56f2164936b005b672f896858b027a79c011
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61745
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: Bob Beck <bbe@google.com>
file_test_gtest.cc depends on GetTestData which, for now, only exists in
crypto_test because of how the crypto_test_data machinery works. Ideally
that would be fixed but, for now, move the file out of test_support.
Things were previously building because we were relying on the static
linker to drop the file in the other targets, before the linker would
notice the undefined symbol. I'm not sure what's different about
Chromium, but somehow Chromium is sensitive to this.
Bug: 542
Change-Id: I38c7719e7c3f27bcfeeab9693fcd43fbd0300799
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61526
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
As part of this, align the generated and standalone builds in how
crypto/test/gtest_main.cc is added. Since not all test targets
(urandom_test) include gtest_main.cc, and the generated one just
manually adds it to the file lists, just put it into the file lists
ahead of time. That way we don't need to synchronize the dependency
information with the generated build.
This also aligns the generated build with
https://boringssl-review.googlesource.com/c/boringssl/+/56567 to put
files like crypto/test/abi_test.cc and crypto/test/file_test_gtest.cc in
the test_support library.
Update-Note: If something odd happens with the test_support library in
downstream builds, this CL is probably to blame.
Bug: 542
Change-Id: I235e0ccd0432f4b380a92b265ede35eb8a6a6e36
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61288
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
CMake and the generate builds now broadly share a source of truth for
the test files.
Update-Note: In the standalone CMake build, build/crypto/crypto_test is
now build/crypto_test, etc. For now, the build still copies the outputs
to the subdirectories (it's cheap and avoids some workflow turbulence),
but I'm thinking we keep that for six months or so and then remove it.
Bug: 542
Change-Id: I8f97e1fcedea1375d48567dfd2da01a6e66ec4e8
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61286
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
This achieves much of the same goals as
https://boringssl-review.googlesource.com/c/boringssl/+/61245, but
reuses the existing source.cmake parser in generate_build_files.py.
There are two practical differences here:
First, CMake knows that, if it sees include(sources.cmake), it should
add sources.cmake as a dependency of build.ninja, and re-run cmake if
source.cmake changes. It does not know this for file(STRINGS). This can
be fixed with CMAKE_CONFIGURE_DEPENDS, but since we already have this,
may as well use it.
Second, sources.cmake wants paths rooted at the top-level BoringSSL
source directory, which means we want to define the targets at the top
level, rather than in subdirectories. While it will make the top-level
CMakeLists.txt larger, I think this is a good move:
- ./build/crypto_test --gtest_filter=... is just less annoying to type
than ./build/crypto/crypto_test --gtest_filter=...
- It will (eventually) mean libcrypto.a lives at build/libcrypto.a
instead of build/crypto/libcrypto.a. This means we can pass a single
-L parameter when building things against BoringSSL, without relying
on the install target.
- It aligns with the generated CMake build. I would like, long-term, to
stop maintaining multiple CMake builds, and the generated one seems to
have a better convention. And one that will be more disruptive to
others if we change it.
- Top-level-rooted paths are more convenient for generate_build_files.py
to work with, because that's what we want to output.
As I get further along in 542, I expect I'll move this once again,
possibly to some JSON file, because I'll need my new pregenerate tool to
parse it (and we'll no longer be constrained by what's easy to consume
in CMake), but use this for now.
Bug: 542
Change-Id: I1e8b894057264da5d7624a1fbb92f9e1198ea38e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61266
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Passes test vectors, and should be constant time, but is currently
not optimized and neither the API nor the standard is stable.
Change-Id: I89b90877e023a43ee7238e11b86065444ab3bdec
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/57845
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
If we see a critical policy constraints extension, we have two options:
We can either process it, which requires running policy validation, or
reject the certificate. We and OpenSSL do neither by default, which
means we may accept certificate chains that we weren't supposed to.
This fixes it by enabling X.509 policy validation unconditionally and
makes X509_V_FLAG_POLICY_CHECK moot. As a side effect, callers no longer
need to do anything for CVE-2023-0466.
This is the opposite of [0]'s advice, which instead recommends skipping
the feature and rejecting critical policy contraints. That would be a
good move for a new X.509 implementation. Policy validation is
badly-designed, even by X.509's standards. But we have OpenSSL's history
of previously accepting critical policy constraints (even though it
didn't check it). I also found at least one caller that tests a chain
with policy constraints, albeit a non-critical one.
We now have an efficient policy validation implementation, so just
enable it.
Of course, fixing this bug in either direction has compatibility risks:
either we take on the compat risk of being newly incompatible with
policyConstraints-using PKIs, or we take on the compat risk of newly
rejecting certificates that were invalid due to a policy validation
error, but no one noticed. The latter case seems safer because the chain
is unambiguously invalid.
Update-Note: X.509 certificate verification (not parsing) will now
notice policy-validation-related errors in the certificate chain. These
include syntax errors in policy-related extensions, and chains with a
requireExplicitPolicy policy constraint that are valid for no
certificate policies. Such chains are unambiguously invalid. We just did
not check it before by default. This is an obscure corner of X.509 and
not expected to come up in most PKIs.
[0] https://www.ietf.org/archive/id/draft-davidben-x509-policy-graph-01.html#section-3.4.4
Fixed: 557
Change-Id: Icc00c7797bb95fd3b14570eb068543fd83cda7b9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58426
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
There was a typo and inhibitPolicyMapping updated the wrong value. With
this fixed, we pass the PKITS tests (as imported into Chromium).
Change-Id: I3b80eb56561ae5ae88023fa639d697a9f1757b21
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56205
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
And specifically that it also counts at the leaf, which was a bug I'd
nearly introduced. (RFC 5280 is written somewhat confusingly. The
wrap-up and prepare procedures have some duplicate processing.)
Change-Id: Iea901b96f64e12199fec426dc936bfbde16f88a4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56035
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Such mappings should be ignored.
Change-Id: Ic75d3c17e3f2d25da75b15d59e38177f9bc1c044
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56034
Reviewed-by: Matt Mueller <mattm@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
anyPolicy causes crypto/x509 to synthesize policy nodes in places. Add
some test coverage for this.
Change-Id: I1b1dcba35088d6cabce6b40e36e478ec4756effa
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55753
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
If a certificate has policy constraints, but the certificate policies
extension is either missing or unsuitable (in a way not caught by the
parser), the policy constraints object is leaked.
As part of this, add some basic tests for policy constraints.
Change-Id: I4a2c618019d1f92b0f3b9ad4cf6e29d4926e3095
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55752
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
X509_policy_check returns -1 if some certificate had an unparseable
extension, in which case it sets EXFLAG_INVALID_POLICY on it. The
calling code then iterates over the certificates to find the offending
one, so the callback has a chance to undo it. But it skips i = 0, the
leaf, and instead just silentely returns success.
We really should cut down on the callback's ability to mess things up
here but, in the meantime, fix this. Also add a test covering this case.
While I'm here, I've updated make_invalid_extensions.go, which I pulled
some code from, to rename fooOrPanic to mustFoo. That seems to be the
convention in the Go standard library. (regexp.MustCompile, etc.)
Change-Id: Ib07c9f4175e66483bd7c0f7d49aea931bf36e53f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55748
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
FileTests run sequentially and cannot be filtered. Split them up so it's
easier to, say, just run the ModExp ones. Also our test sharding
machinery will do a slightly better job parallelizing them when split up
like this. (This is one of our slower tests.)
Change-Id: Ie69864982f043655f68e592440b1f36e971b033a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55230
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Matching Chromium, Go, and TLS 1.3, only allow SHA-256, SHA-384, and
SHA-512 RSA-PSS signatures, where MGF-1 and message hash match and salt
length is hash length. Sadly, we are stuck tolerating an explicit
trailerField for now. See the certificates in cl/362617931.
This also fixes an overflow bug in handling the salt length. On
platforms with 64-bit long and 32-bit int, we would misinterpret, e.g,
2^62 + 32 as 32. Also clean up the error-handling of maskHash. It was
previously handled in a very confusing way; syntax errors in maskHash
would succeed and only be noticed later, in rsa_mgf1_decode.
I haven't done it in this change, but as a followup, we can, like
Chromium, reduce X.509 signature algorithms down to a single enum.
Update-Note: Unusual RSA-PSS combinations in X.509 are no longer
accepted. This same change (actually a slightly stricter version) has
already landed in Chrome.
Bug: 489
Change-Id: I85ca3a4e14f76358cac13e66163887f6dade1ace
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53865
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
The ARMv8 assembly code in this commit is mostly taken from OpenSSL's `ecp_nistz256-armv8.pl` at 19e277dd19/crypto/ec/asm/ecp_nistz256-armv8.pl (see Note 1), adapting it to the implementation in p256-x86_64.c.
Most of the assembly functions found in `crypto/fipsmodule/ec/asm/p256-x86_64-asm.pl` required to support that code have their analogous functions in the imported OpenSSL ARMv8 Perl assembly implementation with the exception of the functions:
- ecp_nistz256_select_w5
- ecp_nistz256_select_w7
An implementation for these functions was added.
Summary of modifications to the imported code:
* Renamed to `p256-armv8-asm.pl`
* Modified the location of `arm-xlate.pl` and `arm_arch.h`
* Replaced the `scatter-gather subroutines` with `select subroutines`. The `select subroutines` are implemented for ARMv8 similarly to their x86_64 counterparts, `ecp_nistz256_select_w5` and `ecp_nistz256_select_w7`.
* `ecp_nistz256_add` is removed because it was conflicting during the static build with the function of the same name in p256-nistz.c. The latter calls another assembly function, `ecp_nistz256_point_add`.
* `__ecp_nistz256_add` renamed to `__ecp_nistz256_add_to` to avoid the conflict with the function `ecp_nistz256_add` during the static build.
* l. 924 `add sp,sp,#256` the calculation of the constant, 32*(12-4), is not left for the assembler to perform.
Other modifications:
* `beeu_mod_inverse_vartime()` was implemented for AArch64 in `p256_beeu-armv8-asm.pl` similarly to its implementation in `p256_beeu-x86_64-asm.pl`.
* The files containing `p256-x86_64` in their name were renamed to, `p256-nistz` since the functions and tests defined in them are hereby running on ARMv8 as well, if enabled.
* Updated `delocate.go` and `delocate.peg` to handle the offset calculation in the assembly instructions.
* Regenerated `delocate.peg.go`.
Notes:
1- The last commit in the history of the file is in master only, the previous commits are in OpenSSL 3.0.1
2- This change focuses on AArch64 (64-bit architecture of ARMv8). It does not support ARMv4 or ARMv7.
Testing the performance on Armv8 platform using -DCMAKE_BUILD_TYPE=Release:
Before:
```
Did 2596 ECDH P-256 operations in 1093956us (2373.0 ops/sec)
Did 6996 ECDSA P-256 signing operations in 1044630us (6697.1 ops/sec)
Did 2970 ECDSA P-256 verify operations in 1084848us (2737.7 ops/sec)
```
After:
```
Did 6699 ECDH P-256 operations in 1091684us (6136.4 ops/sec)
Did 20000 ECDSA P-256 signing operations in 1012944us (19744.4 ops/sec)
Did 7051 ECDSA P-256 verify operations in 1060000us (6651.9 ops/sec)
```
Change-Id: I9fdef12db365967a9264b5b32c07967b55ea48bd
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51805
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
X509V3_EXT_d2i should notice if an extension has extra data at the end.
Update-Note: Some previously accepted invalid certicates may be
rejected, either in certificate verification or in X509_get_ext_d2i.
Bug: 352
Change-Id: Iacbb74a52d15bf3318b4cb8271d44b0f0a2df137
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50285
Reviewed-by: Adam Langley <agl@google.com>
pkcs12_test.cc was getting a bit long. Along the way, embed_test_data.go
needed a fix to work around a syntax quirk of C++.
Change-Id: Ic4a19f77d177ebd607918feb253a08f1f9037981
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46044
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Our use-case for this does not require optimisation at the current time,
so a clean C implementation is fine.
Change-Id: I8f29572c33e8dbcc37961c099c71c14aafc8d0a3
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45164
Reviewed-by: David Benjamin <davidben@google.com>
For FIPS reasons, one might wish to ensure that a random AES-GCM nonce
was generated entirely within the FIPS module. If so, then these are the
AEADs for you.
Change-Id: Ic2b7864b089f446401f700d7d55bfa6336c61e23
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43686
Commit-Queue: Adam Langley <alangley@gmail.com>
Reviewed-by: David Benjamin <davidben@google.com>
Conscrypt will need these functions. Also fix a bug in
X509_get_extension_flags's error-handling. While I'm here, add
X509_CRL_get0_extensions for completeness. Nothing uses this yet, but
this could later be an alternative to avoid Conscrypt's mess with
templates.
Change-Id: I9393b75fcf53346535e6a4712355be081baa630d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42744
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
draft-ietf-tls-esni-07 uses HPKE for encryption.
Bug: 275
Change-Id: I4af39be4df534f8c1c991c4df82d38c6adcf2574
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41304
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Andres Erbsen
Bob Beck
David Benjamin
Sophie Schmieg
Adam Langley
Adam Langley
Nevine Ebeid
Daniel McArdle