I screwed up in 56b6c714c9 and got the direction of this condition
backwards. This doesn't cause a security problem because:
a) wait_for_entropy will ensure that the pool is initialised.
b) if GRNG_NONBLOCK is set when not expected, any EAGAIN will
cause an abort anyway.
However, when coupled with opportunistic entropy collection on platforms
with RDRAND, this could cause an unexpected blocking getrandom call.
This this change, `strace -e getrandom bssl rand 1` shows two getrandom
calls with GRNG_NONBLOCK set, as expected. (The first being the probe to
check whether the kernel supports getrandom, and the second being the
opportunistic entropy gathering to augment RDRAND.)
Bug: chromium:1016811
Change-Id: I98ed1cef90df510f24cf2df1fba9b886fcbf3355
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38204
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
(cherry picked from commit f3bd757ee5)
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38504
Chrome sync folks need to do this. Add a function for it. There doesn't
seem to be a standard way to do it, so pick something arbitrary.
Bug: chromium:1010968
Change-Id: Ib55456e4af5849cd9da33f397e8f12deb6f02917
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38144
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
When building with |OPENSSL_NO_ASM|, the section that marks assembly
files as no-exec-stack will currently be omitted. That results in an
empty assembly file but that's still enough to trigger warnings:
warning: crypto_tests/trampoline-x86_64.o: missing .note.GNU-stack section implies executable stack
This change makes it so that the section marker will always be emitted,
even if the file is otherwise empty.
Change-Id: I2d08d34ed9dbe9e9592c88dcd42d3ba4fa3d7652
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38084
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
This makes it possible to fetch the min and max versions configured
directly on SSL objects (as opposed to SSL_CTX ones).
This is useful when configuring supported TLS versions on per-connection
basis.
Change-Id: Ibccc92c5f7668e9a7be5a01d6f84089608382407
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38104
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Introduces optional extra flags for getrandom which are ORed in when
reading a FIPS seed. Setting the Android read-only system property
ro.boringcrypto.hwrand to true will set the extra flags to GRND_RANDOM.
Testing: Built and tested on AOSP as http://r.android.com/1134926
and verified behaviour via the extra printfs in that CL and also
observing the flags passed to getrandom using strace.
Change-Id: Idd782df65ba0d49b8b1357b346caa4ef747587f1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38024
Reviewed-by: David Benjamin <davidben@google.com>
Chromium's renegotiation handling currently relies on reads being the only
thing that can discover a renegotiation. However, for a number of reasons, we
would like to eagerly drive the read loop after a handshake:
- 0-RTT + HTTP/1.1 will otherwise not pick up ServerHellos until after we send
a request. In particular, if we preconnect a 0-RTT socket sufficiently in
advance, such that the ServerHello comes in by the time we use it, we should
send 1-RTT data rather than 0-RTT.
- In TLS 1.2 False Start, if HTTP/1.1 or preconnect, we will not pick up the
server Finished and NewSessionTicket until later. This way we pick it up
sooner.
- If the server does not implement
https://boringssl-review.googlesource.com/c/boringssl/+/34948, this plugs the
theoretical deadlock on the client end. The False Start and 0-RTT scenarios
above also have theoretical deadlocks and cannot be mitigated on the server.
- TLS 1.3 client certificate alerts interact badly with TCP reset. Eagerly
reading from the socket makes it behave slightly better, though it's still
not reliable unless the server defers closing the socket.
So we can SSL_peek without triggering a renegotiation, add an
ssl_renegotiate_explicit mode to defer processing the renegotiation.
Bug: chromium:950706, chromium:958638
Change-Id: I78242d93d651b7a32a5c4c24ea9032ef63a027cf
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37944
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
1) Matches signature in internal.h
2) Works around presubmit build errors in Trusty: b/141974065
Nit: Should probably be const uint8_t *const module_hash
Change-Id: Id16ceea8442f4e8e588f84a8ef45e2320435809b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37904
Commit-Queue: Pete Bentley <prb@google.com>
Reviewed-by: Adam Langley <agl@google.com>
1458b49a9e switched to using HMAC-SHA256 for FIPS integrity checks on
Android. However, the flag file was named after a full 64-byte hex
digest. The additional 32 bytes weren't uninitialised, but are still
superfluous. This change gets rid of them.
Change-Id: I192af9eb2b94833cdea3620a153d4fd05c7265b9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37864
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
If a function forgets to BN_CTX_end, everything will work but we'll use
more memory than intended. Catch such errors by asserting in
BN_CTX_free.
Update-Note: BN_CTX is exposed publicly. Some callers may have been
using it wrong and trip this assert. If so, add the missing BN_CTX_end
calls.
Change-Id: I9c38431376a256e5176fd295c0114a10a7f588bd
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37787
Reviewed-by: Adam Langley <agl@google.com>
The Miller-Rabin test is an extension of the Fermat test (in addition to
looking for a^(n-1) != 1, it also looks for a non-trivial square root of
unity). It thus seems prudent to sanity-check we indeed reject Fermat
pseudoprimes. Euler pseudoprimes are a stronger constraint, so test
those.
Change-Id: I959769de2da3f8579403621bcf893e7c9247ca33
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37785
Reviewed-by: Adam Langley <agl@google.com>
We mostly say Miller-Rabin but sometimes say Rabin-Miller. git log -S
suggests this is mostly my fault for picking the less common order.
Miller-Rabin is also the more common order according to the internet, so
use that.
Change-Id: Id18853469a641af6d1c37d3ec87c3110e01e6b71
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37784
Reviewed-by: Adam Langley <agl@google.com>
The assembly dispatch tests currently assume NDEBUG is consistently
defined between C/C++ and assembly. While this is usually the case for
UNIX, CMake does not pass NDEBUG to NASM. This is giving gRPC some
difficulties in updating BoringSSL, so switch it to an opt-in
-DBORINGSSL_DISPATCH_TEST flag instead.
Update-Note: If you were copying NDEBUG over to assembly files, that's
no longer required (though it's harmless to leave it in). If you want to
run ImplDispatchTest.*, build both C/C++ and assembly with
-DBORINGSSL_DISPATCH_TEST in your debug builds. (Don't enable it in
release builds. It causes assembly to scribble in some globals.)
Change-Id: I9ab3371dc0f0a40b27b44ef93835e007a6346900
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37764
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
By spamming just two bytes, this fuzzer can bounce between
SSL_CTX_use_certificate and SSL_CTX_get0_certificate, which continually
runs d2i_X509 on some certificate.
Doing that nearly 400,000 times is not particularly useful. Bound the
number of API calls. Start with 10,000 and see if the fuzzers are still
unhappy.
Bug: oss-fuzz:17748
Change-Id: I074fa08475fffcb86c02e64dcb9c5c7c69bcda71
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37765
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
On Android only, assume code is compiled for Execute-only memory, so add
Read permission for the duration of the self test and
then mark the pages Execute-only again.
NB if libcrypto is not compiled for Execute-only memory, then attempting
to change the page permissions to PROT_EXEC at the start of the self
test does not cause it to fail, however changing it to PROT_NONE does.
Bug: 134580074
Test: m && flashall
Test: Manual tests described above.
Change-Id: Ibbf8405a5a9b162ce26532127aaf62c539cd9163
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37644
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
The Server Gated Cryptography EKUs are a left-over from 1990's export
regulations. For historical reaons, the SGC EKUs are accepted as a valid
substitute for a server authentication EKU, but they shouldn't be. This
change makes it so that we ignore them.
Change-Id: Ie184c52f588ae391a95d61c474ee6324bdd8f4f2
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37545
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
This file runs against the limit of ARMv7's ADR pseudo-instruction. ADR
expands to an ADD or SUB of the pc register to find an address. That
immediate must fit in ARM's encoding scheme: 8 bits of constant and 4
bits of rotation. This means larger values must be more aligned.
ARM additionally has two encodings, ARM and Thumb mode. Our assembly
files may use either encoding (do we actually need to support this?). In
ARM mode, the distances get large enough to require 16-byte alignment.
Moving constants closer to their use resolves most of this, but common
constants in _vpaes_consts are used by the whole file. Affected ADR
instructions must be placed at 8 mod 16 (the pc register is 8 ahead).
Instructions with this constraint have been commented.
For details on ARM's immediate value encoding scheme, see
https://alisdair.mcdiarmid.org/arm-immediate-value-encoding/
Update-Note: See b/141080375
Change-Id: Iadac36d800bb45901b513055fcc28a3a60f9060c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37524
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Electron builds Node.js with BoringSSL. They want to match OpenSSL as
much as possible and thus have a patch[1] that adds AES-256 CFB mode.
However, that patch makes libcrypto depend on libdecrepit, which can't
be done in general. This change lands the AES-256 CFB support in
libdecrepit without the libcrypto bit and, in order for BoringSSL to
remain consistent, without advertising support in
EVP_CIPHER_do_all_sorted. This will let Electron reduce the size of
their patch a bit.
[1] https://github.com/electron/electron/blob/master/patches/boringssl/expose_aes-cfb.patch
Change-Id: If628d22a595b354623439c587542e414e43e4045
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37264
Reviewed-by: Adam Langley <agl@google.com>
Wycheproof has a series of ECDH tests for whether we reject misspelled
explicit versions of named curves in public keys, including the wrong
cofactor. We pass those tests easily because we reject those in public
keys altogether, consistent with RFC 5480.
However, we do parse explicit curves for private keys, for compatibility
with keys produced by older OpenSSLs with unfortunate defaults. Were
that parser enabled for public keys too, we would trip some of these
Wycheproof tests because we ignore the cofactor.
Tighten the parser up. If the cofactor is not one, ignore the curve.
Also syntax-check the seed, even though we ignore it.
Change-Id: I39936e027a72d2dc5532beb2407575ad8042d4c9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37484
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
tl;dr: AES is now constant-time on 32-bit ARM with NEON. Combined with
all the past work, we now have constant-time AES and GHASH on ARM and
x86 chips, 32-bit and 64-bit, provided NEON (required by Chrome on
Android, aside from https://crbug.com/341598) or SSSE3 (almost all
Chrome on Windows users) is available!
CTR-like bsaes modes is harder to resolve than CBC decryption. They use
both bulk (ctr128_f) and one-off (block128_f) operations. We currently
use ctr128_f of bsaes and block128_f of aes_nohw (not constant-time),
which hits 22.0 MB/s on my test chip.
Implement a vpaes/bsaes hybrid to get the best of both worlds. The key
is kept in vpaes form and, when the input is large enough, we convert
the key to bsaes on-demand. This retains bsaes performance, but with no
variable-time gaps.
Alternatives considered:
- Convert to bsaes form immediately and only use bsaes. This makes the
one-off block128_f calls very expensive. One 8-block batch of
bsaes_ctr32_encrypt_blocks costs as much as 5.76 vpaes_encrypt calls.
- Do the above, but fold the one-off calls into bsaes batches because
GCM is parallelizable. This is a mess with the current internal
structure and doesn't apply to, e.g., CCM.
- Drop bsaes in favor of vpaes. However, even with
vpaes_ctr32_encrypt_blocks, vpaes is 15.5 MB/s. The hybrid is a 40%
win on an important platform.
- Try to narrow the gap, as we did for x86_64, with a "2x" optimization.
I attempted this here but the register pressure was tricky. (x86_64
was already tight and NEON can't address memory in vtbl.) If I ignored
this (gives wrong answer), the gap was still 20-25%. Perf here is
slower overall (20 MB/s for old ARM vs 120-140 MB/s for old x86_64),
so that gap is scarier.
I retained vpaes_ctr32_encrypt_blocks because it's fairly compact (only
84 bytes assembled), though it's less important in the bsaes hybrid.
Cortex-A53 (Raspberry Pi 3 Model B+)
Before:
Did 267000 AES-128-GCM (16 bytes) seal operations in 2004871us (133175.7 ops/sec): 2.1 MB/s
Did 135000 AES-128-GCM (256 bytes) seal operations in 2013825us (67036.6 ops/sec): 17.2 MB/s
Did 31000 AES-128-GCM (1350 bytes) seal operations in 2059039us (15055.6 ops/sec): 20.3 MB/s
Did 5565 AES-128-GCM (8192 bytes) seal operations in 2073607us (2683.7 ops/sec): 22.0 MB/s
Did 2709 AES-128-GCM (16384 bytes) seal operations in 2020264us (1340.9 ops/sec): 22.0 MB/s
Did 209000 AES-256-GCM (16 bytes) seal operations in 2005654us (104205.4 ops/sec): 1.7 MB/s
Did 109000 AES-256-GCM (256 bytes) seal operations in 2011293us (54194.0 ops/sec): 13.9 MB/s
Did 25000 AES-256-GCM (1350 bytes) seal operations in 2082385us (12005.5 ops/sec): 16.2 MB/s
Did 4452 AES-256-GCM (8192 bytes) seal operations in 2080729us (2139.6 ops/sec): 17.5 MB/s
Did 2226 AES-256-GCM (16384 bytes) seal operations in 2079819us (1070.3 ops/sec): 17.5 MB/s
After:
Did 542000 AES-128-GCM (16 bytes) seal operations in 2003408us (270539.0 ops/sec): 4.3 MB/s [+104.8%]
Did 124000 AES-128-GCM (256 bytes) seal operations in 2012579us (61612.5 ops/sec): 15.8 MB/s [-8.1%]
Did 30000 AES-128-GCM (1350 bytes) seal operations in 2020636us (14846.8 ops/sec): 20.0 MB/s [-1.5%]
Did 5502 AES-128-GCM (8192 bytes) seal operations in 2068807us (2659.5 ops/sec): 21.8 MB/s [-0.9%]
Did 2772 AES-128-GCM (16384 bytes) seal operations in 2085176us (1329.4 ops/sec): 21.8 MB/s [-0.9%]
Did 459000 AES-256-GCM (16 bytes) seal operations in 2003587us (229089.1 ops/sec): 3.7 MB/s [+117.6%]
Did 100000 AES-256-GCM (256 bytes) seal operations in 2018311us (49546.4 ops/sec): 12.7 MB/s [-8.6%]
Did 24000 AES-256-GCM (1350 bytes) seal operations in 2026975us (11840.3 ops/sec): 16.0 MB/s [-1.2%]
Did 4410 AES-256-GCM (8192 bytes) seal operations in 2079581us (2120.6 ops/sec): 17.4 MB/s [-0.6%]
Did 2226 AES-256-GCM (16384 bytes) seal operations in 2099318us (1060.3 ops/sec): 17.4 MB/s [-0.6%]
Bug: 256
Change-Id: Ib74ab7e63974d3ddae8ce5fc35c9b44e73dce305
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37429
Reviewed-by: Adam Langley <agl@google.com>
Adam Langley