The Clang used in the Android SDK, at least, defines both __ARM_NEON__
and __ARM_NEON for ARMv7, but only the latter for AArch64.
This change switches each use of __ARM_NEON__ to accept either.
Change-Id: I3b5d5badc9ff0210888fd456e9329dc53a2b9b09
Reviewed-on: https://boringssl-review.googlesource.com/c/33104
Commit-Queue: Adam Langley <alangley@gmail.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This removes the failure cases for cmp_x_coordinate, this clearing our
earlier dilemma.
Change-Id: I057f705e49b0fb5c3fc9616ee8962a3024097b24
Reviewed-on: https://boringssl-review.googlesource.com/c/33065
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This is in preparation for removing the BIGNUM from cmp_x_coordinate.
Change-Id: Id8394248e3019a4897c238289f039f436a13679d
Reviewed-on: https://boringssl-review.googlesource.com/c/33064
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
I forgot to refresh the public key in those tests, so they weren't
actually testing what they were supposed to. With this fix, injecting
too larger of a P_MINUS_ORDER into p256-x86_64.c now breaks tests.
Change-Id: I5d10a85c84b09629448beef67c86de607525fc71
Reviewed-on: https://boringssl-review.googlesource.com/c/33044
Reviewed-by: Adam Langley <agl@google.com>
Reportedly some combination of C++ modules and old clang gets upset.
That seems an inadvisable combination, but including headers under
extern "C" is rude, so fix it.
Change-Id: I12f873e1be41697b67f2b1145387a3c6fc769c28
Reviewed-on: https://boringssl-review.googlesource.com/c/33024
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Having to lazily create it is a little wordy, and we append to it in
three places now. V2ClientHello makes this slightly finicky, but I think
this is still clearer.
Change-Id: If931db0b56efd7f0728c0b7d119886864dd7933a
Reviewed-on: https://boringssl-review.googlesource.com/c/32824
Commit-Queue: Steven Valdez <svaldez@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Steven Valdez <svaldez@google.com>
This function is not EC_METHOD-specific, nor is there any reason it
would be (we do not support GF2m).
Change-Id: I4896cd16a107ad6a99be445a0dc0896293e8c8f9
Reviewed-on: https://boringssl-review.googlesource.com/c/32884
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
This is done in preparation of generalizing the optimization to all our
EC_METHODs.
Wycheproof happily does cover the case where x needed a reduction, but
they don't appear to check x being just above or below n, only x = p - 1
(adjusted downwards). Also we can tailor the test vectors a bit to the
x == r*z^2 (mod p) strategy to make sure we don't mess that up.
Additionally, the scenario is different for n > p. There is also the
nuisance of EC_FELEM vs EC_SCALAR having different widths. All our
built-in curves are well-behaved (same width, and consistently p < n),
but secp160r1 is reachable from custom curves and violates both
properties. Generate some tests to cover it as well.
Change-Id: Iefa5ebfe689a81870be21f04f5962ab161d38dab
Reviewed-on: https://boringssl-review.googlesource.com/c/32985
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
Some of the ec files now reference ECDSA_R_BAD_SIGNATURE. Instead, lift the
error-pushing to ecdsa.c.
Change-Id: Ice3e7a22c5099756599df0ab0b215c0752ada4ee
Reviewed-on: https://boringssl-review.googlesource.com/c/32984
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This reverts commit e907ed4c4b. CPUID
checks have been added so hopefully this time sticks.
Change-Id: I5e0e5b87427c1230132681f936b3c70bac8263b8
Reviewed-on: https://boringssl-review.googlesource.com/c/32924
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Update-Note: This effectively reverts https://boringssl-review.googlesource.com/4733,
which was an attempt at a well-defined story during renegotiation and pre-handshake.
This is a behavior change, though one that matches OpenSSL upstream. It is also more
consistent with other functions, such as SSL_get_curve_id. Renegotiation is now
opt-in, so this is less critical, and, if we change the behavior mid-renegotiation,
we should do it consistently to all getters.
Change-Id: Ica6b386fb7c5ac524395de6650642edd27cac36f
Reviewed-on: https://boringssl-review.googlesource.com/c/32904
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Now that the tuned add/dbl implementations are exposed, these can be
specific to EC_GFp_mont_method and call the felem_mul and felem_sqr
implementations directly.
felem_sqr and felem_mul are still used elsewhere in simple.c, however,
so we cannot get rid of them yet.
Change-Id: I5ea22a8815279931afc98a6fc578bc85e3f8bdcc
Reviewed-on: https://boringssl-review.googlesource.com/c/32849
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
Change-Id: I7922b4b26dabb6875e800472ee8453ca4a9922e0
Reviewed-on: https://boringssl-review.googlesource.com/c/32845
Reviewed-by: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
A split SSL handshake may involve 2 binaries, potentially built at
different versions: call them the "handoff/handback" binary and the
"handshake" binary. We would like to guarantee that the
handoff/handback binary does not make any promises that the handshake
binary cannot keep.
d2ed382 serialized |kCiphers|; this commit extends the same approach
to |kNamedGroups|.
Change-Id: Idb13e54e9b189236309f6054a36872c5a4d96985
Reviewed-on: https://boringssl-review.googlesource.com/c/32825
Reviewed-by: David Benjamin <davidben@google.com>
This reverts commit 3d450d2844. It fails
SDE, looks like a missing CPUID check before using vector instructions.
Change-Id: I6b7dd71d9e5b1f509d2e018bd8be38c973476b4e
Reviewed-on: https://boringssl-review.googlesource.com/c/32864
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Some consumer stumbled upon EC_POINT_{add,dbl} being faster with a
"custom" P-224 curve than the built-in one and made "custom" clones to
work around this. Before the EC_FELEM refactor, EC_GFp_nistp224_method
used BN_mod_mul for all reductions in fallback point arithmetic (we
primarily support the multiplication functions and keep the low-level
point arithmetic for legacy reasons) which took quite a performance hit.
EC_FELEM fixed this, but standalone felem_{mul,sqr} calls out of
nistp224 perform a lot of reductions, rather than batching them up as
that implementation is intended. So it is still slightly faster to use a
"custom" curve.
Custom curves are the last thing we want to encourage, so just route the
tuned implementations out of EC_METHOD to close this gap. Now the
built-in implementation is always solidly faster than (or identical to)
the custom clone. This also reduces the number of places where we mix
up tuned vs. generic implementation, which gets us closer to making
EC_POINT's representation EC_METHOD-specific.
Change-Id: I843e1101a6208eaabb56d29d342e886e523c78b4
Reviewed-on: https://boringssl-review.googlesource.com/c/32848
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
This commit improves the performance of ECDSA signature verification
(over NIST P-256 curve) for x86 platforms. The speedup is by a factor of 1.15x.
It does so by:
1) Leveraging the fact that the verification does not need
to run in constant time. To this end, we implemented:
a) the function ecp_nistz256_points_mul_public in a similar way to
the current ecp_nistz256_points_mul function by removing its constant
time features.
b) the Binary Extended Euclidean Algorithm (BEEU) in x86 assembly to
replace the current modular inverse function used for the inversion.
2) The last step in the ECDSA_verify function compares the (x) affine
coordinate with the signature (r) value. Converting x from the Jacobian's
representation to the affine coordinate requires to perform one inversions
(x_affine = x * z^(-2)). We save this inversion and speed up the computations
by instead bringing r to x (r_jacobian = r*z^2) which is faster.
The measured results are:
Before (on a Kaby Lake desktop with gcc-5):
Did 26000 ECDSA P-224 signing operations in 1002372us (25938.5 ops/sec)
Did 11000 ECDSA P-224 verify operations in 1043821us (10538.2 ops/sec)
Did 55000 ECDSA P-256 signing operations in 1017560us (54050.9 ops/sec)
Did 17000 ECDSA P-256 verify operations in 1051280us (16170.8 ops/sec)
After (on a Kaby Lake desktop with gcc-5):
Did 27000 ECDSA P-224 signing operations in 1011287us (26698.7 ops/sec)
Did 11640 ECDSA P-224 verify operations in 1076698us (10810.8 ops/sec)
Did 55000 ECDSA P-256 signing operations in 1016880us (54087.0 ops/sec)
Did 20000 ECDSA P-256 verify operations in 1038736us (19254.2 ops/sec)
Before (on a Skylake server platform with gcc-5):
Did 25000 ECDSA P-224 signing operations in 1021651us (24470.2 ops/sec)
Did 10373 ECDSA P-224 verify operations in 1046563us (9911.5 ops/sec)
Did 50000 ECDSA P-256 signing operations in 1002774us (49861.7 ops/sec)
Did 15000 ECDSA P-256 verify operations in 1006471us (14903.6 ops/sec)
After (on a Skylake server platform with gcc-5):
Did 25000 ECDSA P-224 signing operations in 1020958us (24486.8 ops/sec)
Did 10373 ECDSA P-224 verify operations in 1046359us (9913.4 ops/sec)
Did 50000 ECDSA P-256 signing operations in 1003996us (49801.0 ops/sec)
Did 18000 ECDSA P-256 verify operations in 1021604us (17619.4 ops/sec)
Developers and authors:
***************************************************************************
Nir Drucker (1,2), Shay Gueron (1,2)
(1) Amazon Web Services Inc.
(2) University of Haifa, Israel
***************************************************************************
Change-Id: Idd42a7bc40626bce974ea000b61fdb5bad33851c
Reviewed-on: https://boringssl-review.googlesource.com/c/31304
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Change-Id: I84cda22a1086bce0da4797afae7975b3f39625de
Reviewed-on: https://boringssl-review.googlesource.com/c/32844
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
A split SSL handshake may involve 2 binaries, potentially built at
different versions: call them the "handoff/handback" binary and the
"handshake" binary. We would like to guarantee that the
handoff/handback binary does not make any promises that the handshake
binary cannot keep.
As a start, this commit serializes |kCiphers| to the handoff message.
When the handoff message is applied to an |SSL|, any configured
ciphers not listed in the handoff message will be removed, in order to
prevent them from being negotiated.
Subsequent commits will apply the same approach to other lists of features.
Change-Id: Idf6dbeadb750c076ab0509c09b9d3f22eb162b9c
Reviewed-on: https://boringssl-review.googlesource.com/c/29264
Reviewed-by: Matt Braithwaite <mab@google.com>
This is an extremely important and practical use case. The comment that
state->calls is bounded by the reseed interval isn't quite true. We only
check on entry to the function, which means that it may exceed it by one
call's worth. Switch it to a size_t (which doesn't actually increase
memory because the struct was already padded).
Change-Id: Ia7646fd5b4142789c1d613280223baa4cd1a4a9b
Reviewed-on: https://boringssl-review.googlesource.com/c/32804
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Avoid forcing the QUIC implementation to buffer this when we already have code
to do it. This also avoids QUIC implementations relying on this hook being
called for each individual message.
Change-Id: If2d70f045a25da1aa2b10fdae262cae331da06b1
Reviewed-on: https://boringssl-review.googlesource.com/c/32785
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
0-RTT support and APIs to consume NewSessionTicket will be added in a
follow-up.
Change-Id: Ib2b2c6b618b3e33a74355fb53fdbd2ffafcc5c56
Reviewed-on: https://boringssl-review.googlesource.com/c/31744
Commit-Queue: Steven Valdez <svaldez@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Uses have been either migrated to
OPENSSL_NO_THREADS_CORRUPT_MEMORY_AND_LEAK_SECRETS_IF_THREADED or removed.
Update-Note: Anything still relying on OPENSSL_NO_THREADS should be updated to
either use OPENSSL_NO_THREADS_CORRUPT_MEMORY_AND_LEAK_SECRETS_IF_THREADED if a
single-threaded-only platform, or fixed to depend on the platform threading
library.
Change-Id: I02ec63bc7ede892bd6463f1a23e2cec70887fab3
Reviewed-on: https://boringssl-review.googlesource.com/c/32744
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Ryan noticed that CBS_ASN1_{SEQUENCE,SET} used CBS_ASN1_CONSTRUCTED
before it was defined. The C preprocessor expands late, so this works,
but it is weird. Flip the order.
There was also some question about the constructed bit, which is
different from how ASN.1 formally specifies it. (ASN.1 believes the
constructed bit is a property of the element, not the tag. We fold it in
because it's entirely computable[*] from the type in DER, so it's easier
to fold it in.) Move existing text to the section header and expand on
it.
[*] DER forbids constructed strings so string types are always
primitive. ASN.1 forbids implicitly tagging CHOICE or ANY, so the
inherited constructed bit cannot vary by value.
Change-Id: Ieb91f9d6898d582dda19fec8b042051b67f217a8
Reviewed-on: https://boringssl-review.googlesource.com/c/32725
Reviewed-by: Ryan Sleevi <rsleevi@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
tls_cbc.c is concerned with the variation in where the padding+mac may
end, counted in blocks. Hash blocks are larger than block cipher blocks,
and the hash itself appends some padding. Thus maximal padding off a
64-hash.Size() bytes may not fully stress things.
Just run all inputs modulo the hash block size, so we don't have to
think very hard about the "most difficult" input.
Change-Id: I8da1427dfff855931c14a9135c22afbff4f367c0
Reviewed-on: https://boringssl-review.googlesource.com/c/32724
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Although this macro is not public API and is unused in BoringSSL,
wpa_supplicant uses it to define its own stacks. Remove this once
wpa_supplicant has been fixed.
Change-Id: I1f85e06efe4057b6490bf93bf4dea773dcb491c5
Reviewed-on: https://boringssl-review.googlesource.com/c/32764
Reviewed-by: Robert Sloan <varomodt@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Symptom: When using larger hash functions and short messages,
these six blocks take too much time to be conditionally copied.
Observations:
- SHA-384 consumes more data per iteration, unlike SHA-256.
- The value of `kVarianceBlocks` must depend on the parameters
of the selected hash algorithm.
- Avoid magic constants.
Changes:
- A new formula for the kVarianceBlocks value.
- Stronger test vectors were created in change: 32724.
- The new formula passes these tests.
Discussion:
OpenSSL team: https://github.com/openssl/openssl/pull/7342
Quoting mattcaswell:
> The "real" data that needs to be hashed has to be padded for the
> hashing algorithm. For SHA1 the smallest amount of padding that
> can be added is the "0x80" byte plus 8 bytes containing the message
> length, i.e. 9 bytes. If the data length is within 9 bytes of the
> end of the hash block boundary then the padding will push it into
> an extra block to be hashed.
Change-Id: Id1ad2389927014316eed2b453aac6e4c2a585c5c
Reviewed-on: https://boringssl-review.googlesource.com/c/32624
Reviewed-by: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This function is not exported, so we don't need the optional BN_CTX
logic. Additionally, the cleanup code can be made a bit simpler and more
idiomatic.
Change-Id: Ib326eab4813fd9de9ac1df8fdc9e470c26aff092
Reviewed-on: https://boringssl-review.googlesource.com/c/32704
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
glibc didn't add getauxval or sys/auxv.h until 2.16. glib 2.16.0 is six
years old and thus glibc 2.15 is past our support horizon, however
Android is using an outdated sysroot. Temporarily allow this until they
fix their toolchain.
Change-Id: I24e231cf40829e446969f67bf15c32e0b007de4c
Reviewed-on: https://boringssl-review.googlesource.com/c/32686
Reviewed-by: Robert Sloan <varomodt@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
MSVC 2015 supports the static_assert keyword in C mode (not quite what C11
specifies: _Static_assert is the keyword and static_assert is a macro in
assert.h, but close enough). GCC and Clang both support _Static_assert at all C
versions. GCC has supported it in GCC 4.6.
glibc supports the assert.h macro since glibc 2.16, but does condition it on
the version, so we likely can't rely on that yet. Still, this means we should
be able to rely on proper static assertions at this point. In particular, this
means we'd no longer worry about emitting multiple typedefs of the same name.
Though at some point, it'd be nice to rely on being built in C11 mode. Then we
can just pull in assert.h and use bare static_assert, and the atomics business
needn't be a build flag.
Update-Note: If static asserts break the build, it's this CL's fault.
Change-Id: I1b09043aae41242f6d40386c063e381d00b028d8
Reviewed-on: https://boringssl-review.googlesource.com/c/32604
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Some versions of Android libc don't even include the header.
Change-Id: Ib1033d2b8a10ba69d834ac1ed2564870e0e35d61
Reviewed-on: https://boringssl-review.googlesource.com/c/32664
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
An EVP_AEAD_CTX used to be a small struct that contained a pointer to
an AEAD-specific context. That involved heap allocating the
AEAD-specific context, which was a problem for users who wanted to setup
and discard these objects quickly.
Instead this change makes EVP_AEAD_CTX large enough to contain the
AEAD-specific context inside itself. The dominant AEAD is AES-GCM, and
that's also the largest. So, in practice, this shouldn't waste too much
memory.
Change-Id: I795cb37afae9df1424f882adaf514a222e040c80
Reviewed-on: https://boringssl-review.googlesource.com/c/32506
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: David Benjamin <davidben@google.com>
Sections are separated by two blank lines.
Change-Id: If4f94a3b8f96044e83ab116e7603f1654130a551
Reviewed-on: https://boringssl-review.googlesource.com/c/32584
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This reverts https://boringssl-review.googlesource.com/24924. As noted
there, GCC 4.7 support ends 2018-03-23, which has passed. GCC 4.8.0 was
released 2013-03-22, so we are now past the five year mark, matching
Abseil's guidelines.
Abseil also now explicitly lists supported compilers and explicitly
requires GCC 4.8+. https://abseil.io/docs/cpp/platforms/platforms
gRPC also now requires 4.8 per
https://github.com/grpc/grpc/issues/10036#issuecomment-290248204
Update-Note: On the off chance someone was using GCC 4.7, which only
started working in January, that'll no longer work.
Change-Id: Ie017822e903f98293e7b5e9bda10f104f17be7b3
Reviewed-on: https://boringssl-review.googlesource.com/c/32564
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
If a startup process blocks, it's very useful to know which it was.
Change-Id: I04dd541695a61cfceb8142ea45d4bd5e3492c6ec
Update-note: updates internal bug 117227663.
Reviewed-on: https://boringssl-review.googlesource.com/c/32544
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
cryptography.io wraps this function and so we have to keep the LHASH_OF
argument for now.
Change-Id: I4e071dee973c3931a4005678ce4135161a5861bd
Reviewed-on: https://boringssl-review.googlesource.com/c/32524
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: David Benjamin <davidben@google.com>
Node references it these days. Also replace the no-op modes with negative
numbers rather than zero. Stream ciphers like RC4 report a "mode" of zero, so
code comparing the mode to a dummy value will get confused.
(I came across https://github.com/nodejs/node/pull/23635, though we'd have run
into it sooner or later anyway. Better to just define the value and avoid ifdef
proliferation.)
Change-Id: I223f25663e138480ad83f35aa16f5218f1425563
Reviewed-on: https://boringssl-review.googlesource.com/c/32464
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This CL adds srtp.h to the list of SSLHeaderFiles, in order to move it
from ssl_h_files to crypto_h_files. The header file only includes an
inclusion of ssl.h. ssl_h_files can depend on crypt_h_files but not the
other way around.
Change-Id: If7410624a8b2bbbd5afb7f66ec6f491968faf24e
Reviewed-on: https://boringssl-review.googlesource.com/c/32505
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This CL omits the RandTest.Fork unit test on Fuchsia, which does not
have fork(). Fuchsia has a bug (SEC-140) to create a suitable
replacement test.
Change-Id: Ic42f9149c24dc7321bfac1c718e9ecbb4a18b5d0
Reviewed-on: https://boringssl-review.googlesource.com/c/32504
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
As with sk_*, this. This doesn't fix the function pointer casts. Those
will be done in a follow-up change. Also add a test for lh_*_doall so we
cover both function pointer shapes.
Update-Note: This reworks how LHASH_OF(T) is implemented and also only
pulls in the definitions where used, but LHASH_OF(T) is never used
externally, so I wouldn't expect this to affect things.
Change-Id: I7970ce8c41b8589d6672b71dd03658d0e3bd89a7
Reviewed-on: https://boringssl-review.googlesource.com/c/32119
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
https://boringssl-review.googlesource.com/c/boringssl/+/24945 was mistaken in
that it thought that these AVX-512 assembly extensions were an
instruction-level thing, whereas they actually appear to be an argument-level
modifier.
This change parses them as such and unbreaks some AVX-512 instructions that can
be emitted by compilers with certain combinations of flags.
Change-Id: I9af5a4fec21f55d3198a248c9175252e229c355a
Reviewed-on: https://boringssl-review.googlesource.com/c/32484
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This is consistent with the old behavior of d2i_*_fp and avoids tripping
Conscrypt's unnecessarily fragile error-handling (see
https://github.com/google/conscrypt/pull/552).
Additionally, by source inspection, CPython expects
ASN1_R_HEADER_TOO_LONG on EOF, analogously to PEM_R_NO_START_LINE. Fix
that. The other errors are a bit haphazard in the old implementation
(that code is really hard to follow), so I didn't match it too
carefully. In particular, OpenSSL would report ASN1_R_HEADER_TOO_LONG on
some generic tag parsing, but that is inconsistent with
ASN1_R_HEADER_TOO_LONG being an EOF signal.
Update-Note: https://boringssl-review.googlesource.com/32106 may have
caused some compatibility issues. This should fix it.
Change-Id: Idfe2746ffd7733de4338e14c58a40753e98a791e
Reviewed-on: https://boringssl-review.googlesource.com/c/32444
Reviewed-by: Steven Valdez <svaldez@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Due to non-compliant middleboxes, it is possible we'll need to do some
surgery to this mechanism. Making it per-SSL is a little more flexible
and also eases some tests in Chromium until we get its SSL_CTX usage
fixed up.
Also fix up BoringSSL tests. We forgot to test it at TLS 1.0 and use the
-expect-tls13-downgrade flag.
Bug: 226
Change-Id: Ib39227e74e2d6f5e1fbc1ebcc091e751471b3cdc
Reviewed-on: https://boringssl-review.googlesource.com/c/32424
Reviewed-by: Steven Valdez <svaldez@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
