Large memory models on x86-64 allow the code/data of a shared object /
executable to be larger than 2GiB. This is typically impossible because
x86-64 code frequently uses int32 offsets from RIP.
Consider the following program:
int getpid();
int main() {
return getpid();
}
This is turned into the following assembly under a large memory model:
.L0$pb:
leaq .L0$pb(%rip), %rax
movabsq $_GLOBAL_OFFSET_TABLE_-.L0$pb, %rcx
addq %rax, %rcx
movabsq $getpid@GOT, %rdx
xorl %eax, %eax
jmpq *(%rcx,%rdx) # TAILCALL
And, with relocations:
0: 48 8d 05 f9 ff ff ff lea -0x7(%rip),%rax # 0 <main>
7: 48 b9 00 00 00 00 00 movabs $0x0,%rcx
e: 00 00 00
9: R_X86_64_GOTPC64 _GLOBAL_OFFSET_TABLE_+0x9
11: 48 01 c1 add %rax,%rcx
14: 48 ba 00 00 00 00 00 movabs $0x0,%rdx
1b: 00 00 00
16: R_X86_64_GOT64 getpid
1e: 31 c0 xor %eax,%eax
20: ff 24 11 jmpq *(%rcx,%rdx,1)
We can see that, in the large memory model, function calls involve
loading the address of _GLOBAL_OFFSET_TABLE_ (using `movabs`, which
takes a 64-bit immediate) and then indexing into it. Both cause
relocations.
If we link the binary and disassemble we get:
0000000000001120 <main>:
1120: 48 8d 05 f9 ff ff ff lea -0x7(%rip),%rax # 1120 <main>
1127: 48 b9 e0 2e 00 00 00 movabs $0x2ee0,%rcx
112e: 00 00 00
1131: 48 01 c1 add %rax,%rcx
1134: 48 ba d8 ff ff ff ff movabs $0xffffffffffffffd8,%rdx
113b: ff ff ff
113e: 31 c0 xor %eax,%eax
1140: ff 24 11 jmpq *(%rcx,%rdx,1)
Thus the _GLOBAL_OFFSET_TABLE_ symbol is at 0x1120+0x2ee0 = 0x4000.
That's the address of the .got.plt section. But the offset “into” the
table is -0x40, putting it at 0x3fd8, in .got:
Idx Name Size VMA LMA File off Algn
18 .got 00000030 0000000000003fd0 0000000000003fd0 00002fd0 2**3
19 .got.plt 00000018 0000000000004000 0000000000004000 00003000 2**3
And, indeed, there's a dynamic relocation to setup that address:
OFFSET TYPE VALUE
0000000000003fd8 R_X86_64_GLOB_DAT getpid@GLIBC_2.2.5
Accessing data or BSS works the same: the address of the variable is
stored relative to _GLOBAL_OFFSET_TABLE_.
This is a bit of a pain because we want to delocate the module into a
single .text segment so that it moves through linking unaltered. If we
took the obvious path and built our own offset table then it would need
to contain absolute addresses, but they are only available at runtime
and .text segments aren't supposed to be run-time patched. (That's why
.rela.dyn is a separate segment.) If we use a different segment then
we have the same problem as with the original offset table: the offset
to the segment is unknown when compiling the module.
Trying to pattern match this two-step lookup to do extensive rewriting
seems fragile: I'm sure the compilers will move things around and
interleave other work in time, if they don't already.
So, in order to handle movabs trying to load _GLOBAL_OFFSET_TABLE_ we
define a symbol in the same segment, but outside of the hashed region of
the module, that contains the offset from that position to
_GLOBAL_OFFSET_TABLE_:
.boringssl_got_delta:
.quad _GLOBAL_OFFSET_TABLE_-.boringssl_got_delta
Then a movabs of $_GLOBAL_OFFSET_TABLE_-.Lfoo turns into:
movq .boringssl_got_delta(%rip), %destreg
addq $.boringssl_got_delta-.Lfoo, %destreg
This works because it's calculating
_GLOBAL_OFFSET_TABLE_ - got_delta + (got_delta - .Lfoo)
When that value is added to .Lfoo, as the original code will do, the
correct address results. Also it doesn't need an extra register because
we know that 32-bit offsets are sufficient for offsets within the
module.
As for the offsets within the offset table, we have to load them from
locations outside of the hashed part of the module to get the
relocations out of the way. Again, no extra registers are needed.
Change-Id: I87b19a2f8886bd9f7ac538fd55754e526bcf3097
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42324
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Update-Note: If an SSL_QUIC_METHOD is set, connections will now fail if
ALPN is not negotiated. This new behavior can be detected by checking
if the value of BORINGSSL_API_VERSION is greater than 10.
Bug: 294
Change-Id: I42fb80aa09268e77cec4a51e49cdad79bd72fa58
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42304
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Reason codes 1000+N correspond to receiving an alert N from the peer,
rather than observing the corresponding error condition locally. This
has generally been a source of confusion for folks.
They were originally named like SSL_R_TLSV1_ALERT_DECRYPTION_FAILED, but
OpenSSL introduced a few without the "ALERT" token in
739a543ea863682f157e9aa0ee382367eb3d187c.
We then inadvertently carried the mistake over in
SSL_R_TLSV1_UNKNOWN_PSK_IDENTITY and SSL_R_TLSV1_CERTIFICATE_REQUIRED.
Fix all these to include the "ALERT" for consistency and make it
slightly less confusing. (Although perhaps it should have been
RECEIVED_ALERT or so.) Add compatibility #defines for the original
OpenSSL ones and SSL_R_TLSV1_CERTIFICATE_REQUIRED. The latter can be
removed when downstream code is fixed. The OpenSSL ones we'll probably
just leave around.
Update-Note: The renamed alerts will log slightly different strings, but
the constants used by external code are still there.
Bug: 366
Change-Id: I30c299c4ad4b2bed695bd71d0831fbe6755975a7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42384
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
The CI should be set up to retain the Go module and build caches, so
we'll avoid downloading it multiple times. This avoids having to
replicate some code.
Update-Note: The tests now have a golang.org/x/crypto dependency. This
should be fetched transparently with Go modules. Monorepos with
different import path conventions may need to rewrite these imports.
Change-Id: If5ba52e051f180536d72109c2e690bbd13d58e7c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42044
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
clang-format now reorders includes. It used to simply sort within
blocks, but later it added a "regroup" option. The regroup option is a
bit aggressive and does not take into account our project headers being
referenced in <system/header.h> style. (It also won't be able to
recognize the header corresponding to the source file, but perhaps we
should drop that rule.)
For now, just revert it to Preserve.
Change-Id: Ief82b5c3f91c16a8def14f91ef6bf6cde502bb79
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42265
Reviewed-by: Adam Langley <agl@google.com>
We should probably ponder what to do about clang-format. That we
disagree on chains of && is a little annoying, but peppering the code
with clang-format off seems problematic.
Change-Id: I0547e4e41817e8c0b585d5fabe759ef25ed00cf7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42264
Reviewed-by: Adam Langley <agl@google.com>
This fixes a couple issues:
- Which libraries to use should be based on WIN32, not MSVC.
- Windows libraries can be specified by #pragma comment lines in the
source or by build dependencies. We specified #pragma lines in
source, but also have build dependencies in crypto_test, etc. The
latter was missing bssl.
The comment line should be sufficient, but being explicit is useful,
so fill in the missing one. This should help building with MINGW,
which is missing support for the usual Windows pragma.
Change-Id: Ide9328c7dd306738ebbb0792e47da96948fe12f4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42105
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This is partially imported from upstream's
54dbf42398e23349b59f258a3dd60387bbc5ba13 which does something similar.
In doing so, remove the pkcs8->broken field, which is a remnant of some
parsing hacks we long since removed (PKCS8_set_broken). The immediate
motivation is, if this sticks, this would make it easier to detach
i2d_PKCS8_PRIV_KEY_INFO and d2i_PKCS8_PRIV_KEY_INFO from the old ASN.1
code.
Update-Note: Direct accesses of PKCS8_PRIV_KEY_INFO now need to use the
accessors. Code search suggests no one uses the fields. Even the
accessors are virtually unused (the one thing which uses it doesn't need
it).
Bug: chromium:1102458
Change-Id: I57054de3fe412079f7387dc99291250e873b1471
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42006
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Code which targets OpenSSL won't use EVP_parse_public_key. X509_PUBKEY
is fairly deeply tied to the old ASN.1 stack, but there's no reason for
i2d_PUBKEY and friends to be. Move them to crypto/evp and reimplement as
wrappers over our functions.
Bug: chromium:1102458
Change-Id: Ic11766acdac797602e4abe1253b0efe33faef298
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42005
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Every X509 object, when parsed, would pretty-print the subject and stash
the result in x509->name. This field was removed in upstream OpenSSL and
all uses I found have now been fixed. Remove this to reduce unnecessary
work in the X.509 parser.
Update-Note: instead of x509->name, use X509_NAME_oneline and
X509_get_subject_name.
Change-Id: I1d1e69bed7429d59125a8bdea5cbba391cd1028c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41904
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Use |crypto_word_t| as the type for secret values in scalar recoding.
Use |size_t| as the type of array indexes in scalar recoding. Use
explicit casts where a larger type is (losslessly) truncated to a
smaller type. With this change, |uint64_t| is no longer used in the
p256.c when building in 32-bit mode, |unsigned| is not used in any of
the affected modules, and |uint8_t| and |char| are no longer used for
secret values in the ECC recoding.
When given the choice of doing non-array-indexing arithmetic (e.g. shifts)
on |size_t| values or |crypto_word_t| values, prefer doing it on
|crypto_word_t| values. More generally, try to use |size_t| only for
sizes and array indexes.
This is part of a bigger project to minimize the use of types other than
|crypto_word_t| for secret values. This is also part of a larger project
make the ECC code more consistent.
Avoid changing the loop indexing in the P-256 scalar multiplication from
|int| to |size_t|. The P-224 code does use |size_t| but it is less clear
than the P-256 code where |i - 1| results in a negative/underflowed
value when |i| is zero.
Change-Id: I78cb404455c2340a4f8c9688d36c0d425bfcc50b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41685
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Mid-renegotiation, there are a lot of sets of TLS parameters flying
around. We need to be clear which one we want for each operation. There
were a few parts of TLS 1.2 which were relying on SSL_get_session to
abstract between the resumption session and a new session.
Implement that separately as ssl_handshake_session, so we're free to
avoid SSL_get_session returning an incomplete session mid-renegotiation.
This doesn't fixed the linked Chromium bug, but it is necessary to do
so. (I'm trying to separate the SSL_get_session change from the
dependencies within the library.)
Update-Note: SSL_generate_key_block will now fail mid-handshake. It is
ambiguous which key block to use and, in some cases, we may not even be
able to compute the right key block.
Bug: chromium:1010748
Change-Id: I30c8a683bb506310e37adbd05a28e3b8de6e6836
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41865
Reviewed-by: Steven Valdez <svaldez@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
The const ASN1_TIME getters don't work well because some const functions
aren't marked as such. I took a pass over the header and fixed the ones
I noticed.
Change-Id: I7eede530abc14ba0aab5763561c6f2dcf09e9659
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41824
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
We'll need the accessors to be functions if we ever make X509 opaque.
Functions are also type-checked and avoid confusing code search's cross
reference features.
Update-Note: This should be compatible, but it is possible that someone,
e.g., passed in a bssl::UniquePtr<X509> to an accessor and relied on
operator->. Callers may also run afoul of const correctness. I mirrored
OpenSSL 1.1.1's consts, so it should at least be compatible with
third-party code.
Change-Id: I65dadc4e9ac0042576dc4db0f194d2e6b786ccca
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41808
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
The X509_CINF_* macros were removed before OpenSSL 1.0.2 was released
but after we forked. X509_CINF_set_modified and X509_CINF_get_signature
have some users to clean up, but these two are unused.
(OpenSSL 1.1.x's new X.509 API effectively no longer exposes X509_CINF
at all. If we could align, that would simplify switching to retaining
the full encoding rather than just TBSCertificate. But I think we'll
need to add some functions to replace a few use cases they missed.)
Update-Note: Two unused macros were removed. If there were uses, the
X509-level accessors can be used instead.
Change-Id: I9b5c7c08196885ee0bccc2658b1ad177bf3100e7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41807
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This macro dates to SSLeay. It is never used and for good reason: it
doesn't do anything. EVP_PKEY_type returns NID_undef if the NID is not
key type, but it is being passed in a signature algorithm type. This
means that, except for invalid certificates, or the rare algorithms
where the two OIDs match (Ed25519), it always returns NID_undef.
Update-Note: If there are any calls to X509_get_signature_type, remove
them. It more-or-less always returned NID_undef.
Change-Id: I6e2e41f171143c28f2afce2890f029b776cc36b5
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41806
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This checks the X.509 version is valid and consistent with fields new to
those versions. These checks are also implemented by Chromium's
certificate verifier and should be compatible.
Update-Note: The X.509 parser is now a bit stricter. This may break some
malformed certificates which were previously incorrectly accepted.
Bug: 348, 351
Change-Id: I56f35d768d5e72948d22a9546fba3d257a75f409
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41746
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This imports https://github.com/openssl/openssl/pull/10756 from upstream
with a number of changes:
- Add tests.
- Rather than blindly return false in cert_self_signed, make that
function a tri-state return. This gives better error-reporting when the
leaf certificate has a bad extension and reduces the risk of confusing
the verifier.
- Give x509v3_cache_extensions a return value rather than expecting
everyone to check EXFLAG_INVALID. Switch X509_check_purpose calls to
it when applicable.
- Rather than setting EXFLAG_INVALID on bad CRLs, fail the parse
altogether. We're already in the d2i callback. (Nothing checks
EXFLAG_INVALID on CRLs.)
- I've intentionally left the error unchecked in X509_cmp. OpenSSL's
strategy is to return -2, but that's not a consistent comparison
and may mess up sorts that depend on transitivity. This retains the
current behavior where we consider all undigestable certs as equal
to each other (modulo the opportunistic TBSCertificate double-check
which should work most of the time). This is terrible, so I've filed
https://crbug.com/boringssl/355 to track fixes here.
That last fix caught that I misread the spec when I generated
kKnownCriticalCRL and kUnknownCriticalCRL2. This fixes those and uses
the old kKnownCriticalCRL as a test for invalid extensions. (Those CRLs
were assembled by hand, so they don't indicate any software has been
encoding them wrong.)
Update-Note: The X.509 verifier now correctly rejects syntax errors in
important certificate extensions. This may break some malformed
certificates which were incorrectly accepted before.
Bug: 345
Change-Id: Ifb3a98ba62cd296920546bc718fda524bd55c024
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41745
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
If we were to accidentally leave the ticket keys zero-initialized, the
only tests that notice are DefaultTicketKeyInitialization (initial key
is not all zeros) and DefaultTicketKeyRotation (old key is not new key),
by way of querying the keys themselves.
Add some tests which additionally test the effects on resumption itself.
Change-Id: I3bfd3f1e082e3a466105dbdffa18621b81c53d17
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41564
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Fixes warning thrown when compiling digest.cc with MinGW64, by only defining PATH_MAX, if it has not yet been defined.
Else building with MinGW64, throws the following warning:
<PATH_TO_SOURCE_FOLDER>\boringssl\src\tool\digest.cc:39: warning: "PATH_MAX" redefined
39 | #define PATH_MAX MAX_PATH
|
In file included from C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/9.3.0/include-fixed/limits.h:194,
from C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/9.3.0/include-fixed/syslimits.h:7,
from C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/9.3.0/include-fixed/limits.h:34,
from C:/msys64/mingw64/x86_64-w64-mingw32/include/pthread.h:67,
from C:/msys64/mingw64/include/c++/9.3.0/x86_64-w64-mingw32/bits/gthr-default.h:35,
from C:/msys64/mingw64/include/c++/9.3.0/x86_64-w64-mingw32/bits/gthr.h:148,
from C:/msys64/mingw64/include/c++/9.3.0/ext/atomicity.h:35,
from C:/msys64/mingw64/include/c++/9.3.0/memory:73,
from <PATH_TO_SOURCE_FOLDER>/boringssl/src/include/openssl/base.h:473,
from <PATH_TO_SOURCE_FOLDER>\boringssl\src\tool\digest.cc:15:
C:/msys64/mingw64/x86_64-w64-mingw32/include/limits.h:20: note: this is the location of the previous definition
20 | #define PATH_MAX 260
|
Change-Id: I29eb33ee8fad9e4e80d9348a0d5e4057dfac620c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41705
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Windows and POSIX implement very similar fd operations, but differ
slightly:
- ssize_t in POSIX is usually int on Windows.
- POSIX needs EINTR retry loops.
- Windows wants _open rather than open, etc.
- POSIX fds and sockets are the same thing, while Windows sockets are
HANDLEs and leaves fd as a C runtime construct.
Rather than ad-hoc macros and redefinitions of ssize_t (which reportedly
upset MINGW), add some actual abstractions. While I'm here, add a scoped
file descriptor type.
That still leaves recv/send which are only used in one file, so defined
a socket_result_t for them.
Change-Id: I17fca2a50c77191f573852bfd27553996e3e9c3f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41725
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
I've left this independent of SSL_set_enforce_rsa_key_usage because
client certificates in TLS always use the digitalSignature bit, RSA or
otherwise, so it's less likely that someone has messed it up, unlike
TLS 1.2 RSA server certificates.
Update-Note: Client certificates which do not support the
digitalSignature key usage will be rejected. They should either include
that bit or omit the keyUsage extension.
Bug: 349
Change-Id: I97bbf0c8e394f219ff75b686e0c14019f6d8c9a8
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41664
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
The NIST server has been updated and is now sending a sizeConstraint of
-1 to indicate that the large-upload process isn't needed. However, the
code was trying to put that in a uint64, which caused a parse error.
Change-Id: I9ee16918df13c229b0e889fa1248eb2e0a6a5fb2
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41605
Reviewed-by: David Benjamin <davidben@google.com>
In order to efficiently track heap operations, the memory hooks may need
to store other information in the prefix area than the size that
BoringSSL uses by default. This change lets them manage the prefix how
they wish.
Change-Id: I5a4d98bed100aff2deaaabb3d23fab02f0be82aa
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41584
Reviewed-by: Adam Langley <alangley@gmail.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <alangley@gmail.com>
Commit-Queue: David Benjamin <davidben@google.com>
md_size is the size of a hash, so it cannot be zero. Add an assert since
it appears to have caused some confusion. The j >= md_size and
j -= md_size logic implicitly assumes md_size > 0. (It's another way to
stick a % md_size elsewhere which, likewise, assumes md_size > 0.)
The bug report itself is a false positive, but locally documenting
assumptions is good.
Bug: chromium:1092697
Change-Id: I3be0992552a300c6786cf1dc5ecfa881173a42e6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41544
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
There are a decent number of uses of this function directly. I've
attached this to bug 338. Arguably it makes it worse, though it does
help with aligning on ctr32, if that works out.
Bug: 338
Change-Id: I3dfc1305d359ec0c88d4f298fe1928bef7ec9877
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41426
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
AES_ctr128_encrypt, in particular, has a decent number of external
callers but is completely untested. I haven't included
AES_cfb128_encrypt because its EVP_CIPHER counterpart is tested in
decrept_test. But the EVP_CIPHER counterpart simply calls
AES_cfb128_encrypt, so it's tested transitively.
Change-Id: I0133dbd5b13c2b4045a89a04f29240008a279186
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41425
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
The previous implementation was too strict in its byte-for-byte equality
check including Transport Parameters, because the Transport Parameters
contain a field that QUIC requires be different on each connection. This
change still has BoringSSL do a byte-for-byte check, but now it is only
done over the quic_early_data_context. An additional requirement is
imposed that the quic_early_data_context must be set for early data
capable tickets to be issued.
Bug: 295
Change-Id: I5145c10752b41908b6807c3a3c967653b0c13f37
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41427
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Also update the documentation for RAND_enable_fork_unsafe_buffering. The
fd parameter is no longer used.
Update-Note: RAND_set_urandom_fd no longer exists. This was only called
by Chromium, which now uses CRYPTO_pre_sandbox_init.
Change-Id: I1659c1cc84a6f1edc01f6105fc07e80856e457fc
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41424
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Syscall-filtering sandboxes may make getrandom fail without crashing.
This will sometimes trigger the /dev/urandom fallback and sometimes not.
Change-Id: Ic824e5bfe6fcb99105fd285184243c4620447327
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41404
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
If BoringSSL is used in a sandbox without /proc/cpuinfo, we will
silently act as if the CPU is missing capabilities, even though
getauxval may be available. We use /proc/cpuinfo to work around a
missing AT_HWCAP2 and ignore a particular broken CPU.
Ignoring the former fails closed, so it's safe to proceed. The latter
fails closed, but it is now vanishingly rare (even missing AT_HWCAP2 has
largely dropped off), so instead proceed with getauxval. This makes the
/proc paths largely optional.
Change-Id: Ib198c4f78ccdae874d55669b6a7508dfbeac0f44
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41325
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Before:
Did 19655000 SHA-1 (16 bytes) operations in 2000053us (157.2 MB/sec)
Did 5112000 SHA-1 (256 bytes) operations in 2000126us (654.3 MB/sec)
Did 1280000 SHA-1 (1350 bytes) operations in 2000559us (863.8 MB/sec)
Did 229000 SHA-1 (8192 bytes) operations in 2004784us (935.7 MB/sec)
Did 116000 SHA-1 (16384 bytes) operations in 2008224us (946.4 MB/sec)
After:
Did 20506000 SHA-1 (16 bytes) operations in 2000062us (164.0 MB/sec) [+4.3%]
Did 5659000 SHA-1 (256 bytes) operations in 2000100us (724.3 MB/sec) [+10.7%]
Did 1454000 SHA-1 (1350 bytes) operations in 2000739us (981.1 MB/sec) [+13.6%]
Did 255000 SHA-1 (8192 bytes) operations in 2000733us (1044.1 MB/sec) [+11.6%]
Did 129000 SHA-1 (16384 bytes) operations in 2009483us (1051.8 MB/sec) [+11.1%]
Change-Id: Idaf75e92b2da4d83b597771aca1123f2884d7687
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41284
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
The small P-256 tables currently store 2 * 16 points in Jacobian
coordinates, but all the Z values are one, except for the two entries
which store infinity. Instead, store only affine coordinates and omit
the infinity entries. (We can recover infinity with constant-time
selects.)
This trims 1152 bytes from the table. Comparing the sizes of the bssl
tool (stripped, otherwise debug symbols undo the size gain), the binary
is 4096 bytes smaller, but I suspect this is just an artifact of
something rounding to page sizes.
Along the way, I've scripted the table generation and merged it into a
much generalized version of make_p256-x86_64-table.go.
As a bonus, by cutting the size of the table we scan, it's faster!
(ECDSA verify was already not scanning a table, so that one staying the
same is expected.)
Before:
Did 22302 ECDH P-256 operations in 4009795us (5561.9 ops/sec)
Did 62000 ECDSA P-256 signing operations in 4020075us (15422.6 ops/sec)
Did 26544 ECDSA P-256 verify operations in 4056526us (6543.5 ops/sec)
After:
Did 23001 ECDH P-256 operations in 4016544us (5726.6 ops/sec) [+3.0%]
Did 66000 ECDSA P-256 signing operations in 4043083us (16324.2 ops/sec) [+5.8%]
Did 26544 ECDSA P-256 verify operations in 4051220us (6552.1 ops/sec) [+0.1%]
Change-Id: Ie88898fd56e57505e3a325c50bbaf0dc5d42eeb3
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41164
Reviewed-by: Steven Valdez <svaldez@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
The input points are all public, so we can use a faster multi-scalar
multiplication. This generalizes ec_point_mul_scalar_public to
ec_point_mul_scalar_public_batch. To support the batched DLEQ
construction, this function takes an arbirarily-length array of points
and allocates some temporaries if necessary.
First, to confirm that this doesn't affect the basic ECDSA verify case:
Before:
Did 6324 ECDSA P-384 verify operations in 3069342us (2060.4 ops/sec)
After:
Did 6324 ECDSA P-384 verify operations in 3063355us (2064.4 ops/sec) [+0.2%]
Results for Trust Tokens issue (Exp1) and finish_issuance (both):
Before:
Did 147 TrustToken-Exp0-Batch1 finish_issuance operations in 2059145us (71.4 ops/sec)
Did 14 TrustToken-Exp0-Batch10 finish_issuance operations in 2085888us (6.7 ops/sec)
Did 357 TrustToken-Exp1-Batch1 issue operations in 2068238us (172.6 ops/sec)
Did 286 TrustToken-Exp1-Batch1 finish_issuance operations in 2090932us (136.8 ops/sec)
Did 63 TrustToken-Exp1-Batch10 issue operations in 2068201us (30.5 ops/sec)
Did 56 TrustToken-Exp1-Batch10 finish_issuance operations in 2064796us (27.1 ops/sec)
After:
Did 168 TrustToken-Exp0-Batch1 finish_issuance operations in 2058891us (81.6 ops/sec) [+14.3%]
Did 16 TrustToken-Exp0-Batch10 finish_issuance operations in 2075742us (7.7 ops/sec) [+14.8%]
Did 378 TrustToken-Exp1-Batch1 issue operations in 2067956us (182.8 ops/sec) [+5.9%]
Did 336 TrustToken-Exp1-Batch1 finish_issuance operations in 2097757us (160.2 ops/sec) [+17.1%]
Did 105 TrustToken-Exp1-Batch10 issue operations in 2069934us (50.7 ops/sec) [+66.5%]
Did 88 TrustToken-Exp1-Batch10 finish_issuance operations in 2014621us (43.7 ops/sec) [+61.1%]
(This CL doesn't affect other operations.)
Change-Id: Ie643b06f44990ab52bf892a007732fde61cdffe5
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41285
Reviewed-by: Steven Valdez <svaldez@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Before:
Did 867 TrustToken-Exp1-Batch1 generate_key operations in 1029740us (842.0 ops/sec)
Did 1441 TrustToken-Exp1-Batch1 begin_issuance operations in 1021088us (1411.2 ops/sec)
Did 200 TrustToken-Exp1-Batch1 issue operations in 1003145us (199.4 ops/sec)
Did 154 TrustToken-Exp1-Batch1 finish_issuance operations in 1053858us (146.1 ops/sec)
Did 5128000 TrustToken-Exp1-Batch1 begin_redemption operations in 1000076us (5127610.3 ops/sec)
Did 517 TrustToken-Exp1-Batch1 redeem operations in 1031054us (501.4 ops/sec)
Did 15000 TrustToken-Exp1-Batch1 finish_redemption operations in 1041906us (14396.7 ops/sec)
Did 870 TrustToken-Exp1-Batch10 generate_key operations in 1020929us (852.2 ops/sec)
Did 154 TrustToken-Exp1-Batch10 begin_issuance operations in 1085963us (141.8 ops/sec)
Did 20 TrustToken-Exp1-Batch10 issue operations in 1040995us (19.2 ops/sec)
Did 14 TrustToken-Exp1-Batch10 finish_issuance operations in 1009041us (13.9 ops/sec)
Did 5138000 TrustToken-Exp1-Batch10 begin_redemption operations in 1000114us (5137414.3 ops/sec)
Did 528 TrustToken-Exp1-Batch10 redeem operations in 1026978us (514.1 ops/sec)
Did 15000 TrustToken-Exp1-Batch10 finish_redemption operations in 1016920us (14750.4 ops/sec)
After:
Did 900 TrustToken-Exp1-Batch1 generate_key operations in 1032678us (871.5 ops/sec) [+3.5%]
Did 1410 TrustToken-Exp1-Batch1 begin_issuance operations in 1004439us (1403.8 ops/sec) [-0.5%]
Did 154 TrustToken-Exp1-Batch1 issue operations in 1068370us (144.1 ops/sec) [-27.7%]
Did 121 TrustToken-Exp1-Batch1 finish_issuance operations in 1048767us (115.4 ops/sec) [-21.0%]
Did 5179000 TrustToken-Exp1-Batch1 begin_redemption operations in 1000159us (5178176.7 ops/sec) [+1.0%]
Did 572 TrustToken-Exp1-Batch1 redeem operations in 1093354us (523.2 ops/sec) [+4.3%]
Did 15000 TrustToken-Exp1-Batch1 finish_redemption operations in 1001506us (14977.4 ops/sec) [+4.0%]
Did 913 TrustToken-Exp1-Batch10 generate_key operations in 1027546us (888.5 ops/sec) [+4.3%]
Did 154 TrustToken-Exp1-Batch10 begin_issuance operations in 1051530us (146.5 ops/sec) [+3.3%]
Did 26 TrustToken-Exp1-Batch10 issue operations in 1027599us (25.3 ops/sec) [+31.7%]
Did 24 TrustToken-Exp1-Batch10 finish_issuance operations in 1055615us (22.7 ops/sec) [+63.9%]
Did 5100000 TrustToken-Exp1-Batch10 begin_redemption operations in 1000201us (5098975.1 ops/sec) [-0.7%]
Did 561 TrustToken-Exp1-Batch10 redeem operations in 1072683us (523.0 ops/sec) [+1.7%]
Did 15000 TrustToken-Exp1-Batch10 finish_redemption operations in 1006697us (14900.2 ops/sec) [+1.0%]
Change-Id: Ibdc08f9d63e62dda14a2cd9e9d8be27c8723675b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40865
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
QUIC imposes additional restrictions on when 0-RTT data can be accepted.
With this change, a QUIC server configured to support 0-RTT will only
accept early data if the transport parameters and application protocol
specific context are a byte-for-byte match from the original connection
to the 0-RTT resumption attempt.
Bug: 295
Change-Id: Ie5d4688d1c9076b49f2131bb66b27c87e2ba041a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41145
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Several of the Trust Tokens multiplications use repeated points (G, H,
and the public keys). We can precompute a 5-bit comb for those points
and perform only 1/5th as many doubles in the multiplication.
Before:
Did 483 TrustToken-Exp0-Batch1 generate_key operations in 2017082us (239.5 ops/sec)
Did 1449 TrustToken-Exp0-Batch1 begin_issuance operations in 2086097us (694.6 ops/sec)
Did 176 TrustToken-Exp0-Batch1 issue operations in 2089640us (84.2 ops/sec)
Did 147 TrustToken-Exp0-Batch1 finish_issuance operations in 2027924us (72.5 ops/sec)
Did 12284000 TrustToken-Exp0-Batch1 begin_redemption operations in 2000151us (6141536.3 ops/sec)
Did 483 TrustToken-Exp0-Batch1 redeem operations in 2063241us (234.1 ops/sec)
Did 35000 TrustToken-Exp0-Batch1 finish_redemption operations in 2050694us (17067.4 ops/sec)
Did 483 TrustToken-Exp0-Batch10 generate_key operations in 2003222us (241.1 ops/sec)
Did 138 TrustToken-Exp0-Batch10 begin_issuance operations in 2000845us (69.0 ops/sec)
Did 16 TrustToken-Exp0-Batch10 issue operations in 2010264us (8.0 ops/sec)
Did 14 TrustToken-Exp0-Batch10 finish_issuance operations in 2036137us (6.9 ops/sec)
Did 12106000 TrustToken-Exp0-Batch10 begin_redemption operations in 2000126us (6052618.7 ops/sec)
Did 483 TrustToken-Exp0-Batch10 redeem operations in 2062366us (234.2 ops/sec)
Did 35000 TrustToken-Exp0-Batch10 finish_redemption operations in 2023617us (17295.8 ops/sec)
Did 1254 TrustToken-Exp1-Batch1 generate_key operations in 2086776us (600.9 ops/sec)
Did 3612 TrustToken-Exp1-Batch1 begin_issuance operations in 2052090us (1760.2 ops/sec)
Did 420 TrustToken-Exp1-Batch1 issue operations in 2002421us (209.7 ops/sec)
Did 378 TrustToken-Exp1-Batch1 finish_issuance operations in 2078074us (181.9 ops/sec)
Did 12843000 TrustToken-Exp1-Batch1 begin_redemption operations in 2000068us (6421281.7 ops/sec)
Did 1210 TrustToken-Exp1-Batch1 redeem operations in 2083419us (580.8 ops/sec)
Did 35000 TrustToken-Exp1-Batch1 finish_redemption operations in 2023704us (17295.0 ops/sec)
Did 1239 TrustToken-Exp1-Batch10 generate_key operations in 2060962us (601.2 ops/sec)
Did 357 TrustToken-Exp1-Batch10 begin_issuance operations in 2031131us (175.8 ops/sec)
Did 42 TrustToken-Exp1-Batch10 issue operations in 2045185us (20.5 ops/sec)
Did 36 TrustToken-Exp1-Batch10 finish_issuance operations in 2028604us (17.7 ops/sec)
Did 12435000 TrustToken-Exp1-Batch10 begin_redemption operations in 2000084us (6217238.9 ops/sec)
Did 1176 TrustToken-Exp1-Batch10 redeem operations in 2023934us (581.0 ops/sec)
Did 35000 TrustToken-Exp1-Batch10 finish_redemption operations in 2002899us (17474.7 ops/sec)
After:
Did 875 TrustToken-Exp0-Batch1 generate_key operations in 2028222us (431.4 ops/sec) [+80.2%]
Did 1449 TrustToken-Exp0-Batch1 begin_issuance operations in 2097298us (690.9 ops/sec) [-0.5%]
Did 207 TrustToken-Exp0-Batch1 issue operations in 2083578us (99.3 ops/sec) [+18.0%]
Did 147 TrustToken-Exp0-Batch1 finish_issuance operations in 2018783us (72.8 ops/sec) [+0.5%]
Did 12020250 TrustToken-Exp0-Batch1 begin_redemption operations in 2000036us (6010016.8 ops/sec) [-2.1%]
Did 525 TrustToken-Exp0-Batch1 redeem operations in 2077137us (252.8 ops/sec) [+8.0%]
Did 35000 TrustToken-Exp0-Batch1 finish_redemption operations in 2006257us (17445.4 ops/sec) [+2.2%]
Did 903 TrustToken-Exp0-Batch10 generate_key operations in 2091846us (431.7 ops/sec) [+79.0%]
Did 138 TrustToken-Exp0-Batch10 begin_issuance operations in 2006432us (68.8 ops/sec) [-0.3%]
Did 19 TrustToken-Exp0-Batch10 issue operations in 2000665us (9.5 ops/sec) [+19.3%]
Did 14 TrustToken-Exp0-Batch10 finish_issuance operations in 2045846us (6.8 ops/sec) [-0.5%]
Did 12124000 TrustToken-Exp0-Batch10 begin_redemption operations in 2000055us (6061833.3 ops/sec) [+0.2%]
Did 525 TrustToken-Exp0-Batch10 redeem operations in 2076637us (252.8 ops/sec) [+7.9%]
Did 35000 TrustToken-Exp0-Batch10 finish_redemption operations in 2000072us (17499.4 ops/sec) [+1.2%]
Did 2142 TrustToken-Exp1-Batch1 generate_key operations in 2031447us (1054.4 ops/sec) [+75.5%]
Did 3633 TrustToken-Exp1-Batch1 begin_issuance operations in 2073265us (1752.3 ops/sec) [-0.4%]
Did 504 TrustToken-Exp1-Batch1 issue operations in 2043677us (246.6 ops/sec) [+17.6%]
Did 378 TrustToken-Exp1-Batch1 finish_issuance operations in 2086624us (181.2 ops/sec) [-0.4%]
Did 12548250 TrustToken-Exp1-Batch1 begin_redemption operations in 2000020us (6274062.3 ops/sec) [-2.3%]
Did 1281 TrustToken-Exp1-Batch1 redeem operations in 2067790us (619.5 ops/sec) [+6.7%]
Did 35000 TrustToken-Exp1-Batch1 finish_redemption operations in 2012117us (17394.6 ops/sec) [+0.6%]
Did 2184 TrustToken-Exp1-Batch10 generate_key operations in 2069977us (1055.1 ops/sec) [+75.5%]
Did 357 TrustToken-Exp1-Batch10 begin_issuance operations in 2041930us (174.8 ops/sec) [-0.5%]
Did 50 TrustToken-Exp1-Batch10 issue operations in 2063927us (24.2 ops/sec) [+18.0%]
Did 36 TrustToken-Exp1-Batch10 finish_issuance operations in 2038115us (17.7 ops/sec) [-0.5%]
Did 12693000 TrustToken-Exp1-Batch10 begin_redemption operations in 2000070us (6346277.9 ops/sec) [+2.1%]
Did 1281 TrustToken-Exp1-Batch10 redeem operations in 2066940us (619.8 ops/sec) [+6.7%]
Did 35000 TrustToken-Exp1-Batch10 finish_redemption operations in 2020506us (17322.4 ops/sec) [-0.9%]
Change-Id: Id26600c07401d6567275155aa389839ac0e87013
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41124
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
With multi-scalar multiplication, we're stuck pondering the doubling
case. But it's fine for trust tokens, because the points are independent
and the scalars are uniformly generated and not under attacker control.
That means the probability of hitting a double is negligible. (It's
equivalent to accidentally finding the discrete log of two independent
points.)
Before:
Did 306 TrustToken-Exp0-Batch1 generate_key operations in 2000725us (152.9 ops/sec)
Did 1428 TrustToken-Exp0-Batch1 begin_issuance operations in 2080325us (686.4 ops/sec)
Did 105 TrustToken-Exp0-Batch1 issue operations in 2070658us (50.7 ops/sec)
Did 88 TrustToken-Exp0-Batch1 finish_issuance operations in 2023864us (43.5 ops/sec)
Did 12283000 TrustToken-Exp0-Batch1 begin_redemption operations in 2000063us (6141306.5 ops/sec)
Did 315 TrustToken-Exp0-Batch1 redeem operations in 2084451us (151.1 ops/sec)
Did 35000 TrustToken-Exp0-Batch1 finish_redemption operations in 2024388us (17289.2 ops/sec)
Did 315 TrustToken-Exp0-Batch10 generate_key operations in 2045481us (154.0 ops/sec)
Did 138 TrustToken-Exp0-Batch10 begin_issuance operations in 2022158us (68.2 ops/sec)
Did 10 TrustToken-Exp0-Batch10 issue operations in 2148640us (4.7 ops/sec)
Did 8 TrustToken-Exp0-Batch10 finish_issuance operations in 2047452us (3.9 ops/sec)
Did 12167000 TrustToken-Exp0-Batch10 begin_redemption operations in 2000118us (6083141.1 ops/sec)
Did 315 TrustToken-Exp0-Batch10 redeem operations in 2084853us (151.1 ops/sec)
Did 35000 TrustToken-Exp0-Batch10 finish_redemption operations in 2014997us (17369.8 ops/sec)
Did 777 TrustToken-Exp1-Batch1 generate_key operations in 2034967us (381.8 ops/sec)
Did 3612 TrustToken-Exp1-Batch1 begin_issuance operations in 2052618us (1759.7 ops/sec)
Did 264 TrustToken-Exp1-Batch1 issue operations in 2084327us (126.7 ops/sec)
Did 220 TrustToken-Exp1-Batch1 finish_issuance operations in 2024603us (108.7 ops/sec)
Did 12691000 TrustToken-Exp1-Batch1 begin_redemption operations in 2000111us (6345147.8 ops/sec)
Did 777 TrustToken-Exp1-Batch1 redeem operations in 2070867us (375.2 ops/sec)
Did 35000 TrustToken-Exp1-Batch1 finish_redemption operations in 2019118us (17334.3 ops/sec)
Did 798 TrustToken-Exp1-Batch10 generate_key operations in 2090816us (381.7 ops/sec)
Did 357 TrustToken-Exp1-Batch10 begin_issuance operations in 2032751us (175.6 ops/sec)
Did 25 TrustToken-Exp1-Batch10 issue operations in 2046353us (12.2 ops/sec)
Did 21 TrustToken-Exp1-Batch10 finish_issuance operations in 2015579us (10.4 ops/sec)
Did 12695000 TrustToken-Exp1-Batch10 begin_redemption operations in 2000126us (6347100.1 ops/sec)
Did 740 TrustToken-Exp1-Batch10 redeem operations in 2032413us (364.1 ops/sec)
Did 35000 TrustToken-Exp1-Batch10 finish_redemption operations in 2011564us (17399.4 ops/sec)
After:
Did 483 TrustToken-Exp0-Batch1 generate_key operations in 2003131us (241.1 ops/sec) [+57.7%]
Did 1449 TrustToken-Exp0-Batch1 begin_issuance operations in 2089317us (693.5 ops/sec) [+1.0%]
Did 176 TrustToken-Exp0-Batch1 issue operations in 2094210us (84.0 ops/sec) [+65.7%]
Did 147 TrustToken-Exp0-Batch1 finish_issuance operations in 2006750us (73.3 ops/sec) [+68.5%]
Did 12217000 TrustToken-Exp0-Batch1 begin_redemption operations in 2000094us (6108212.9 ops/sec) [-0.5%]
Did 483 TrustToken-Exp0-Batch1 redeem operations in 2058132us (234.7 ops/sec) [+55.3%]
Did 35000 TrustToken-Exp0-Batch1 finish_redemption operations in 2026970us (17267.2 ops/sec) [-0.1%]
Did 504 TrustToken-Exp0-Batch10 generate_key operations in 2086204us (241.6 ops/sec) [+56.9%]
Did 144 TrustToken-Exp0-Batch10 begin_issuance operations in 2084670us (69.1 ops/sec) [+1.2%]
Did 16 TrustToken-Exp0-Batch10 issue operations in 2008793us (8.0 ops/sec) [+71.1%]
Did 14 TrustToken-Exp0-Batch10 finish_issuance operations in 2033577us (6.9 ops/sec) [+76.2%]
Did 12026000 TrustToken-Exp0-Batch10 begin_redemption operations in 2000018us (6012945.9 ops/sec) [-1.2%]
Did 483 TrustToken-Exp0-Batch10 redeem operations in 2056418us (234.9 ops/sec) [+55.5%]
Did 35000 TrustToken-Exp0-Batch10 finish_redemption operations in 2046766us (17100.1 ops/sec) [-1.6%]
Did 1239 TrustToken-Exp1-Batch1 generate_key operations in 2060737us (601.2 ops/sec) [+57.5%]
Did 3675 TrustToken-Exp1-Batch1 begin_issuance operations in 2085293us (1762.3 ops/sec) [+0.1%]
Did 420 TrustToken-Exp1-Batch1 issue operations in 2008121us (209.2 ops/sec) [+65.1%]
Did 378 TrustToken-Exp1-Batch1 finish_issuance operations in 2077226us (182.0 ops/sec) [+67.5%]
Did 12783000 TrustToken-Exp1-Batch1 begin_redemption operations in 2000134us (6391071.8 ops/sec) [+0.7%]
Did 1197 TrustToken-Exp1-Batch1 redeem operations in 2056802us (582.0 ops/sec) [+55.1%]
Did 35000 TrustToken-Exp1-Batch1 finish_redemption operations in 2030955us (17233.3 ops/sec) [-0.6%]
Did 1260 TrustToken-Exp1-Batch10 generate_key operations in 2095507us (601.3 ops/sec) [+57.5%]
Did 357 TrustToken-Exp1-Batch10 begin_issuance operations in 2029693us (175.9 ops/sec) [+0.2%]
Did 42 TrustToken-Exp1-Batch10 issue operations in 2050856us (20.5 ops/sec) [+67.6%]
Did 36 TrustToken-Exp1-Batch10 finish_issuance operations in 2027488us (17.8 ops/sec) [+70.4%]
Did 12140000 TrustToken-Exp1-Batch10 begin_redemption operations in 2000070us (6069787.6 ops/sec) [-4.4%]
Did 1210 TrustToken-Exp1-Batch10 redeem operations in 2079615us (581.8 ops/sec) [+59.8%]
Did 34000 TrustToken-Exp1-Batch10 finish_redemption operations in 2052918us (16561.8 ops/sec) [-4.8%]
Change-Id: Idd51d7e1d18f3b94edc4105e68fd50b5f44d87cd
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41104
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
The DLEQ and DLEQOR proofs require converting many Jacobian points to
affine, some multiple times. The inversions involved can be batched.
This buys us a +5-8% improvement in token issuance speed. issue and
finish_issue should each only perform two inversions per token now. We
could save an inversion per token by changing the dleq_generate and
dleq_verify function signatures, but that would complicate the likely
more valuable batched DLEQ(OR) optimization, so I've left those alone.
Before:
Did 300 TrustToken-Exp0-Batch1 generate_key operations in 2031798us (147.7 ops/sec)
Did 1449 TrustToken-Exp0-Batch1 begin_issuance operations in 2093639us (692.1 ops/sec)
Did 96 TrustToken-Exp0-Batch1 issue operations in 2044310us (47.0 ops/sec)
Did 84 TrustToken-Exp0-Batch1 finish_issuance operations in 2072137us (40.5 ops/sec)
Did 12170000 TrustToken-Exp0-Batch1 begin_redemption operations in 2000098us (6084701.8 ops/sec)
Did 315 TrustToken-Exp0-Batch1 redeem operations in 2091938us (150.6 ops/sec)
Did 35000 TrustToken-Exp0-Batch1 finish_redemption operations in 2004900us (17457.2 ops/sec)
Did 308 TrustToken-Exp0-Batch10 generate_key operations in 2067860us (148.9 ops/sec)
Did 138 TrustToken-Exp0-Batch10 begin_issuance operations in 2005706us (68.8 ops/sec)
Did 9 TrustToken-Exp0-Batch10 issue operations in 2107753us (4.3 ops/sec)
Did 8 TrustToken-Exp0-Batch10 finish_issuance operations in 2193489us (3.6 ops/sec)
Did 12046750 TrustToken-Exp0-Batch10 begin_redemption operations in 2000025us (6023299.7 ops/sec)
Did 315 TrustToken-Exp0-Batch10 redeem operations in 2091940us (150.6 ops/sec)
Did 35000 TrustToken-Exp0-Batch10 finish_redemption operations in 2008851us (17422.9 ops/sec)
Did 756 TrustToken-Exp1-Batch1 generate_key operations in 2051005us (368.6 ops/sec)
Did 3633 TrustToken-Exp1-Batch1 begin_issuance operations in 2072577us (1752.9 ops/sec)
Did 242 TrustToken-Exp1-Batch1 issue operations in 2052091us (117.9 ops/sec)
Did 210 TrustToken-Exp1-Batch1 finish_issuance operations in 2058740us (102.0 ops/sec)
Did 12477000 TrustToken-Exp1-Batch1 begin_redemption operations in 2000004us (6238487.5 ops/sec)
Did 777 TrustToken-Exp1-Batch1 redeem operations in 2084953us (372.7 ops/sec)
Did 35000 TrustToken-Exp1-Batch1 finish_redemption operations in 2028286us (17255.9 ops/sec)
Did 756 TrustToken-Exp1-Batch10 generate_key operations in 2051178us (368.6 ops/sec)
Did 357 TrustToken-Exp1-Batch10 begin_issuance operations in 2041875us (174.8 ops/sec)
Did 23 TrustToken-Exp1-Batch10 issue operations in 2026494us (11.3 ops/sec)
Did 20 TrustToken-Exp1-Batch10 finish_issuance operations in 2048478us (9.8 ops/sec)
Did 12492000 TrustToken-Exp1-Batch10 begin_redemption operations in 2000053us (6245834.5 ops/sec)
Did 777 TrustToken-Exp1-Batch10 redeem operations in 2084956us (372.7 ops/sec)
Did 36000 TrustToken-Exp1-Batch10 finish_redemption operations in 2021991us (17804.2 ops/sec)
After:
Did 315 TrustToken-Exp0-Batch1 generate_key operations in 2046638us (153.9 ops/sec) [+4.2%]
Did 1449 TrustToken-Exp0-Batch1 begin_issuance operations in 2087930us (694.0 ops/sec) [+0.3%]
Did 105 TrustToken-Exp0-Batch1 issue operations in 2071104us (50.7 ops/sec) [+8.0%]
Did 88 TrustToken-Exp0-Batch1 finish_issuance operations in 2023502us (43.5 ops/sec) [+7.3%]
Did 11847000 TrustToken-Exp0-Batch1 begin_redemption operations in 2000041us (5923378.6 ops/sec) [-2.7%]
Did 315 TrustToken-Exp0-Batch1 redeem operations in 2084116us (151.1 ops/sec) [+0.4%]
Did 35000 TrustToken-Exp0-Batch1 finish_redemption operations in 2003732us (17467.4 ops/sec) [+0.1%]
Did 315 TrustToken-Exp0-Batch10 generate_key operations in 2046863us (153.9 ops/sec) [+3.3%]
Did 138 TrustToken-Exp0-Batch10 begin_issuance operations in 2000108us (69.0 ops/sec) [+0.3%]
Did 10 TrustToken-Exp0-Batch10 issue operations in 2149283us (4.7 ops/sec) [+9.0%]
Did 8 TrustToken-Exp0-Batch10 finish_issuance operations in 2046416us (3.9 ops/sec) [+7.2%]
Did 12112000 TrustToken-Exp0-Batch10 begin_redemption operations in 2000077us (6055766.9 ops/sec) [+0.5%]
Did 315 TrustToken-Exp0-Batch10 redeem operations in 2084427us (151.1 ops/sec) [+0.4%]
Did 35000 TrustToken-Exp0-Batch10 finish_redemption operations in 2015111us (17368.8 ops/sec) [-0.3%]
Did 777 TrustToken-Exp1-Batch1 generate_key operations in 2029777us (382.8 ops/sec) [+3.9%]
Did 3654 TrustToken-Exp1-Batch1 begin_issuance operations in 2093484us (1745.4 ops/sec) [-0.4%]
Did 252 TrustToken-Exp1-Batch1 issue operations in 2024557us (124.5 ops/sec) [+5.5%]
Did 220 TrustToken-Exp1-Batch1 finish_issuance operations in 2034633us (108.1 ops/sec) [+6.0%]
Did 12659000 TrustToken-Exp1-Batch1 begin_redemption operations in 2000112us (6329145.6 ops/sec) [+1.5%]
Did 777 TrustToken-Exp1-Batch1 redeem operations in 2073783us (374.7 ops/sec) [+0.5%]
Did 35000 TrustToken-Exp1-Batch1 finish_redemption operations in 2050371us (17070.1 ops/sec) [-1.1%]
Did 768 TrustToken-Exp1-Batch10 generate_key operations in 2025482us (379.2 ops/sec) [+2.9%]
Did 357 TrustToken-Exp1-Batch10 begin_issuance operations in 2034429us (175.5 ops/sec) [+0.4%]
Did 25 TrustToken-Exp1-Batch10 issue operations in 2049293us (12.2 ops/sec) [+7.5%]
Did 21 TrustToken-Exp1-Batch10 finish_issuance operations in 2022256us (10.4 ops/sec) [+6.4%]
Did 12702000 TrustToken-Exp1-Batch10 begin_redemption operations in 2000015us (6350952.4 ops/sec) [+1.7%]
Did 777 TrustToken-Exp1-Batch10 redeem operations in 2072048us (375.0 ops/sec) [+0.6%]
Did 35000 TrustToken-Exp1-Batch10 finish_redemption operations in 2024580us (17287.5 ops/sec) [-2.9%]
Change-Id: Ia1b09cd14aa8ce0935d18033fb4bd75666a258e9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41086
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
The DLEQ logic needs to convert many points to affine coordinates at the
Hc computations. Rearrange things so the two happen concurrently, which
will allow us to batch the inversions.
Change-Id: I09bb053788f1555547272bf9af19b54e0fe7c325
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41085
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
PMBTokens ends up converting the same point to affine coordinates
repeatedly. Additionally, it converts many affine coordinates at once,
which we can batch. Introduce an EC_AFFINE type to store affine points
and move the inversion to the Jacobian -> affine conversion.
This does mean we lose the (negligible) Montgomery reduction
optimization in EC_GFp_mont. point_get_affine_coordinates no longer
breaks the EC_FELEM abstraction around Montgomery form.
Unfortunately, this complicates hardening of the callers not checking
return values because EC_AFFINE cannot represent the point at infinity
and, due to OpenSSL's API limitations, groups may not have generators
available and the generator is not affine at the type level. (EC_AFFINE
cannot represent the point at infinity.) Thus this CL:
- Tidies up some duplicate code in setting up the generator and ensures
it always has Z = 1.
- ec_point_set_affine_coordinates hardens against unused results if the
generator is configured. But this is ultimately an internal function.
- Retains the hardening on the public APIs by adding calls to
ec_set_to_safe_point in two places.
This CL does not apply the optimization to Trust Tokens, only introduces
the EC_AFFINE abstraction. It additionally continues to store EC_POINTs
(used in ECDH and ECDSA) in Jacobian form. See
https://crbug.com/boringssl/326#c4 for a discussion on why this is
tricky. Those protocols are hopefully simple enough that they don't need
complexity around inversions.
Having an EC_AFFINE type will also be useful for computing custom tables
for Trust Token public keys, which gives a nice speedup.
Bug: 326
Change-Id: I11b010a33f36a15bac9939351df5205bd35cc665
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41084
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
This starts a new branch of the protocol using P-384 and draft-07 of
hash-to-curve. Mark it unstable for now as we aim to add batching and
other fixes.
Did 154 TrustToken-Exp0-Batch1 generate_key operations in 1033312us (149.0 ops/sec)
Did 748 TrustToken-Exp0-Batch1 begin_issuance operations in 1078707us (693.4 ops/sec)
Did 48 TrustToken-Exp0-Batch1 issue operations in 1030056us (46.6 ops/sec)
Did 44 TrustToken-Exp0-Batch1 finish_issuance operations in 1092816us (40.3 ops/sec)
Did 6040750 TrustToken-Exp0-Batch1 begin_redemption operations in 1000009us (6040695.6 ops/sec)
Did 154 TrustToken-Exp0-Batch1 redeem operations in 1023722us (150.4 ops/sec)
Did 18000 TrustToken-Exp0-Batch1 finish_redemption operations in 1021087us (17628.3 ops/sec)
Did 154 TrustToken-Exp0-Batch10 generate_key operations in 1032878us (149.1 ops/sec)
Did 72 TrustToken-Exp0-Batch10 begin_issuance operations in 1050908us (68.5 ops/sec)
Did 4 TrustToken-Exp0-Batch10 issue operations in 1051989us (3.8 ops/sec)
Did 4 TrustToken-Exp0-Batch10 finish_issuance operations in 1214996us (3.3 ops/sec)
Did 5987000 TrustToken-Exp0-Batch10 begin_redemption operations in 1000068us (5986592.9 ops/sec)
Did 154 TrustToken-Exp0-Batch10 redeem operations in 1037898us (148.4 ops/sec)
Did 18000 TrustToken-Exp0-Batch10 finish_redemption operations in 1024788us (17564.6 ops/sec)
Did 396 TrustToken-Exp1-Batch1 generate_key operations in 1060955us (373.2 ops/sec)
Did 1925 TrustToken-Exp1-Batch1 begin_issuance operations in 1093039us (1761.1 ops/sec)
Did 121 TrustToken-Exp1-Batch1 issue operations in 1022292us (118.4 ops/sec)
Did 110 TrustToken-Exp1-Batch1 finish_issuance operations in 1076011us (102.2 ops/sec)
Did 6322000 TrustToken-Exp1-Batch1 begin_redemption operations in 1000144us (6321089.8 ops/sec)
Did 407 TrustToken-Exp1-Batch1 redeem operations in 1087774us (374.2 ops/sec)
Did 18000 TrustToken-Exp1-Batch1 finish_redemption operations in 1031736us (17446.3 ops/sec)
Did 407 TrustToken-Exp1-Batch10 generate_key operations in 1090415us (373.3 ops/sec)
Did 187 TrustToken-Exp1-Batch10 begin_issuance operations in 1065754us (175.5 ops/sec)
Did 11 TrustToken-Exp1-Batch10 issue operations in 1005738us (10.9 ops/sec)
Did 10 TrustToken-Exp1-Batch10 finish_issuance operations in 1066494us (9.4 ops/sec)
Did 6302000 TrustToken-Exp1-Batch10 begin_redemption operations in 1000029us (6301817.2 ops/sec)
Did 407 TrustToken-Exp1-Batch10 redeem operations in 1087692us (374.2 ops/sec)
Did 18000 TrustToken-Exp1-Batch10 finish_redemption operations in 1014611us (17740.8 ops/sec)
Change-Id: I7ea9a8ab8ad48acfbf50026e251cc6e1d5b8ba7f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41069
Reviewed-by: Steven Valdez <svaldez@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
For now, it does nothing. This will make it easier to transition between
versions of the experiment while the protocol evolves.
Update-Note: Pass TRUST_TOKEN_experiment_v0() into any existing code
that now needs a TRUST_TOKEN_METHOD.
Change-Id: I434e18c794ab30545e367eb902e434e6311b7497
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41066
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
fork_detect needs to know whether |MADV_WIPEONFORK| is supported by the
kernel or not. However, current versions of qemu ignore madvise calls
and just return zero, making it seems like it's supported when it's
actually not. Therefore, try an madvise with -1 to ensure that clearly
bogus values actually produce and error before trusting the result of
calling with |MADV_WIPEONFORK|.
Change-Id: I7f72714d5794274acabd0bee0b0ac470e1933774
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41024
Reviewed-by: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
This reduces the number of places that know about the group and allows
us to abstract between different PMBTokens variations. Although the
abstraction isn't quite clean with the key_id in the TRUST_TOKEN
serialization, so we may need to ponder this.
Change-Id: Ia892340057025794aaf7c44a64c4d195a969715f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41065
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
The number of tokens is inconsistent throughout the API. max_batchsize
is a uint16_t. max_issuance is a size_t. out_tokens_issued is a
uint8_t*. The serialization only supports up to uint16_t.
Standardize on size_t. The natural size for a count of elements is
size_t. Protocol limitations can be handled within the implementation.
Additionally, it is best not to use small types for counters in public
APIs in C/C++ because the language has implicit truncating conversions.
(Whereas code points or other enum-like values are fine because the
caller won't managed to get a 32-bit cipher suite.)
Update-Note: Fix callers of TRUST_TOKEN_ISSUER_issue to use size_t
instead of uint8_t. The max_batchsize changes should go through without
changes to the caller.
Change-Id: I9be5dd8f61abdbe5a1dbe70b8dc72d06114b1022
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41044
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
Leave the P-521 one alone as it's part of the current trust token
experiment. But suffix all the functions by their draft until everything
stabilizes. Also remove the ref_for_testing function since we can cite
the fixed test vectors from the upstream PR.
Change-Id: Ied89d26848c8ec1f6e8414a2385d9f3e491d7fb2
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41067
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
Files in the top-level of fipsmodule/ are considered be FIPS-support
files by generate_build_files.py. However, fork_detect is different.
Rather than have more special cases in the support scripts, this change
moves fork_detect into fipsmodule/rand. It's not a perfect fit, and
maybe it could have been its own directory, but it's not bad and fixes
the build for now.
Change-Id: I875088dd458069190dade870e085865e1306f55a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40964
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Linux 4.14 and up support MADV_WIPEONFORK, which can be used to reliably
and efficiently detect forks. Use it to harden the PRNG and RSA blinding
caches.
On the RSA side, we currently cache blinding values. (Alas, removing the cache
gives a *very* noticeable perf hit. There is some low-hanging fruit to trim a
few Montgomery reductions, but it didn't offset much last I toyed with it.)
Now, on Linux 4.14 and up, this cache is fork-safe.
Since not all platforms that support fork also support fork detection,
this should only be used as a hardening measure. Now, when detection is
present, BoringSSL will skip doing per-call entropy draws from the
kernel. (This might regress protection against VM cloning when no fast
RDRAND is available. However, we need to do something for AMD machines.
Hypervisors that clone VMs are going to need to signal the kernel to
wipe WIPEONFORK pages.)
Upgrade-Note: BoringSSL now calls some more syscalls on Linux. If this offends
sandboxes, let us know. We can loosen the sandbox or add a mechanism to prime
the MADV_WIPEONFORK page before entering it.
Change-Id: I6ba43951aeaa2b9b81f74f9e5a7a0ce2de0438a4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/34745
Reviewed-by: Adam Langley <alangley@gmail.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Switch to the addition chains by Brian Smith in
https://briansmith.org/ecc-inversion-addition-chains-01#p256_field_inversion
The new addition chains are a bit faster when measured independently.
They aren't, however, noticeable when measured with everything else in
ECDH. Rather, the motivation is just to align fiat_p256, nistz256, and a
possible future fiat_p384 import.
Since it's free, I've included the (negligible) z^-2 optimization, but
if we ever want a z^-1 abstraction, it doesn't actually matter. In the
meantime, it replaces the (even more negligible) Montgomery conversion
optimization which is a bit less odd on the EC_FELEM abstraction. (I'm
pondering whether we want an EC_AFFINE abstraction given how the Trust
Tokens DLEQ proofs work.)
fiat_p256 (64-bit):
Before:
Did 539000 P-256 get x operations in 5007148us (107646.1 ops/sec)
Did 532000 P-256 get x and y operations in 5008736us (106214.4 ops/sec)
After:
Did 607000 P-256 get x operations in 5005225us (121273.3 ops/sec)
Did 594000 P-256 get x and y operations in 5001251us (118770.3 ops/sec)
nistz256:
Before:
Did 1472000 P-256 get x operations in 5003286us (294206.6 ops/sec)
Did 1445000 P-256 get x and y operations in 5002052us (288881.4 ops/sec)
After:
Did 1491000 P-256 get x operations in 5002524us (298049.5 ops/sec)
Did 1452000 P-256 get x and y operations in 5003193us (290214.7 ops/sec)
I haven't bothered checking in the benchmarks as those operations
standalone are largely artificial. They're a consequence of using the
same type for affine and Jacobian points.
Change-Id: I71e0d50a8712198f9cb8f68d50894d14a6091635
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40867
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Originally, when we imported fiat-crypto field operations, the pipeline
was in early stages and the generated code had to be manually integrated
with the rest of the curve implementation, so we moved all our
supporting code to third_party/fiat for simplicity. Over time more
supporting code, like the table generators, landed there to be next to
its callers.
fiat-crypto now generates standalone files which we #include into the
supporting code. This moves the supporting code back to the usual
location. It also updates the README.md file to reflect the new
pipeline. (Most of it was a documentation of the old pipeline, which was
much more manual.)
Change-Id: I64db7235feb6566f0d3cd4db3a7146050edaf25a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40904
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
We really need a better ECDH API in the first place, but ECDH would not
extract the y-coordinate which saves a couple multiplications. (This is
entirely unnoticeable between everything else going on in ECDH.)
Change-Id: I663554577b0cfc373067f9db4d2116a3dfbf1478
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40866
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
This pulls in the latest upstream files and reapplies our value_barrier patch.
In particular, https://github.com/mit-plv/fiat-crypto/pull/723 made 64-bit
P-256 faster!
32-bit x86, gcc
Before:
Did 3150 ECDH P-256 operations in 4027477us (782.1 ops/sec)
Did 9912 ECDSA P-256 signing operations in 4067212us (2437.1 ops/sec)
Did 3772 ECDSA P-256 verify operations in 4059197us (929.2 ops/sec)
Did 74800 Ed25519 key generation operations in 4020883us (18602.9 ops/sec)
Did 74000 Ed25519 signing operations in 4001827us (18491.6 ops/sec)
Did 21371 Ed25519 verify operations in 4024606us (5310.1 ops/sec)
Did 78000 Curve25519 base-point multiplication operations in 4051574us (19251.8 ops/sec)
Did 25133 Curve25519 arbitrary point multiplication operations in 4063280us (6185.4 ops/sec)
After:
Did 3250 ECDH P-256 operations in 4025179us (807.4 ops/sec) [+3.2%]
Did 10277 ECDSA P-256 signing operations in 4084926us (2515.8 ops/sec) [+3.2%]
Did 3895 ECDSA P-256 verify operations in 4048734us (962.0 ops/sec) [+3.5%]
Did 74480 Ed25519 key generation operations in 4002460us (18608.6 ops/sec) [+0.0%]
Did 74000 Ed25519 signing operations in 4004425us (18479.6 ops/sec) [-0.1%]
Did 21756 Ed25519 verify operations in 4038856us (5386.7 ops/sec) [+1.4%]
Did 78000 Curve25519 base-point multiplication operations in 4031991us (19345.3 ops/sec) [+0.5%]
Did 25133 Curve25519 arbitrary point multiplication operations in 4064925us (6182.9 ops/sec) [-0.0%]
x86_64, clang, OPENSSL_SMALL
Before:
Did 20090 ECDH P-256 operations in 4019408us (4998.2 ops/sec)
Did 56000 ECDSA P-256 signing operations in 4004370us (13984.7 ops/sec)
Did 23562 ECDSA P-256 verify operations in 4062283us (5800.2 ops/sec)
Did 127000 Ed25519 key generation operations in 4005053us (31709.9 ops/sec)
Did 128000 Ed25519 signing operations in 4021902us (31825.7 ops/sec)
Did 71000 Ed25519 verify operations in 4036015us (17591.6 ops/sec)
Did 132000 Curve25519 base-point multiplication operations in 4002101us (32982.7 ops/sec)
Did 93000 Curve25519 arbitrary point multiplication operations in 4023827us (23112.3 ops/sec)
After:
Did 22263 ECDH P-256 operations in 4005099us (5558.7 ops/sec) [+11.2%]
Did 61000 ECDSA P-256 signing operations in 4024810us (15156.0 ops/sec) [+8.4%]
Did 27426 ECDSA P-256 verify operations in 4038547us (6791.1 ops/sec) [+17.1%]
Did 128000 Ed25519 key generation operations in 4015033us (31880.2 ops/sec) [+0.5%]
Did 127000 Ed25519 signing operations in 4003894us (31719.1 ops/sec) [-0.3%]
Did 70000 Ed25519 verify operations in 4017446us (17424.0 ops/sec) [-1.0%]
Did 132000 Curve25519 base-point multiplication operations in 4006282us (32948.3 ops/sec) [-0.1%]
Did 93000 Curve25519 arbitrary point multiplication operations in 4025190us (23104.5 ops/sec) [-0.0%]
Change-Id: I2f705772899c701480ca0e0885e6b75dd1bb1f5d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40746
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This only matters on malloc failure and I think, even then,
EVP_DigestInit_ex will only fail the first time around the loop so it
wouldn't actually leak anything. Nonetheless, that should be a goto err.
Change-Id: Ieea9db387f9c16915c3a0026c6fd48036da2cfef
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40748
Reviewed-by: Steven Valdez <svaldez@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
We need a constant-time point equality for two reasons. First, although
multiplication results are usually public, their Jacobian Z coordinates
may be secret, or at least are not obviously public. Second, more
complex protocols will sometimes manipulate secret points, notably
PMBTokens.
While here I've renamed the inner function to points_equal without the
flipped return value, to be less confusing.
Update-Note: This does mean that we pay a 6M+2S Jacobian comparison
where comparing two publicly affine points should cost no field
operations at all. Code which compares two EC public keys for equality
will be slightly slower. I wouldn't expect this to matter (if you
actually use the public keys, you'll pay much much more) If it does, we
can restore this optimization by keeping better track of affine vs.
Jacobian forms. See https://crbug.com/boringssl/326.
Bug: 326, chromium:1014199
Change-Id: I67c9a56bc9b66f30c0b500a29e8bf90427d89061
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40665
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
DLEQ proofs for PMBTokens need a random oracle over scalars as well as
field elements. (Interestingly, draft-irtf-cfrg-voprf-03 section 5.1
does not specify as strong of requirements, but then their reference
implementation does rejection sampling, so it's unclear.)
Reusing the hash_to_field operation so hash calls use the domain
separation tag consistently with other hash-to-curve operations seems
prudent, so implement a companion function until the actual construction
solidifies.
Change-Id: I92d807bfddcca26db690cce0a3da551143c25ff3
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40646
Reviewed-by: Steven Valdez <svaldez@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
While we could store an extra boolean along with each session in the
session cache and then disable early data on a per-socket level, that
causes SSL_early_data_reason to report confusing values. Clearing it
at the session seems simpler. Since sessions are intended to be
mutable, do this as a copy operation.
Bug: chromium:1066623
Change-Id: I599b1559b696805e330ab5c2d61e4158440daef8
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40464
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Doing a Jacobian point-on-curve check has negligible cost compared to
the point operations. We may as well perform one to add some defense
against potential bugs and such. (We already double-check RSA
operations.)
Before:
Did 40000 ECDH P-224 operations in 3014872us (13267.6 ops/sec)
Did 55000 ECDH P-256 operations in 3026351us (18173.7 ops/sec)
Did 3410 ECDH P-384 operations in 3053181us (1116.9 ops/sec)
Did 1364 ECDH P-521 operations in 3079656us (442.9 ops/sec)
Did 83000 ECDSA P-224 signing operations in 3013476us (27542.9 ops/sec)
Did 41000 ECDSA P-224 verify operations in 3073530us (13339.7 ops/sec)
Did 168000 ECDSA P-256 signing operations in 3008562us (55840.6 ops/sec)
Did 60000 ECDSA P-256 verify operations in 3038517us (19746.5 ops/sec)
Did 6169 ECDSA P-384 signing operations in 3066741us (2011.6 ops/sec)
Did 6231 ECDSA P-384 verify operations in 3054468us (2040.0 ops/sec)
Did 2418 ECDSA P-521 signing operations in 3058901us (790.5 ops/sec)
Did 2418 ECDSA P-521 verify operations in 3048765us (793.1 ops/sec)
After:
Did 39600 ECDH P-224 operations in 3001966us (13191.4 ops/sec)
Did 55000 ECDH P-256 operations in 3033098us (18133.3 ops/sec)
Did 3441 ECDH P-384 operations in 3088436us (1114.2 ops/sec)
Did 1364 ECDH P-521 operations in 3087711us (441.8 ops/sec)
Did 83000 ECDSA P-224 signing operations in 3029486us (27397.4 ops/sec)
Did 40000 ECDSA P-224 verify operations in 3005452us (13309.1 ops/sec)
Did 168000 ECDSA P-256 signing operations in 3011387us (55788.2 ops/sec)
Did 60000 ECDSA P-256 verify operations in 3030343us (19799.7 ops/sec)
Did 6076 ECDSA P-384 signing operations in 3023469us (2009.6 ops/sec)
Did 6231 ECDSA P-384 verify operations in 3056138us (2038.8 ops/sec)
Did 2418 ECDSA P-521 signing operations in 3057375us (790.9 ops/sec)
Did 2449 ECDSA P-521 verify operations in 3083418us (794.2 ops/sec)
Change-Id: Icedc51e340c8f3a21f96a535395814575e0c89b2
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40592
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
511S + 3M isn't even enough operations to get up to 2^519-1. I dropped a
a bunch of terms. (We can get up to 2^512-1 with 511S + 9M. Then an
additional 7S + 3M finishes it up.)
Change-Id: Ibb1bc3491dfb09ab8a917498e99deb66e4894cf0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40644
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This function (by way of EC_POINT_is_on_curve) is used by callers in two
places:
- To check the affine result of decoding a point. (This is no longer
necessary because we'll always do it internally, but folks still do
it.)
- To check the Jacobian result of a multiplication as fault protection.
(Tink does this. We should probably do it in the library.)
That function's implementations of affine and Jacobian checks are mostly
constant-time, but branching between the two isn't. Since the difference
is small (2S + 1M vs 2S + 3M) compared to what one would be doing with
an affine point (point multiplication), this probably isn't worth
worrying about. Conservatively do the Jacobian check so folks like Tink
aren't accidentally introducing side channels.
Change-Id: I3140167868e027004906293df547add43ae40552
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40590
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This implements hash-to-curve for P-521, which is needed by the
PMBTokens construction in https://eprint.iacr.org/2020/072.pdf. It is
only an internal function for now, operating on EC_RAW_POINT, so that
PMBTokens can avoid allocating EC_POINTs everywhere. If we ever have a
need to expose this outside, we can add an EC_POINT wrapper (hopefully
by then the draft will be stable).
Note this implements two versions of the function due to a spec issue in
P521_XMD:SHA-512_SSWU_RO_. One of them only exists to test against the
original test vectors. See
https://github.com/cfrg/draft-irtf-cfrg-hash-to-curve/issues/237
Bug: chromium:1014199
Change-Id: I7207d1bcb8b20f7111c2ffb40e2794ad2d3d0000
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40589
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
We seek to incorporate entropy into every |RAND_bytes| call to avoid
problems with fork() and VM cloning. However, on some chips, RDRAND is
significantly slower than a system call thus crushing the performance of
|RAND_bytes|.
This change disables use of RDRAND for this opportunistic draw for
non-Intel chips. BoringSSL will then fall back to either the OS, or
nothing (if fork-unsafe mode has been set).
RDRAND is still used for seeding the PRNG whenever it is available.
This now adds a new blocking case: RDRAND may be used for seeding, but
the syscall to get additional_data was still blocking. Previously that
didn't matter because, if a syscall was used to get additional_data,
then a blocking one had already been used to seed. Thus the syscall for
additional_data is now non-blocking.
Also, we had both |hwrand| and |rdrand| names hanging around. We don't
support entropy instructions other than RDRAND, so unify around |rdrand|
naming. If we ever do add support for more we can properly abstract at
that time.
Change-Id: I91121b270a2ebc667543dad1324f37285daad893
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40565
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Montgomery reduction works when the input is at most N*R (N^2 is a
tighter bound that's easier to describe and usually suffices). This is
useful when reducing product-sized values. In particular,
hash-to-curve's hash_to_field function requires a reduction. Generalize
this so we can implement it with Montgomery reduction.
Bug: chromium:1014199
Change-Id: I1a07f9b94823742384a98c0c6fecdedfe5240b7b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40588
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Compressed coordinates still use BIGNUM. I've moved the curve check to
an EC_FELEM-based ec_point_set_affine_coordinates and implemented a
tighter one than ec_GFp_simple_is_on_curve, which currently needs to
branch on Jacobian vs. affine and potentially leaks information. (A
later CL will make it conservatively always perform a Jacobian check.)
The Trust Tokens implementation will eventually need to deserialize
points, so this avoids needing to allocate EC_POINTs everywhere.
Likewise if we ever get around to adding a better ECDH, this will let us
avoid pulling in BIGNUMs.
Bug: chromium:1014199, 242
Change-Id: I93162ba3680d38cb3c0eacff1eb8f42a445246ea
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40587
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
group_set_curve is called when instantiating the built-in curves and
when creating arbitrary curves. The former has non-NULL BN_CTXs and
fully reduced inputs. Move the logic for this to the deprecated
EC_GROUP_new_curve_GFp function so it can be dropped from most binaries.
Change-Id: I5ff60d6d51acb79fbcb32588e6324a5b2627b6d2
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40544
Reviewed-by: Adam Langley <agl@google.com>
This fixes two issues. First, we have been lax about whether the
low-level inversion functions fail on zero input or output zero. Fix the
documentation and call the latter inv0 or inverse0 to match the
terminology used in draft-irtf-cfrg-hash-to-curve. (Although we may not
actually need inv0 given the optimization in D.2.)
This has no actual effect because the functions were only used in
contexts where the inputs were already guaranteed to be non-zero. Still,
we should be consistent here.
Second, ec_scalar_inv_montgomery and ec_scalar_inv_montgomery_vartime
claim to perform the same operation, but they do not. First, one
computed inv0 and the other computed inv (except only in some
implementations, so fix it to be consistent). Second, the former
computes inverses in the Montgomery domain, while the latter converts to
the Montgomery domain and then inverts. Rename it to
ec_scalar_to_montgomery_inv_vartime, which is... questionably
understandable but at least looks different.
Change-Id: I9b4829ce5013bdb9528078a093f41b1b158df265
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40526
Reviewed-by: Adam Langley <agl@google.com>
When running ABI tests on an AVX2-enabled system, they flag the
ChaCha20-Poly1305 assembly. The issue appears pretty simple: the code
has chunks of code after the mainline `ret` instruction the there's a
CFI directive that undoes the adjustments for restoring registers, but
it only accounts for six saved registers and there are actually seven.
At least, with this, the ABI tests are happy.
Change-Id: Ia6d1d89f564148db43852b245916a8c2cdfb1e6b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40564
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
These come from OpenSSL 1.1.1. I don't think any third-party code is
using them yet, but OpenSSL 1.1.0 is EOL, so newer code may use them and
they're much more convenient when porting over existing uses of DH and
DSA.
Bug: 325
Change-Id: I767496da4b458a3871dea23a1405b1e7e40b3de5
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40484
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Instead of checking d * e = 1 (mod lcm(p-1, q-1)), we can separately
check d * e = 1 (mod p-1) and d * e = 1 (mod q-1). This drops an LCM
dependency from key import and is 2x faster.
(Our constant-time LCM implementation can probably be faster if we
tried, but now it's only used in RSA keygen, so it doesn't matter much.
It's also using the unoptimized constant-time division, which is
probably the next target if we decide we care about speeding this up.)
Before:
Did 6768 RSA 2048 checking operations in 3015824us (2244.2 ops/sec)
Did 5610 RSA 2048 signing operations in 3033396us (1849.4 ops/sec)
Did 1953 RSA 4096 checking operations in 3060828us (638.1 ops/sec)
Did 817 RSA 4096 signing operations in 3021092us (270.4 ops/sec)
After:
Did 13175 RSA 2048 checking operations in 3090576us (4263.0 ops/sec)
Did 5610 RSA 2048 signing operations in 3032966us (1849.7 ops/sec)
Did 3720 RSA 4096 checking operations in 3085971us (1205.5 ops/sec)
Did 820 RSA 4096 signing operations in 3027312us (270.9 ops/sec)
Bug: 316
Change-Id: Ie29554c02d31f586dd0f8bdee03a227f1d5dc916
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40146
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This function does not need to be so complex. The bulk of
the work is done by bn_sub_words. The unrolled loop is only used when
bn_sub_part_words is called in different-length inputs.
bn_sub_part_words is itself only called from bn_abs_sub_consttime and
bn_mul_part_recursive. bn_abs_sub_consttime is used to compute p - q in
RSA key generation so it never sees different-width inputs.
bn_mul_part_recursive is called from bn_mul_impl if all of the following
are true:
- Both inputs are at least 16 words long (1024 bits on 64-bit platforms
and 512 bits on 32-bit).
- The two inputs are within one word from each other.
- The length of the larger input is one more than a power of two.
The first condition rules out all EC configurations except P-521 on
32-bit platforms. The EC code uses bn_mul_mont assembly if available, so
this only affects non-x86 and non-ARM 32-bit architectures. Building for
32-bit x86 without assembly shows no significant change:
Before:
Did 88 ECDH P-521 operations in 1014591us (86.7 ops/sec)
Did 165 ECDSA P-521 signing operations in 1066428us (154.7 ops/sec)
Did 150 ECDSA P-521 verify operations in 1001749us (149.7 ops/sec)
After:
Did 90 ECDH P-521 operations in 1045905us (86.0 ops/sec)
Did 165 ECDSA P-521 signing operations in 1071189us (154.0 ops/sec)
Did 154 ECDSA P-521 verify operations in 1050509us (146.6 ops/sec)
RSA does meet the first condition, but the third condition rules out all
common RSA sizes, with one quirk: RSA_check_key uses the non-normalized
BIGNUMs, but RSA_check_key is not called as part of private key
operations. (https://crbug.com/boringssl/316 discusses what to do about
RSA longer term. It's kind of a mess right now.)
Bug: 314
Change-Id: I0bd604e2cd6a75c266f64476c23a730ca1721ea6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40145
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This is the getter counterpart to |SSL_CTX_set_chain_and_key|. There's
no |SSL*| because a) we didn't need it and b) then you have to worry
about config discarding and it doesn't end up being very useful.
Change-Id: Iba75d0165d7e555d0f793687b1f5e1e6c6f7c738
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40264
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
set_write_state flushes buffered handshake data, and we should finish
writing to a level before moving on to the next one.
I've moved the callback into set_{read,write}_state to ensure we still
update read_level and write_level after installing secrets, since that's
how we decide what level to write things and we should never write
alerts with keys we don't have. (I believe the only way this can come up
is if the QUIC callback itself fails, but it still seems prudent to
defer updating the levels.)
This does unfortunately mean a goofy secret_for_quic parameter, though
it is arguably more "correct" in that QUIC would ideally be a third
SSL_PROTOCOL_METHOD, rather than escape hatches over TLS. Probably a
cleaner abstraction would be for set_read_state and set_write_state to
take the secret and derive an SSLAEADContext internally.
Update-Note: See b/151142920#comment9
Change-Id: I4bbb76e15b5d95615ea643bccf796db87fae4989
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40244
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
Our server code (unfortunately) conditions its transport parameters
based on the client's transport parameters. Instead of using
hs->config->quic_transport_params to check whether QUIC is in use, this
replaces it with ssl->quic_method.
Change-Id: I6817e9f674a70f4568b0c469c96dfdf1c1c91709
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40224
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Trust Token is a new protocol to issue and redeem provably anonymized
tokens. To allow for development of key storage/management for Trust
Token, this CL provides the function to generate Trust Token keys.
Bug: chromium:1014199
Change-Id: If764e027b202f07be13c64f7be66dfaff71c45e7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40064
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
The original API separated when keys were exported to QUIC from when
they were "active". This means the obligations on QUIC are unclear. For
instance we added SSL_quic_read_level and SSL_quic_write_level to
capture when keys were active, yet QUICHE never used them anyway. It
would be better to defer releasing keys to when they are needed.
In particular, we should align our API with the guidelines in
https://github.com/quicwg/base-drafts/issues/3173.
This means we need separate read and write callbacks, which
unfortunately means the invariants around ACKs must now be covered in
prose.
We'll likely remove SSL_quic_read_level and SSL_quic_write_level in a
later CL as QUIC has no need to know this anymore. (It should simply
feed handshake data to BoringSSL as it sees it and, if we reject it,
report a suitably error.) The notion of a "current" encryption level is
a little odd given the interaction between 0-RTT and
ServerHello..Finished ACKs.
Update-Note: This is an incompatible change to SSL_QUIC_METHOD.
BORINGSSL_API_VERSION can be used to distinguish the two revisions.
Bug: 303
Change-Id: I6c9dca1ae156d26a80c366a4ba969dcb04e65349
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40127
Reviewed-by: Nick Harper <nharper@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This change does two things. First, it funnels the transition out of
0-RTT into one function so that, later, when QUIC releases keys in
set_(read|write)_state, we can handle the QUIC quirks better.
Second, it switches to handshake (or initial) keys as soon as 0-RTT is
closed. In particular, if EncryptedExtensions reports a 0-RTT reject, we
switch keys before processing Certificate. This way, if we then reject
the server certificate, we send the alert with keys the server can read.
If there is an error in EncryptedExtensions or earlier, we do not know
whether the server is expecting 0-RTT-encrypted alerts or
handshake-encrypted alerts, so we cannot reliably send an alert. This is
fine because all such error cases are server implementation bugs and
alerts are purely a debugging courtesy. However, after a 0-RTT reject,
we may reject the Certificate message due to local policy, in which case
the certificate error alerts make more sense.
Bug: 303
Change-Id: I4c4bc9c8ab2c2ecb89e20141518e1b7ea7b39af3
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40125
Reviewed-by: Steven Valdez <svaldez@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
The assembly only existed for 32-bit x86, which is much less relevant
these days. It's also just a pile of ADDs, ADCs, etc., which compilers
should be able to figure out by now.
This frees us up to clean up that function, including the weird cl/dl
calling convention. No noticeable difference in RSA benchmarks:
Before:
Did 224 RSA 2048 signing operations in 1006100us (222.6 ops/sec)
Did 9240 RSA 2048 verify (same key) operations in 1078563us (8567.0 ops/sec)
Did 8541 RSA 2048 verify (fresh key) operations in 1064996us (8019.7 ops/sec)
Did 32 RSA 4096 signing operations in 1052851us (30.4 ops/sec)
Did 2365 RSA 4096 verify (same key) operations in 1093337us (2163.1 ops/sec)
Did 2222 RSA 4096 verify (fresh key) operations in 1090037us (2038.5 ops/sec)
After:
Did 231 RSA 2048 signing operations in 1018908us (226.7 ops/sec)
Did 9394 RSA 2048 verify (same key) operations in 1095548us (8574.7 ops/sec)
Did 8525 RSA 2048 verify (fresh key) operations in 1062449us (8023.9 ops/sec)
Did 32 RSA 4096 signing operations in 1050236us (30.5 ops/sec)
Did 2376 RSA 4096 verify (same key) operations in 1098509us (2162.9 ops/sec)
Did 2233 RSA 4096 verify (fresh key) operations in 1094724us (2039.8 ops/sec)
Bug: 314
Change-Id: I86a27b2550ab8bec2a9930cc509f4c29d6036b35
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40144
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
This is a little bit of internal cleanup. The original intent was so
QUIC could install secrets in set_(read|write)_state, but that was
somewhat annoying, so I've left it just before the call for now.
There is one TLS 1.3 state transition which doesn't carry an encryption
level: switching from 0-RTT keys back to unencrypted on an HRR-based
0-RTT reject. The TCP code doesn't care about write_level and the QUIC
code is currently fine because we never "install" the 0-RTT keys. But we
should get this correct.
This also opens the door for DTLS 1.3, if we ever implement it, because
DTLS 1.3 will need to know which level it is to handle 0-RTT keys funny.
(Clients sending 0-RTT will briefly have handshake and 0-RTT write keys
active simultaneously.)
QUIC has the same property, but we can fudge it because only the caller
is aware of this.
Change-Id: Ia76d787e1b96a058d9818948b6d9a051e8592207
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40124
Reviewed-by: Steven Valdez <svaldez@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
The urandom test added in 3e502c84f0 assumed that __NR_getrandom was
defined by the system's headers, but urandom.c doesn't. This change
pulls the fills for that system call into a common header that's used by
both.
Change-Id: I71c3b9bfa69c34b320e724a4c977cd63163cbdec
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40067
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
The SDE bot has started developing flakes with that many threads.
(Unclear if it is due to SDE or running too many copies of the test
in parallel.)
Change-Id: I0081b6d75882b946bdccee5405dc688d0035d565
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40066
Reviewed-by: Adam Langley <agl@google.com>
Servers can only accept 0-RTT if the ciphers match. If they reject
0-RTT, however, they may change the cipher suite and even the PRF hash.
This is tricky, however, because the 0-RTT accept or reject signal comes
in EncryptedExtensions, which is *after* the new cipher suite is
installed. (Although a client could infer 0-RTT is rejected based on the
cipher suite if it wanted.)
While we correctly handled the PRF hash switch, we get the cipher suite
mixed up due to dependency on SSL_get_session and incorrectly decrypt
EncryptedExtensions. Fix this and add some tests.
Change-Id: Ia20f2ed665cf601d30a38f0c8d4786c4c111019f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40005
Reviewed-by: Steven Valdez <svaldez@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
There's no need to treat the 1-RTT and 0-RTT handback flows differently.
This aligns the 1-RTT handback with the 0-RTT point. This consistently
installs the decryption keys in the state machine after handback rather
than while applying the handback.
Update-Note: This changes the serialization format for TLS 1.3 split
handshakes, which were only just added.
Change-Id: I0e109cb8d9ecd3c8658dfa26059cbe0139f82eed
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39988
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Matt Braithwaite <mab@google.com>
The TLS handshake runs over a sequence of messages, serialized onto a
stream, which is then packetized into records, with no correlation to
message boundaries.
TLS messages may span records, so a TLS implementation will buffer up
excess data in a record for the next message. If not checked, that next
message may a round-trip or even a key change later. Carrying data
across a key change has security consequences, so we reject any excess
data across key changes (see ChangeCipherSpec synchronization tests and
(d)tls_set_read_state). However, we do not currently check it across
network round trips that do not change keys.
For instance, a TLS 1.2 client may pack part of ClientKeyExchange (the
first byte, at least, is deterministic) into the ClientHello record,
before even receiving ServerHello. Most TLS implementations will accept
this.
However, the handback logic does *not* serialize excess data in hs_buf.
There shouldn't be any, but if the peer is doing strange things as
above, that data will get silently dropped. The way TLS 1.3 0-RTT
handback logic works (the key isn't installed until after handback),
this data is even silently dropped though there is a key change.
To keep all our behavior consistent, check for unprocessed handshake
data at the end of each flight and reject it. Add a bunch of tests.
Update-Note: If the peer packs data across handshake flights, or packs
HelloRequest into the same record as Finished, this will now be an
error. (The former is pathologically odd behavior. The latter is also
rejected by Schannel and also odd.)
Change-Id: I9412bbdea09ee7fdcfeb78d3456329505a190641
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39987
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
It is impossible for us to have an unconsumed ChangeCipherSpec message
in dtls_has_unprocessed_handshake_data.
dtls_has_unprocessed_handshake_data is only called in
dtls1_set_read_state and, in DTLS 1.2 and earlier, we only ever switch
the cipher state immediately after consuming ChangeCipherSpec.
Remove this because later commits will check
has_unprocessed_handshake_data in more places and we have a test
(StrayChangeCipherSpec) which asserts we do tolerate arbitrarily early
ChangeCipherSpecs messages.
There may be something to be said for rejecting this (the peer would
have to be doing something weird and sending ChangeCipherSpec in the
wrong flight), but ChangeCipherSpec in DTLS is predictable and
informationless, so this is probably not worth worrying about.
Change-Id: I1bc2952c0ba5231a7f962b9f7ca4c63271ec079f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39986
Reviewed-by: Adam Langley <agl@google.com>
Some of the TLS-specific functions begin with ssl3_, otherwise with
tls_. Align on tls_ since we don't implement SSL 3.0 anymore. (Plain ssl_
means common to TLS and DTLS, which is an odd backronym, but SSL_foo for
the APIs are thoroughly stuck.)
Change-Id: Ib7acffd21ee370bb9bed46789fb511d00fac24ca
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39985
Reviewed-by: Adam Langley <agl@google.com>
This helps to clarify where SSL_set_early_data_enabled() needs to be
called: in the shim tests it was being set everywhere, which concealed
the fact that the |enable_early_data| bit was not being set by
SSL_apply_handback().
Change-Id: I35bfdc6dd43f4fa07ef79eb02e4624b59fcdda5e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39385
Commit-Queue: Matt Braithwaite <mab@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
OpenSSL 1.1.0's RSA getters can be inconvenient because they return a number of
fields via output parameters. OpenSSL 1.1.1 adds individual getters for each of
the fields, which is a bit simpler. Align with them.
Note our OPENSSL_VERSION_NUMBER is still 1.1.0. Adding these functions may
cause friction with third-party packages which polyfill these functions based
on OPENSSL_VERSION_NUMBER, though none appear to be doing this right now.
Between this and TLS 1.3, we probably should switch the version to 1.1.1 at
some point anyway.
Change-Id: Iada5a0315c403cc221688af53fc4ba165d65e99c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39944
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
We never ended up using this, and callers can still configure
SSL_CTX_set_verify_algorithm_prefs to enable Ed25519 on the receiving
side. (On the sending side, this API was never needed because it's a
function of what certificate you configure.) This was just a way to
tweak the default without requiring callers restate the order.
Change-Id: I38d7f91d85430f37fc7e278d77466e78a0cbfa0d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39848
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
ecdsa_sha1 and ecdsa_secp521_sha512 are disabled by default but a caller
could still enable them by configuring the verify preferences. Improve
the tests to distinguish these cases better. Also, as this is getting
unwieldy, cut down on duplicated code between the client and server
signatures.
Change-Id: I1530f4cb43d8e9d675f7fdc4693034287fcac153
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39847
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
We already had the state for it, but no API. This will allow us to
configure the signature preferences individually per socket in Chromium
and get a better measurement for how often SHA-1 in TLS 1.2 is still
needed. See associated bug for details.
Bug: chromium:658905
Change-Id: Id6198afc91f8275492995992e03d75a7ff328909
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39845
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Functions that take SSL* do not necessarily have an ssl->config
available because it is released post-handshake, whereas hs->config can
be accessed without a null check.
Change-Id: I3d9f3838c1f2d79f92beac363a90fb6046671053
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39844
Reviewed-by: Adam Langley <agl@google.com>
This doesn't change the serialization: it just adds
|enable_early_data| to the list of early data fields that get updated
by SSL_apply_handback().
This is needed because, for example, add_new_session_tickets(), which
runs after handback, performs certain actions iff |enable_early_data|
is set. Plus it just seems cleaner.
Change-Id: Ibcdb745ff9bcbeb2af2475f69f9f798937e7ee63
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39804
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Matt Braithwaite <mab@google.com>
Although the new tests are enabled by default, there is a flag to
(continue to) skip them. This is to allow for inter-version
compatibility testing to be performed without a monstrous number of
failures from old versions that don't yet have TLS 1.3 support.
Change-Id: I9f5e201a21f775442859e127c906b5f77ad8755b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39388
Commit-Queue: Matt Braithwaite <mab@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
RtlGenRandom is a legacy API that might be altered and is unavailable
for UWP apps. BCryptGenRandom is the recommended API for generating
random numbers on UWP.
This change causes BCryptGenRandom to be used for UWP apps and
RtlGenRandom to be used on non-UWP apps (i.e. desktop apps). For non-UWP
configurations, RtlGenRandom is used instead of BCryptGenRandom to avoid
accessing resources that may be unavailable inside the Chromium sandbox.
Bug: 307
Change-Id: I49f445198b7b4f300a752f45e221a2875d17099e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39584
Reviewed-by: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
We do not support these, but Node expects the constants to be there, so
define them. Also fill in X25519's OID. Now that we can wrap it in
EVP_PKEY, we should have the OID there. (Our serializers don't use the
giant OID table, which is why it didn't matter.)
Change-Id: Ie0637f0e525c5704a9354c743075c027ace2f631
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39724
Reviewed-by: Adam Langley <agl@google.com>
BlindingCacheConcurrency is crashing on older macOS in Chromium and
Wycheproof primality tests are timing out on Windows. Just disable them
both by default and reenable only when running tests standalone.
Bug: chromium:1042657
Change-Id: Ib3151e883269d1c03154560c2c6f89467cc0113c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39625
Reviewed-by: Adam Langley <agl@google.com>
In split handshake tests, it is already the case that the handshaker
must signal the proxy when it wants to read more data. But there was
not a lot of specificity about exactly how much data would be read.
The case of rejecting early data sent with a second ClientHello,
following a HelloRetryRequest,[1] requires this to be nailed down, in
order that the handshaker should not process the early data.
This commit changes the handshaker to read exactly one SSL record and
then stop, when it is asked to read. The pattern of I/O operations
remains undefined.
[1] See SkipEarlyData-SecondClientHelloEarlyData-TLS13-Split.
Change-Id: I30f58e57fc5ebff3f7c7ef8482cc629e42fef6a4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39524
Commit-Queue: Matt Braithwaite <mab@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
I had hoped outputting regularly would solve things, but one of
Chromium's Android builders is still timing out. Limit it to x86 and
x86_64, which typically is correlated with a more powerful CPU in
downstream CIs.
This isn't great, but we still run non-Wycheproof primality tests and
primality testing doesn't have any dedicated platform-specific assembly.
It does run platform-specific assembly by way of lower-level BIGNUM
operations, but those are also tested elsewhere. bn_mod_u16_consttime
depends on 32-bit vs 64-bit, but that is covered by running on both
32-bit and 64-bit x86.
Use the GTest DISABLED_Foo mechanism so they may still be run manually
with --gtest_also_run_disabled_tests.
Change-Id: Ie422096db5bb4186145532f4fd2d4063372b8988
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39604
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This is needed for some TLS 1.3 split-handshake tests. Because
TestState::Deserialize doesn't check for CBS_len() == 0, it should be
a compatible change to tack additional data onto the end of the
serialized test state.
Change-Id: I16464b6e27ab2e9afd0d505719095b4895e652a4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39546
Commit-Queue: Matt Braithwaite <mab@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Running that many primality tests, particularly on large numbers, in a
single test case is slow and timing out Chromium's test runner.
Change-Id: I07363744970545b2b4fcd7be264e20c338765dea
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39564
Reviewed-by: Adam Langley <agl@google.com>
Based on reports, these changes seem like good suspects for build
failures reported, while using the generated CMake build, on iOS and
Android. By checking this in, this change will appear in the
master-with-bazel branch, making it easier for consumers to test.
Change-Id: Icbcebe85f10fad76e3224333c769d0818ae45244
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39545
Reviewed-by: David Benjamin <davidben@google.com>
This is a speculative fix for the CI flakiness on Android. It seems
Android and Linux ARM ABIs may differ slightly in handling of thread
locals, so we should build for GOOS=android. That requires cgo and
pointing CC at a suitable target-specific compiler from the NDK. Detect
those values from CMakeCache.txt.
Change-Id: I2da75bf9ca6df3e5e677c2151ece8c5e20740fc3
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39504
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This relands
https://boringssl-review.googlesource.com/c/boringssl/+/39206. See that
CL description for details on the change.
The CL was originally reverted due to a number of ARM-only test
failures. First, there was a test-only issue, resolved in
https://boringssl-review.googlesource.com/c/boringssl/+/39306.
Second, the implementation did not work in unoptimized Android Thumb2
builds. This was caused by a clang bug introduced in
https://reviews.llvm.org/rL340261 and fixed in
https://reviews.llvm.org/rL351310. aes_nohw_(un)compact_block have
been rewritten in an attempt to dodge the bug. Performance of optimized
builds with clang and gcc do not appear to be affected by the rewrite.
See the delta from patch set 1.
(I had hoped to improve precommit CQ coverage before landing this, but
both failures turned out to be ARM-only. Either way, there are now
32-bit and 64-bit SSE2-less configurations so the 32-bit and 64-bit
implementations have CQ coverage.)
Change-Id: If5f9f5ea570686a15258ecd7cf49bdbc12dc34c5
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39444
Reviewed-by: Adam Langley <agl@google.com>
Points not on the curve are invalid inputs to EC functions, so EC
implementations should check the curve equation whenever importing
points from the caller. Sadly, a number of implementations, including
older OpenSSLs, miss this important check, so careful callers want this
clarified in the documentation.
Also update the note about OpenSSL to reflect the current behavior.
While I'm here, const-correct EC_KEY_key2buf.
Change-Id: I6fde5c823c4f3f6b141ba1566f427d96cd5881df
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39364
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
When building with TSAN, having 2048 threads causes crypto_test to run
for more than 20 minutes (when I gave up), vs about two minutes
normally. This will remove our TSAN coverage (due to timeouts) unless we
trim the size of the test.
Change-Id: I381c77a8e9e09c49f3476c38993db40ffdac60d6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39346
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
poly1305_vec.c requires SSE2 intrinsics and uint128_t. Unlike MSVC, clang-cl
supports uint128_t just fine (as long as we do not do division). This makes
ChaCha20-Poly1305 much faster on Windows when built with clang-cl.
Before:
Did 2219000 ChaCha20-Poly1305 (16 bytes) seal operations in 1016000us (2184055.1 ops/sec): 34.9 MB/s
Did 1279500 ChaCha20-Poly1305 (256 bytes) seal operations in 1016000us (1259350.4 ops/sec): 322.4 MB/s
Did 428250 ChaCha20-Poly1305 (1350 bytes) seal operations in 1015000us (421921.2 ops/sec): 569.6 MB/s
Did 84000 ChaCha20-Poly1305 (8192 bytes) seal operations in 1016000us (82677.2 ops/sec): 677.3 MB/s
Did 39750 ChaCha20-Poly1305 (16384 bytes) seal operations in 1015000us (39162.6 ops/sec): 641.6 MB/s
After:
Did 2096250 ChaCha20-Poly1305 (16 bytes) seal operations in 1015000us (2065270.9 ops/sec): 33.0 MB/s
Did 1453250 ChaCha20-Poly1305 (256 bytes) seal operations in 1016000us (1430364.2 ops/sec): 366.2 MB/s
Did 642500 ChaCha20-Poly1305 (1350 bytes) seal operations in 1015000us (633004.9 ops/sec): 854.6 MB/s
Did 136250 ChaCha20-Poly1305 (8192 bytes) seal operations in 1016000us (134104.3 ops/sec): 1098.6 MB/s
Did 69750 ChaCha20-Poly1305 (16384 bytes) seal operations in 1016000us (68651.6 ops/sec): 1124.8 MB/s
(Benchmarks gathered in VM, but this is a significant difference.)
Change-Id: Ia0a856e75995623c5621d2e48d61d945c41b17de
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39345
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This dates to https://boringssl-review.googlesource.com/2850, which was
done in response to an ARM crash. I assume the ARM crash was due to
poly1305_arm.c casting pointers around, which is technically UB, even on
x86 since C says it is UB to cast pointers if the value would be
unaligned. (Also I believe it's a strict aliasing violation, though the
compilers really ought to give us a sanitizer for it if they're excited
about that optimization.)
Replace with memcpy, which any reasonable compiler would compile the
same on platforms that support unaligned access. ARM does support it
these days, so perhaps the crash came from an older ARM?
Benchmarks showed no difference with this CL.
Change-Id: I022bdb84f95e45c143ad19359f646ee1416d5ae9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39344
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
The BN_BLINDING cache, when 1024 threads are performing concurrent
private operations on one RSA key, can race to append a BN_BLINDING to a
cache which is just short of the maximum length. The cache ends up one
(or more) elements longer than the maximum length. That causes the index
of one of the cache elements to _be_ the supposed maximum length, but
that index is treated as a magic number that indicates that a
BN_BLINDING isn't from the cache and thus needs to be freed after use.
That BN_BLINDING is then double-freed when the cache itself is freed.
See internal bug b/147126942.
Since the fact that someone hit this means that 1024 threads working on
a single RSA key is a thing that's happening, take the opportunity to
grow the cache by doubling rather than by single elements at a time.
Once the number of extensions is so reduced, the trick of unlocking to
keep a few allocations outside of the lock (which caused the problem)
can be discarded.
Change-Id: I32dd16d825b702b31ee9b776414c4e6afe883724
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39324
Reviewed-by: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
This reverts commit b3ac6bb39a.
Reason for revert: 32-bit version seems to be broken. I'll debug this
and improve pre-commit CQ coverage before relanding.
Original change's description:
> Replace aes_nohw with a bitsliced implementation.
>
> aes_nohw is currently one of several variable-time table-based
> implementations in C or assembly (armv4, x86, and x86_64). Replace all
> of these with a C bitsliced implementation, with 32-bit, 64-bit, and
> 128-bit (SSE2) variants. This is based on the algorithms described in:
>
> https://bearssl.org/constanttime.html#aes
> https://eprint.iacr.org/2009/129.pdf
> https://eprint.iacr.org/2009/191.pdf
>
> This makes our AES implementation constant-time in all build
> configurations!
>
> There were far too many benchmarks to put in the commit message.
> Instead, please refer to this fancy spreadsheet:
> https://docs.google.com/spreadsheets/d/1wDCzfkPl7brfjWJKq55awQjwCPhOYI8O7zSQZuEc2Xg/edit?usp=sharing
>
> Parallel modes on x86 and x86_64 do fine due to the SSE2 code. AES-GCM
> actually gets faster. The 64-bit (4x) bitsliced implementation is less
> effective at speeding parallel modes but still helps. The 32-bit (2x)
> bitsliced implementation even less.
>
> Non-parallel modes, sadly, take a *dramatic* performance hit. I tried a
> constant-time table lookup for comparison, but bitslicing was still
> better. This implementation performs comparably to the table in
> BearSSL's documentation, which suggests I didn't do anything obviously
> wrong. (Note BearSSL's table for 'ct' corresponds to a 32-bit bitsliced
> implementation compiled for 64-bit. Compiling this implementation for
> 64-bit matches, but compiling it for 32-bit seems to be considerably
> slower.)
>
> Assumptions that may make this palatable:
>
> - AES-GCM is by far the most important AES mode, and we perform okay
> with it. Modern things aren't built out of CBC.
>
> - A nontrivial chunk of Chrome users on Windows don't have SSSE3 and
> would be affected by this change. They would get the SSE2 version
> which performs well for AES-GCM *and* is constant-time.
>
> - ARM devices are primarily mobile which cycles hardware much faster.
> Chrome for Android has required NEON for several years now, so it
> would not run this code. (Aside from https://crbug.com/341598.)
>
> - aarch64 mandates NEON, so it would not run this code.
>
> - QUIC packet number encryption does use a one-off block operation, but
> only once per packet.
>
> - Arguably this is undoing a performance gain that we never earned. That
> said, it was a dramatic performance gain in places.
>
> As an alternative, we could just check in the SSE2 version and drop the
> x86 and x86_64 table-based assembly, but this still leaves the generic
> code with cache-timing side channels.
>
> Change-Id: I0f4b4467a49790509503c529d7c0940318096a00
> Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39206
> Commit-Queue: Adam Langley <agl@google.com>
> Reviewed-by: Adam Langley <agl@google.com>
TBR=agl@google.com,davidben@google.com
Change-Id: Iffaf01a98ab40bbfa009c451aa20ba3eb923eab9
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39285
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
aes_nohw is currently one of several variable-time table-based
implementations in C or assembly (armv4, x86, and x86_64). Replace all
of these with a C bitsliced implementation, with 32-bit, 64-bit, and
128-bit (SSE2) variants. This is based on the algorithms described in:
https://bearssl.org/constanttime.html#aeshttps://eprint.iacr.org/2009/129.pdfhttps://eprint.iacr.org/2009/191.pdf
This makes our AES implementation constant-time in all build
configurations!
There were far too many benchmarks to put in the commit message.
Instead, please refer to this fancy spreadsheet:
https://docs.google.com/spreadsheets/d/1wDCzfkPl7brfjWJKq55awQjwCPhOYI8O7zSQZuEc2Xg/edit?usp=sharing
Parallel modes on x86 and x86_64 do fine due to the SSE2 code. AES-GCM
actually gets faster. The 64-bit (4x) bitsliced implementation is less
effective at speeding parallel modes but still helps. The 32-bit (2x)
bitsliced implementation even less.
Non-parallel modes, sadly, take a *dramatic* performance hit. I tried a
constant-time table lookup for comparison, but bitslicing was still
better. This implementation performs comparably to the table in
BearSSL's documentation, which suggests I didn't do anything obviously
wrong. (Note BearSSL's table for 'ct' corresponds to a 32-bit bitsliced
implementation compiled for 64-bit. Compiling this implementation for
64-bit matches, but compiling it for 32-bit seems to be considerably
slower.)
Assumptions that may make this palatable:
- AES-GCM is by far the most important AES mode, and we perform okay
with it. Modern things aren't built out of CBC.
- A nontrivial chunk of Chrome users on Windows don't have SSSE3 and
would be affected by this change. They would get the SSE2 version
which performs well for AES-GCM *and* is constant-time.
- ARM devices are primarily mobile which cycles hardware much faster.
Chrome for Android has required NEON for several years now, so it
would not run this code. (Aside from https://crbug.com/341598.)
- aarch64 mandates NEON, so it would not run this code.
- QUIC packet number encryption does use a one-off block operation, but
only once per packet.
- Arguably this is undoing a performance gain that we never earned. That
said, it was a dramatic performance gain in places.
As an alternative, we could just check in the SSE2 version and drop the
x86 and x86_64 table-based assembly, but this still leaves the generic
code with cache-timing side channels.
Change-Id: I0f4b4467a49790509503c529d7c0940318096a00
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39206
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This algorithm is much simplier and more obvious than the one from the
HRSS paper. Unfortunately it's not immediately any faster (roughly a
no-op on most platforms, +5% on ARM) but it does allow a bunch of
constant-time rotation code to be deleted.
Since it's simplier, however, it's easier to speed-up a little with
future changes.
Change-Id: Ic0e92c77c44ea9aeb6fe35940af9767084fe5f58
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39084
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
I had a bug that was only caught in ssl_test. This would have caught it
in crypto_test (although only via Wycheproof test vectors; our
EVP_CIPHER CBC test vectors are all short.)
Change-Id: I8dc1457796cb6a8c0be808639657ce74967225ad
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39205
Reviewed-by: Adam Langley <agl@google.com>
We have some code which uses SSE2 intrinsics which, since they don't
have complicated build requirements, is enabled even with
OPENSSL_NO_ASM. x86_64 mandates SSE2 and people building for x86 tend to
mandate it anyway these days. This is great, but we still have generic
32-bit and 64-bit code configurations for other platforms.
32-bit generic code is covered by testing 32-bit ARM with NEON disabled.
However, 64-bit ARM always has NEON available, so we have no SIMD-less
64-bit platforms in our CI.
The immediate motivation is some bitsliced AES code I'm working on,
however I believe this also applies to the existing HRSS code. This also
fixes the HRSS feature checks to only look at __SSE2__, not __SSE__.
__SSE__ isn't sufficient and we don't compile if GCC or Clang is told
-msse -mno-sse2.
Change-Id: Iebb23f1664a2f62e0b4333e0e99f7d5f6c7f384d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39204
Reviewed-by: Adam Langley <agl@google.com>
Reportedly, GCC 8 and 9, on aarch64, rejects this with:
crypto/cipher_extra/aead_test.cc:545:54: error: requested alignment 64 is larger than 16 [-Werror=attributes]
The only other uses of alignas(x), with x > 16, are in x86-64-only code.
Change-Id: I1c93732cb40a783c2ef7271b1df9baae644b4305
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39224
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
This change adds a 'cmake' build type to generate_build_files.py, which
creates a standalone, CMake build without (most) of the complexities of
the full development CMake build.
(This is just a sketch for now. Some deduplication of the CMake is
called for before landing, presuming that this is useful.)
Change-Id: I1f91a8905cabaedf8f9ec588da5784edd67bfed0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38744
Reviewed-by: Adam Langley <agl@google.com>
This does not change the wire format for any existing (TLS 1.2 and
lower) cases, which means it should not affect interoperability of
anything that exists.
Most tests pass, but I'll land those in a separate commit, after
nailing down some loose ends, and in order to have more time to reason
about interoperability effects.
Some features are not supported yet, e.g early data.
Change-Id: I7bb377017324cb3d98df75c5d6ed4757c6901ed7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38926
Reviewed-by: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Matt Braithwaite <mab@google.com>
Although (somewhat) documented in prose, it is not obvious from the name
that BN_prime_checks only works for randomly-selected candidate primes.
Split into BN_prime_checks_for_generation and
BN_prime_checks_for_validation. Fix internal call sites. Notably,
DH_check now uses more iterations.
Consistently call the parameter 'checks' rather than 'iterations', to
match BN_prime_checks.
This is in preparation for importing the Wycheproof primality testing
vectors, some of which include Miller-Rabin worst case values.
(Realistically the blinding mechanism meant, even for those inputs, our
false positive rate was at most ~2^-64 anyway, but best to keep the use
cases clear.)
Update-Note: DH_check may be slower after this change.
Change-Id: Ic13d03d8631e74bf2958979ee5ef45a69e603f46
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39195
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Wycheproof's primality testing vectors include worst case values where
1/4 of witnesses are false. Add some test cases for true and false
witnesses.
Change-Id: I66050fd34694ca1cc145f950500d110c22d8bd42
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39194
Reviewed-by: Adam Langley <agl@google.com>
In doing so, add an IgnoreAllInstructions option for FileTest. FileTest
tracks unused fields so test drivers don't accidentally miss a portion
of the test. Wycheproof tests, however, have many different key formats
in instructions. These are tedious to list out, so add an option to
ignore them, on the assumption that checking attributes is more useful
than instructions.
Change-Id: I01cc9f3a95577d576c8c2dd68f5092fceb3215b1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39191
Reviewed-by: Adam Langley <agl@google.com>
This CL updates the JSON conversion to preserve the flags. A
WycheproofResult now captures both "result" and "flags". An "acceptable"
test case's validity is determined by its flags. By default, we consider
an "acceptable" case as invalid, but a test driver may mark some of them
as valid by listing the flags as a parameter.
Previously, some Wycheproof tests (I think it was x25519_tests.txt?) did
not contain enough information to resolve this unambiguously. This has
since been fixed.
This also makes the converted files smaller because we no longer expand the
flags into comments.
Change-Id: I2ca02d7f1b95f250409e8b23c4ad7bb595d77fdf
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39188
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
The mock QUIC transport used has a very simple record layer: A record
starts with a single byte (either 'H' or 'A') identifying the record to
be handshake or application data, then a 4-byte network order integer
indicating the length of the payload, followed by the encryption secret
that would be used for protecting that payload, followed by the payload
itself. The encoded length is only the length of the payload, not that
of the payload and secret (or the whole record).
Bug: 293
Change-Id: Icb706a94ef1ad77e86ef8728b73db8832ee65e1b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39144
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Our TLS read patterns are always read(5); read(record_size); read(5);
read(record_size); ...;. Allocate the 5-byte reads inline in SSLBuffer.
This avoids bouncing on a 5-byte malloc to learn a socket is idle and
avoids calling malloc twice on each record.
This costs a few bytes but means we malloc once per record, rather than
twice per record + once each time the state machine is run while idle.
Change-Id: I4f6dafe4141cbb890b921a5fa8d528c1fb98a0b4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39004
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
The old ones disappeared. Switch to the developer.arm.com pointers.
Hopefully they are more stable. (Interestingly, the "Download PDF" link
for AAPCS64 now points to a GitHub repo.)
Change-Id: Ifa81e95978285409a6323f007d041515d4f270ee
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39006
Reviewed-by: Adam Langley <agl@google.com>
ERR_error_string_n needs to be called in a separate statement, compared
to ERR_error_string(err, NULL), which returns a buffer and is very
convenient to use in an expression. This is unfortunate because it is
not thread-safe.
Give ERR_error_string_n a return value to align. Fixing callers still
requires allocating a buffer somewhere, but the rest of the expression
can remain relatively unperturbed.
Change-Id: I273c9df97f0bb113cdc57cf3896c42195910c67a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38964
Reviewed-by: Steven Valdez <svaldez@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
On a client using SSL_CTX_set_reverify_on_resume, we currently release
the early data keys before reverification rather than afterwards. This
means the QUIC implementation needs to watch for SSL_do_handshake's
return value before using the keys we've released. It is better to be
robust, so defer releasing the keys in the first place.
To avoid oddities around TCP and QUIC differences, tweak the 0-RTT cert
reverification to not send an alert on error. Sending such an alert
under early data is somewhat questionable given the server may not be
able to read it anyway.
Bug: 303
Change-Id: I42c16f9f046322d0b03cb0b425e11471f2fbe52a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38885
Reviewed-by: Nick Harper <nharper@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
In doing so, convert an unnecessary macro into an inline function and
avoid needing to fix up the word order. gcm.c likes to store things with
the words byteswapped and the words unswapped.
Change-Id: Ifa4cbe9ceaaf2d4cd3b6133d442603343b409cc3
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38785
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This shrinks the perf gap between nohw and 4bit_mmx. Replace 4bit_mmx
and fix the last remaining variable-time GHASH implementation, covering
32-bit x86 without SSSE3.
Before:
Did 2065000 AES-128-GCM (16 bytes) seal operations in 1000154us (2064682.0 ops/sec): 33.0 MB/s
Did 368000 AES-128-GCM (256 bytes) seal operations in 1002435us (367106.1 ops/sec): 94.0 MB/s
Did 77000 AES-128-GCM (1350 bytes) seal operations in 1001225us (76905.8 ops/sec): 103.8 MB/s
Did 14000 AES-128-GCM (8192 bytes) seal operations in 1067523us (13114.5 ops/sec): 107.4 MB/s
Did 6572 AES-128-GCM (16384 bytes) seal operations in 1015976us (6468.7 ops/sec): 106.0 MB/s
After:
Did 1995000 AES-128-GCM (16 bytes) seal operations in 1000374us (1994254.1 ops/sec): 31.9 MB/s
Did 319000 AES-128-GCM (256 bytes) seal operations in 1000196us (318937.5 ops/sec): 81.6 MB/s
Did 66000 AES-128-GCM (1350 bytes) seal operations in 1002823us (65814.2 ops/sec): 88.8 MB/s
Did 12000 AES-128-GCM (8192 bytes) seal operations in 1079294us (11118.4 ops/sec): 91.1 MB/s
Did 5511 AES-128-GCM (16384 bytes) seal operations in 1006218us (5476.9 ops/sec): 89.7 MB/s
(Note fallback AES is dampening the perf hit. Pairing with AESNI to
roughly isolate GHASH shows a 40% hit.)
That just leaves aes_nohw...
Change-Id: I7d842806c54a5a057895fa2e7665633330e34b72
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38784
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
We have several variable-time table-based GHASH implementations, called
"4bit" in the code. We have a fallback one in C and assembly
implementations for x86, x86_64, and armv4. This are used if assembly is
off or if the hardware lacks NEON or SSSE3.
Note these benchmarks are all on hardware several generations beyond
what would actually run this code, so it's a bit artificial.
Implement a constant-time implementation of GHASH based on the notes in
https://bearssl.org/constanttime.html#ghash-for-gcm, as well as the
reduction algorithm described in
https://crypto.stanford.edu/RealWorldCrypto/slides/gueron.pdf.
This new implementation is actually faster than the fallback C code for
both 32-bit and 64-bit. It is slower than the assembly implementations,
particularly for 32-bit. I've left 32-bit x86 alone but replaced the
x86_64 and armv4 ones. The perf hit on x86_64 is smaller and affects a
small percentage of 64-bit Chrome on Windows users. ARM chips without
NEON is rare (Chrome for Android requires it), so replace that too.
The answer for 32-bit x86 is unclear. More 32-bit Chrome on Windows
users lack SSSE3, and the perf hit is dramatic. gcm_gmult_4bit_mmx uses
SSE2, so perhaps we can close the gap with an SSE2 version of this
strategy, or perhaps we can decide this perf hit is worth fixing the
timing leaks.
32-bit x86 with OPENSSL_NO_ASM
Before: (4bit C)
Did 1136000 AES-128-GCM (16 bytes) seal operations in 1000762us (1135135.0 ops/sec): 18.2 MB/s
Did 190000 AES-128-GCM (256 bytes) seal operations in 1003533us (189331.1 ops/sec): 48.5 MB/s
Did 40000 AES-128-GCM (1350 bytes) seal operations in 1022114us (39134.6 ops/sec): 52.8 MB/s
Did 7282 AES-128-GCM (8192 bytes) seal operations in 1117575us (6515.9 ops/sec): 53.4 MB/s
Did 3663 AES-128-GCM (16384 bytes) seal operations in 1098538us (3334.4 ops/sec): 54.6 MB/s
After:
Did 1503000 AES-128-GCM (16 bytes) seal operations in 1000054us (1502918.8 ops/sec): 24.0 MB/s
Did 252000 AES-128-GCM (256 bytes) seal operations in 1001173us (251704.8 ops/sec): 64.4 MB/s
Did 53000 AES-128-GCM (1350 bytes) seal operations in 1016983us (52114.9 ops/sec): 70.4 MB/s
Did 9317 AES-128-GCM (8192 bytes) seal operations in 1056367us (8819.9 ops/sec): 72.3 MB/s
Did 4356 AES-128-GCM (16384 bytes) seal operations in 1000445us (4354.1 ops/sec): 71.3 MB/s
64-bit x86 with OPENSSL_NO_ASM
Before: (4bit C)
Did 2976000 AES-128-GCM (16 bytes) seal operations in 1000258us (2975232.4 ops/sec): 47.6 MB/s
Did 510000 AES-128-GCM (256 bytes) seal operations in 1000295us (509849.6 ops/sec): 130.5 MB/s
Did 106000 AES-128-GCM (1350 bytes) seal operations in 1001573us (105833.5 ops/sec): 142.9 MB/s
Did 18000 AES-128-GCM (8192 bytes) seal operations in 1003895us (17930.2 ops/sec): 146.9 MB/s
Did 9000 AES-128-GCM (16384 bytes) seal operations in 1003352us (8969.9 ops/sec): 147.0 MB/s
After:
Did 2972000 AES-128-GCM (16 bytes) seal operations in 1000178us (2971471.1 ops/sec): 47.5 MB/s
Did 515000 AES-128-GCM (256 bytes) seal operations in 1001850us (514049.0 ops/sec): 131.6 MB/s
Did 108000 AES-128-GCM (1350 bytes) seal operations in 1004941us (107469.0 ops/sec): 145.1 MB/s
Did 19000 AES-128-GCM (8192 bytes) seal operations in 1034966us (18358.1 ops/sec): 150.4 MB/s
Did 9250 AES-128-GCM (16384 bytes) seal operations in 1005269us (9201.5 ops/sec): 150.8 MB/s
32-bit ARM without NEON
Before: (4bit armv4 asm)
Did 952000 AES-128-GCM (16 bytes) seal operations in 1001009us (951040.4 ops/sec): 15.2 MB/s
Did 152000 AES-128-GCM (256 bytes) seal operations in 1005576us (151157.1 ops/sec): 38.7 MB/s
Did 32000 AES-128-GCM (1350 bytes) seal operations in 1024522us (31234.1 ops/sec): 42.2 MB/s
Did 5290 AES-128-GCM (8192 bytes) seal operations in 1005335us (5261.9 ops/sec): 43.1 MB/s
Did 2650 AES-128-GCM (16384 bytes) seal operations in 1004396us (2638.4 ops/sec): 43.2 MB/s
After:
Did 540000 AES-128-GCM (16 bytes) seal operations in 1000009us (539995.1 ops/sec): 8.6 MB/s
Did 90000 AES-128-GCM (256 bytes) seal operations in 1000028us (89997.5 ops/sec): 23.0 MB/s
Did 19000 AES-128-GCM (1350 bytes) seal operations in 1022041us (18590.3 ops/sec): 25.1 MB/s
Did 3150 AES-128-GCM (8192 bytes) seal operations in 1003199us (3140.0 ops/sec): 25.7 MB/s
Did 1694 AES-128-GCM (16384 bytes) seal operations in 1076156us (1574.1 ops/sec): 25.8 MB/s
(Note fallback AES is dampening the perf hit.)
64-bit x86 with OPENSSL_ia32cap=0
Before: (4bit x86_64 asm)
Did 2615000 AES-128-GCM (16 bytes) seal operations in 1000220us (2614424.8 ops/sec): 41.8 MB/s
Did 431000 AES-128-GCM (256 bytes) seal operations in 1001250us (430461.9 ops/sec): 110.2 MB/s
Did 89000 AES-128-GCM (1350 bytes) seal operations in 1002209us (88803.8 ops/sec): 119.9 MB/s
Did 16000 AES-128-GCM (8192 bytes) seal operations in 1064535us (15030.0 ops/sec): 123.1 MB/s
Did 8261 AES-128-GCM (16384 bytes) seal operations in 1096787us (7532.0 ops/sec): 123.4 MB/s
After:
Did 2355000 AES-128-GCM (16 bytes) seal operations in 1000096us (2354773.9 ops/sec): 37.7 MB/s
Did 373000 AES-128-GCM (256 bytes) seal operations in 1000981us (372634.4 ops/sec): 95.4 MB/s
Did 77000 AES-128-GCM (1350 bytes) seal operations in 1003557us (76727.1 ops/sec): 103.6 MB/s
Did 13000 AES-128-GCM (8192 bytes) seal operations in 1003058us (12960.4 ops/sec): 106.2 MB/s
Did 7139 AES-128-GCM (16384 bytes) seal operations in 1099576us (6492.5 ops/sec): 106.4 MB/s
(Note fallback AES is dampening the perf hit. Pairing with AESNI to roughly
isolate GHASH shows a 40% hit.)
For comparison, this is what removing gcm_gmult_4bit_mmx would do.
32-bit x86 with OPENSSL_ia32cap=0
Before:
Did 2014000 AES-128-GCM (16 bytes) seal operations in 1000026us (2013947.6 ops/sec): 32.2 MB/s
Did 367000 AES-128-GCM (256 bytes) seal operations in 1000097us (366964.4 ops/sec): 93.9 MB/s
Did 77000 AES-128-GCM (1350 bytes) seal operations in 1002135us (76836.0 ops/sec): 103.7 MB/s
Did 13000 AES-128-GCM (8192 bytes) seal operations in 1011394us (12853.5 ops/sec): 105.3 MB/s
Did 7227 AES-128-GCM (16384 bytes) seal operations in 1099409us (6573.5 ops/sec): 107.7 MB/s
If gcm_gmult_4bit_mmx were replaced:
Did 1350000 AES-128-GCM (16 bytes) seal operations in 1000128us (1349827.2 ops/sec): 21.6 MB/s
Did 219000 AES-128-GCM (256 bytes) seal operations in 1000090us (218980.3 ops/sec): 56.1 MB/s
Did 46000 AES-128-GCM (1350 bytes) seal operations in 1017365us (45214.8 ops/sec): 61.0 MB/s
Did 8393 AES-128-GCM (8192 bytes) seal operations in 1115579us (7523.4 ops/sec): 61.6 MB/s
Did 3840 AES-128-GCM (16384 bytes) seal operations in 1001928us (3832.6 ops/sec): 62.8 MB/s
(Note fallback AES is dampening the perf hit. Pairing with AESNI to roughly
isolate GHASH shows a 73% hit. gcm_gmult_4bit_mmx is almost 4x as faster.)
Change-Id: Ib28c981e92e200b17fb9ddc89aef695ac6733a43
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38724
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
On older Linux distributions (e.g. Centos 7 which we still use for
Conscrypt releases) PTRACE_O_EXITKILL is defined in <linux/ptrace.h>
but this can't be included alongside <sys/ptrace.h> due to conflicting
defines, so this is the path of least resistance for portability.
Could also define this as 0 if undefined, but all distributions seem
to use 1<<20, and Centos 7 kernels should have support as they are 3.10
and later and PTRACE_O_EXITKILL was introduced around 3.8.
Change-Id: Ib8a6e0dbc62613e30c38a6cc09522c2d7b92577b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38704
Reviewed-by: Adam Langley <agl@google.com>
Warning alerts do not exist in TLS 1.3, but RFC 8446 section 6.1
continues to define user_canceled as a signal to cancel the handshake,
without specifying how to handle it. JDK11 misuses it to signal
full-duplex connection close after the handshake. As a workaround, skip
user_canceled as in TLS 1.2. This matches NSS and OpenSSL.
Bug: b/135941563
Change-Id: I7ef546f1f166741b9f112686c75e6757331948f0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38605
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
C's specification text around pointer arithmetic is buggy and fails to
account for empty spans. Empty spans are typically represented as
ptr=NULL and len=0, so (T*)NULL + 0 must be defined for ptr + len to
reliably work. C++ does not have this bug and specifies this correctly.
See https://crbug.com/1019588.
This language bug has made its way over to newer versions of UBSan,
which enforce this. In the short term, add bogus length checks as a
workaround. However, unlike the memcpy language bug, we cannot address
this systematically. In the long term, we need to switch libcrypto to
building as C++ for a real fix.
To test this, update our clang revision to that in
https://chromium-review.googlesource.com/c/chromium/src/+/1879890. Note
that clang revision was later reverted in Chromium for seemingly
unrelated reasons.
This newer UBSan also catches a memcpy/OPENSSL_memcpy issue in
siphash.c, from the earlier C NULL bug we'd been working around.
Bug: chromium:1019588, chromium:1019644
Change-Id: I460e547c8cd740db68da8cc2a3a970276ec92e90
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38584
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Node.js recently added an option to override signature algorithms in https://github.com/nodejs/node/pull/29598
which make use of several NIDs and SSL_get_shared_sigalgs. This CL adds
NIDs for Ed448 (but does not implement it) and a shim function for
SSL_get_shared_sigalgs that simply returns 0. This enables Electron to
reduce its patch surface.
Change-Id: I833d30b0248ca68ebce4767dd58d5f087fd1e18e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38404
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Upstream did this in 7644a9aef8932ed4d1c3f25ed776c997702982be, so align
with them. Add the new OPENSSL_* names and switch all callers witihn the
library to match. Keep the old BUF_* names around for compatibility.
Note there were two functions where we already had an OPENSSL_* version:
OPENSSL_strdup and OPENSSL_strnlen. The former now gains a NULL check to
align with BUF_strdup. The latter gets deduplicated; we had two
implementations.
Change-Id: Ia1cd4527a752fcd62e142ed1e1d7768d323279ba
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38425
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
The experiment which motivated CECPQ2b has concluded (although the
results haven't been published yet) and the SIKE code is causing some
issues for gRPC in gprc/grpc#20100. Also, this is code size that takes
up space in Android etc.
Change-Id: I43b0b8c420f236c0fe9b40bf2517d2fde98495d5
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38384
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
If -ffunction-sections or -fdata-sections is enabled when doing a FIPS
shared build, the linker script won't do what's expected and will
silently end up including very little (or nothing) in the integrity
check.
This changes alters the linker script to discard any text or data
sections other than the main one, which should make this failure much
more obvious.
Also, add assertions (that are always enabled) in the module to check
that a few obvious things that should be inside the module boundaries
actually are.
Change-Id: I91178e213a28a7c0c4a38155974e452cd9d558d1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38324
Reviewed-by: Adam Langley <agl@google.com>
This path has always had one-too-few “..” elements since the file first
appeared, but everyone seems to have lived with it, presumably because
/include is in the search path and the compiler tries relative to that.
Change-Id: I30006209ad74d064ded5dd2cd34b1f14806dcffe
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38344
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
This change adds a test to try and prevent errors like b8f760191e. Since
it's challenging to test this code, it uses ptrace to capture a trace of
the PRNG behaviour and checks that the observed behaviour matches a much
smaller model of the code. The model is hopefully easier to read and
believe correct.
Change-Id: I00b811dc5692e2fbe3dcc16c622d4eb706f16ce0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38265
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Allows the utility to work on shared libraries.
Also, don't printf the output from hex.Dump() as it may contain
formatting chars such as %.
Change-Id: I3c091436271c132417fd0212955a6575ef57af50
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38244
Reviewed-by: Adam Langley <agl@google.com>
The comment says that an "0x" prefix indicates a hex value. However we
always passed PRIu64 as the format specifier for |sscanf|, and |sscanf|
isn't documented to handle an 0x prefix expect for "i"-family format
specifiers. With |PRIu64|, |sscanf| reads any leading "0x" as just zero.
Instead, check for "0x" ourselves and use |PRIx64| if found to parse hex
values.
Change-Id: Id5ed7009d30902022e5ee640e8931bf1431dedc0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38264
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Use the constants when defined. Also OpenSSL uses 0-indexed iteration
counts rather than 1-indexed. This likely changed when we tried to align
with the 1-indexed FIPS 186-4 algorithm.
Also fix the safe prime call. BN_GENCB_call(cb, i, c1 - 1) doesn't make
sense since the first parameter should be an event constant. OpenSSL
does BN_GENCB_call(cb, 2, c1 - 1).
This also doesn't make sense. OpenSSL documents 2 as meaning the prime
has been found. That function is interleaving the p and (p-1)/2 checks
to save the full iteration count on p if (p-1)/2 is composite anyway.
That also doesn't work because the blinding mechanism runs even if the
iteration count is 1, so we're actually paying for the blinding four
times. Add a TODO to address this.
(I can only assume we just never try to generate safe primes. Moreover,
we don't even use BN_generate_prime_ex in RSA keygen. Still, that
function needs work.)
Change-Id: I6f0b7cd10da28484362c92db0c806c1c3045d415
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38169
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Now that Miller-Rabin can reject composites faster, we can do fewer
trial divisions. Halving the table seems to improve things for RSA-3072
and RSA-4096. I left RSA-2048 alone since measurements with it halved
were a bit more of a wash.
(Although now that I've left it alone, it's gotten faster, so these
numbers are generally noisy.)
Before:
Did 320 RSA 2048 key-gen operations in 30132984us (10.6 ops/sec)
min: 27703us, median: 81774us, max: 375687us
Did 84 RSA 3072 key-gen operations in 30166627us (2.8 ops/sec)
min: 86961us, median: 322184us, max: 1170392us
Did 30 RSA 4096 key-gen operations in 30644802us (1.0 ops/sec)
min: 260916us, median: 772364us, max: 2743435us
After:
Did 345 RSA 2048 key-gen operations in 30103781us (11.5 ops/sec)
min: 23359us, median: 75033us, max: 267159us
Did 91 RSA 3072 key-gen operations in 30185495us (3.0 ops/sec)
min: 72531us, median: 267385us, max: 1119039us
Did 38 RSA 4096 key-gen operations in 30473203us (1.2 ops/sec)
min: 228529us, median: 720027us, max: 2039681us
Change-Id: I52d431347a70572034ced5b7778a2edac8f15173
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38168
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
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.)
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>
We don't need both mask variables. If we know we have a composite
witness, we return immediately, so the only time we mask off
instructions is when we know we have a nonwitness.
Change-Id: I2b99f3114a79ce2dc1a37706835d2abfe93a716e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38167
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
|a| is usually much smaller than |w_bits|. We only need to loop up to
|w_bits| and hide |a| when the value is possibly composite. If
Miller-Rabin has not hit -1 by then, break early.
This speeds up RSA keygen by a bit.
Before:
Did 248 RSA 2048 key-gen operations in 30041496us (8.3 ops/sec)
min: 31690us, median: 109097us, max: 373911us
Did 71 RSA 3072 key-gen operations in 30096719us (2.4 ops/sec)
min: 108650us, median: 370844us, max: 1768070us
Did 27 RSA 4096 key-gen operations in 32829007us (0.8 ops/sec)
min: 205485us, median: 1107051us, max: 4035040us
After:
Did 340 RSA 2048 key-gen operations in 30026342us (11.3 ops/sec)
min: 24681us, median: 77749us, max: 350477us
Did 67 RSA 3072 key-gen operations in 30089075us (2.2 ops/sec)
min: 75070us, median: 394220us, max: 1101562us
Did 38 RSA 4096 key-gen operations in 30283788us (1.3 ops/sec)
min: 284947us, median: 742688us, max: 1970468us
Change-Id: If1b48e9306c3fe1be56c304143e206c3bdb3301d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38165
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This way we test not only that we match expectations for primes and
composites but that the core test correctly reports false witnesses. I
made an initial attempt to gather some interesting test input, but
probably one can do better.
Change-Id: I7c29afb534bd6980ef42a893e86d86bd44af8349
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38164
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
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>
This is translated from vpaes-armv8.pl. See top of the new file for
details. Unfortunately, vpaes's performance is disappointing here. The
vpaes paper notes NEON's vector permutation instructions are not very
fast. But this is now constant-time.
Parallel modes, notably CTR derivatives, are performance-sensitive and
worth further work. (They currently use bsaes.) Thus this CL only
replaces non-parallel uses, which currently use a variable-time
table-based implementation.
Note QUIC packet number encryption will do a single one-off AES block
operation per packet and use this file. But the single-block speeds
below should be fine for a per-packet operation.
Alternatives considered: I toyed with BearSSL's 32-bit C bitsliced
implementation, but it appears to be slower than this implementation.
Cortex-A53 (Raspberry Pi 3 Model B+)
Before:
Did 124000 AES-128-CBC-SHA1 (16 bytes) seal operations in 1005644us (123304.1 ops/sec): 2.0 MB/s
Did 45000 AES-128-CBC-SHA1 (256 bytes) seal operations in 1009513us (44575.9 ops/sec): 11.4 MB/s
Did 12000 AES-128-CBC-SHA1 (1350 bytes) seal operations in 1009735us (11884.3 ops/sec): 16.0 MB/s
Did 2266 AES-128-CBC-SHA1 (8192 bytes) seal operations in 1060631us (2136.5 ops/sec): 17.5 MB/s
Did 1078 AES-128-CBC-SHA1 (16384 bytes) seal operations in 1002268us (1075.6 ops/sec): 17.6 MB/s
Did 114000 AES-256-CBC-SHA1 (16 bytes) seal operations in 1004576us (113480.7 ops/sec): 1.8 MB/s
Did 38000 AES-256-CBC-SHA1 (256 bytes) seal operations in 1001777us (37932.6 ops/sec): 9.7 MB/s
Did 9999 AES-256-CBC-SHA1 (1350 bytes) seal operations in 1028518us (9721.8 ops/sec): 13.1 MB/s
Did 1892 AES-256-CBC-SHA1 (8192 bytes) seal operations in 1095702us (1726.7 ops/sec): 14.1 MB/s
Did 902 AES-256-CBC-SHA1 (16384 bytes) seal operations in 1038989us (868.2 ops/sec): 14.2 MB/s
Did 2094000 AES-128 encrypt setup operations in 1000296us (2093380.4 ops/sec)
Did 1505000 AES-128 encrypt operations in 1000596us (1504103.6 ops/sec)
Did 465000 AES-128 decrypt setup operations in 1000354us (464835.4 ops/sec)
Did 1468000 AES-128 decrypt operations in 1000178us (1467738.7 ops/sec)
Did 1751000 AES-256 encrypt setup operations in 1000189us (1750669.1 ops/sec)
Did 1113000 AES-256 encrypt operations in 1000004us (1112995.5 ops/sec)
Did 339000 AES-256 decrypt setup operations in 1002970us (337996.2 ops/sec)
Did 1103000 AES-256 decrypt operations in 1000882us (1102028.0 ops/sec)
After:
Did 119000 AES-128-CBC-SHA1 (16 bytes) seal operations in 1000259us (118969.2 ops/sec): 1.9 MB/s [-5.0%]
Did 39000 AES-128-CBC-SHA1 (256 bytes) seal operations in 1001341us (38947.8 ops/sec): 10.0 MB/s [-12.3%]
Did 10571 AES-128-CBC-SHA1 (1350 bytes) seal operations in 1067614us (9901.5 ops/sec): 13.4 MB/s [-16.3%]
Did 1903 AES-128-CBC-SHA1 (8192 bytes) seal operations in 1090907us (1744.4 ops/sec): 14.3 MB/s [-18.3%]
Did 957 AES-128-CBC-SHA1 (16384 bytes) seal operations in 1093380us (875.3 ops/sec): 14.3 MB/s [-18.8%]
Did 108000 AES-256-CBC-SHA1 (16 bytes) seal operations in 1005090us (107453.1 ops/sec): 1.7 MB/s [-5.6%]
Did 33000 AES-256-CBC-SHA1 (256 bytes) seal operations in 1026530us (32147.1 ops/sec): 8.2 MB/s [-15.5%]
Did 8393 AES-256-CBC-SHA1 (1350 bytes) seal operations in 1064768us (7882.5 ops/sec): 10.6 MB/s [-19.1%]
Did 1496 AES-256-CBC-SHA1 (8192 bytes) seal operations in 1090316us (1372.1 ops/sec): 11.2 MB/s [-20.6%]
Did 737 AES-256-CBC-SHA1 (16384 bytes) seal operations in 1070396us (688.5 ops/sec): 11.3 MB/s [-20.4%]
Did 695000 AES-128 encrypt setup operations in 1000325us (694774.2 ops/sec) [-66.8%]
Did 1043000 AES-128 encrypt operations in 1000568us (1042407.9 ops/sec) [-30.7%]
Did 495000 AES-128 decrypt setup operations in 1000680us (494663.6 ops/sec) [-6.4%]
Did 743000 AES-128 decrypt operations in 1000892us (742337.8 ops/sec) [-49.4%]
Did 550000 AES-256 encrypt setup operations in 1000228us (549874.6 ops/sec) [-68.6%]
Did 786000 AES-256 encrypt operations in 1000978us (785232.0 ops/sec) [-29.4%]
Did 377000 AES-256 decrypt setup operations in 1002252us (376152.9 ops/sec) [-11.3%]
Did 547000 AES-256 decrypt operations in 1000168us (546908.1 ops/sec) [-50.3%]
Bug: 266
Change-Id: Ia5f9c90bcf5e713e40cacc954c604a6ffb432d6c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37426
Reviewed-by: Adam Langley <agl@google.com>
The prose and the register listing didn't match. (I suspect I wrote the
register listing before I decided which preheat registers to preserve.)
Change-Id: Ib461573ea50fdf5a806266c22805f6ba3470a6ec
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37425
Reviewed-by: Adam Langley <agl@google.com>
Prevents arbitrary processes linked against libcrypto, which run
before the self test binaries, from triggering SELinux audit logs.
Fails safe. I.e. default is not to write a flag file which in turn
will mean all processes loading libcrypto run a full set of KAT tests
until the variable is set.
Alternative considered: Use a weak gloabl symbol containing the flag
(defaulting to "don't write") and override in the self test binaries.
However at the very least this would need to be in a separate object
file other than bcm.o to prevent local symbol resolution, so unsure
if that would be acceptable.
Change-Id: I32b20699bdd7ecaff06fc5f79b213d9a9d5f6253
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37404
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
It turns out that emcc does not like "-ggdb" flag. Disable it if we
detect that we're being compiled by Emscripten toolchain (e.g., when
compiling to WebAssembly).
Change-Id: Ic6a11251a79cdb370c1bdce48aec5428b2f2f306
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37344
Reviewed-by: Adam Langley <alangley@gmail.com>
Reviewed-by: Adam Langley <agl@google.com>
This is test-only code and a no-op, but it's prudent to avoid making
assumptions about the initial state of *out. Hopefully someday later we can
assume std::optional or pull in absl::optional.
Change-Id: I85af87bb2cc3cda3d40801c91e6abe4f5a7d89f8
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37184
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
This adapts our existing API for QUIC, although I'm not entirely
convinced the shape of it fits as it does with TCP. Things that needed
to be changed:
- There is a slight ordering issue on the server with HRR and releasing
the 0-RTT keys to QUIC.
- Remove EndOfEarlyData.
- At the early return point for the server, QUIC needs to have installed
the client traffic secrets earlier.
- The maximum early data value is a constant in QUIC.
- QUIC never installs early secrets at the TLS level. (In particular,
this avoids nuisances with do_send_second_client_hello's null cipher
not updating the encryption level.)
- The read/write secrets for 0-RTT keys were mixed up.
As the QUIC tests are getting a bit unwieldy, I tidied them up a bit.
This CL does *not* handle the QUIC transport parameters or HTTP/3
server SETTINGS frame interactions with 0-RTT. That will be done in a
separate CL.
I suspect if we ever implement DTLS 1.3, we'll find ourselves wanting to
align some of the QUIC bits here with DTLS and perhaps refine the
handshake/transport abstractions a bit.
Bug: 221
Change-Id: I61f701d7241dbc99e5dbf57ae6c283e10b85b049
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37145
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
With Clang 3.5, this fails and breaks gRPC's build:
third_party/boringssl/crypto/bio/fd.c:196:7: error: declaration does not declare anything [-Werror,-Wmissing-declarations]
OPENSSL_FALLTHROUGH;
^~~~~~~~~~~~~~~~~~~
third_party/boringssl/crypto/bio/../internal.h:192:29: note: expanded from macro 'OPENSSL_FALLTHROUGH'
Clang 5, empirically, is happy, so limit this to Clang >= 5.
Change-Id: I82430b415955ec7d664abe3ffe024e6bb28346c2
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37246
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
FIPS IG 9.11 allows for a shared library to skip running self tests if
they have already run successfully for a given module and environment.
This change has Android FIPS builds read and write a flag file in
/dev/boringssl to implement this. The flag file is named after the hash
of the module to ensure specificity.
Change-Id: I5c4e7b6244831746e61c5f78f703b0b4fb0ddd10
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37204
Reviewed-by: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
QUIC is going to make this flow a bit more complicated, so let's simplify it a
bit. The client flight states already know to skip themselves in 1-RTT
resumption, so just run through the same states. Also remove a redundant
early_data_offered check.
(I think we originally skipped the states because we do half-RTT tickets and
the transcript bits were precomputed.)
Bug: 221
Change-Id: I3a62c864458012e74b46f7ef212abc125760c12d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37144
Reviewed-by: Steven Valdez <svaldez@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Unexpected SSL_ERROR_* values usually mean the caller didn't handle an
error case for some opt-in feature, but it still would be handy to
stringify them when logging.
Change-Id: If1c44a180b5c124a51ba61410ba02bd637f3429a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37188
Reviewed-by: Adam Langley <agl@google.com>
There's no sense in having two of these (with similar but slightly
different numbers, no less!). Fold them together and remove the
redundant SSL_want constants. Almost everything uses SSL_get_error.
Update-Note: Most of the SSL_want constants have been removed, except
SSL_NOTHING, SSL_READING, and SSL_WRITING which are used by external
code.
Change-Id: I75727f7cf6333694767ce8129ee6815fd464c163
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37187
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This undoes a lot of the MakeConstSpans and MakeSpans that were just
added, though it does require a bit of helper machinery. This should
make us much more consistent about which buffer is sized with which size
(even though they are secretly all the same size).
Change-Id: I772ffd2e69141ff20511bcd3add865afa82cf3a0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37127
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
The callers become filled with MakeConstSpans, but the various TLS 1.3
secrets will get fixed in a subsequent CL. We do still need a better
pattern for the EVP_MAX_MD_SIZE buffers.
Change-Id: Ide9c173bf0760ecdb8cc45e63969457c20310de2
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37125
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
We perform all our negotiation based on the first ClientHello (for
consistency with what |select_certificate_cb| observed), which is in the
transcript, so we can ignore most of the second one.
However, we ought to check the second PSK binder. That covers the client
key share, which we do consume. In particular, we'll want to check if it
we ever send half-RTT data on these connections (we do not currently do
this). It is also a tricky computation, so we enforce the peer handled
it correctly.
Tested that both Chrome and Firefox continue to interop with this check,
when configuring uncommon curve preferences that trigger HRR. (Normally
neither browser sees HRRs against BoringSSL servers.)
Update-Note: This does enforce some client behavior that we hadn't been
enforcing previously. However, it only figures into TLS 1.3 (not many
implementations yet), and only clients which hit HelloRetryRequest
(rare), so this should be low risk.
Change-Id: I42126585ec0685d009542094192e674cbd22520d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37124
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
The Android emulator uses a custom CMake-based build. It's a little
goofy to generate a CMake file list when our standalone build is already
CMake, but our standalone build doesn't use pregenerated files.
(Long-term, I hope we can unify the file lists under sources.cmake and,
to help out Mundane, allow the standalone build to optionally consume
pregenerated files. But for now just making yet another build output is
simplest.)
Bug: b/139120013
Change-Id: Id5b8b4ed83bc21d261663cb8defe9e19b64c639b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37065
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This explicitly sets the section for the dummy_chacha20_poly1305_asm
symbol we generate for Windows. Without explicitly setting the
section, NASM would store it as an undefined symbol rather than a
defined symbol, resulting in a broken object file.
Change-Id: If8ff18f714be5e46af59ff869ae93e64e2c6e44b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37024
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
As of LLVM r368102, Clang will set a pointer tag in bits 56-63 of the
address of a global when compiling with -fsanitize=hwaddress. This requires
an adjustment to assembly code that takes the address of such globals: the
code cannot use the regular R_AARCH64_ADR_PREL_PG_HI21 relocation to refer
to the global, since the tag would take the address out of range. Instead,
the code must use the non-checking (_NC) variant of the relocation (the
link-time check is substituted by a runtime check).
This change makes the necessary adjustment in all of the places where it
is needed when compiling with -fsanitize=hwaddress. While here, shrink the
code by an instruction in each of those places by folding the addend into
the load, and remove some dead code that seems to have been left over from
commit 293d9ee4e8.
We check for a sufficiently new clang before using the :pg_hi21_nc: relocation
variant because support for this variant was only added recently.
Change-Id: Ic9da8386e19c03c1e90c103a81232a254277e9a5
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36924
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
In order to clarify that CCM is not a service offered by the FIPS
module, move the CCM-related fragments of code out of the module to
where they are used in the outer part of libcrypto.
Change-Id: I64f95867a92fb90ea8bb460e2608c998669bb543
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36804
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
OpenSSL has two notions of key type because it supports multiple OIDs
for the same algorithm: NID_rsa vs NID_rsaEncryption and five distinct
spelling of DSA. We do not support these, so the base ID is simply the
ID.
Bug: 280
Change-Id: I966530901405a29a0cc35a2bea67304dda336e8a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36844
Reviewed-by: Adam Langley <alangley@gmail.com>
Commit-Queue: David Benjamin <davidben@google.com>
Due to padding and slightly silly field ordering, I think this actually ends up
a no-op memory-wise, but may amount to win with cleverer reordering or as
fields change.
Change-Id: I14e38d747a90112cf06c741aec148b77cc5902fb
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36791
Reviewed-by: Adam Langley <agl@google.com>
EVP_MAX_MD_SIZE is sized for the largest hash function supported, SHA-512, but
TLS never uses anything larger than SHA-384, which is plenty large enough. This
shaves 16 * 3 = 48 bytes of per-connection overhead plus an addition 16 * 7 =
112 bytes of per-handshake overhead. (Per-handshake structures are discarded
when the handshake completes, so this matters less.)
Change-Id: Iabe15d25fc9182ffcdde876facbe4d80c8143197
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36790
Reviewed-by: Adam Langley <agl@google.com>
cryptography.io expects X25519 support to be exposed via EVP_PKEY. Also we're
considering using EVP_PKEY to pass in keys for ESNI. This unfortunately
requires adding some odd EVP_PKEY_set1_tls_encodedpoint and
EVP_PKEY_get1_tls_encodedpoint APIs which cryptography.io uses for X25519
because the EVP_PKEY "raw" functions did not exist at the time.
To test, implement EVP_PKEY_derive support in evp_tests.txt.
Change-Id: Ie0666bb9aba13eecf203156dc047ac49ef6d0093
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36788
Reviewed-by: Adam Langley <agl@google.com>
This avoids early callback users writing their own SNI parser and gives us a
place to surface the server name from ESNI in the future.
Update-Note: This isn't a breaking change, but users of
SSL_CTX_set_select_certificate_cb can likely drop a bit of code after this CL.
Bug: 275
Change-Id: I9685ae5cca8e0483de76229d12dac45ff8e9ec32
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36784
Reviewed-by: Steven Valdez <svaldez@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Keep the setup_ctx logic, which, among other things, checks if the
signature algorithm is valid. This cuts down on some unnecessary
fuzzer-mode suppressions.
Change-Id: I644f75630791c9741a1b372e5f83ae7ff9f01c2f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36766
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
The names of those tests don't actually matter to the shim because we
don't pass them in anywhere. Note hasComponent() is also used by the
signature algorithm tests, so that also needs to use underscores as a
result.
Change-Id: I393df4c6ffebcc66a55f256df5a641ad87e66441
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36765
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
There are two naming conventions for TLS cipher suites, the standard
IETF names (SSL_CIPHER_standard_name) and the ad-hoc OpenSSL names
(SSL_CIPHER_get_name). When we added TLS 1.3, we had to come up with
OpenSSL-style names for the cipher suites.
OpenSSL-style names use hyphens rather than underscores (and omit
underscores in odd places), so the natural name for
TLS_AES_128_GCM_SHA256 would have been "AES128-GCM-SHA256". However,
that name is already taken by TLS_RSA_WITH_AES_128_GCM_SHA256 because
OpenSSL's naming convention treats the legacy RSA key exchange as
default. Instead, we used an "AEAD-" prefix to indicate the ciphers only
specified the AEAD.
Since then, OpenSSL has implemented TLS 1.3. Instead, they simply made
the OpenSSL-style name match the standard name starting TLS 1.3,
underscores and all. (This is why openssl s_client will return very
different-looking cipher names in TLS 1.2 and TLS 1.3.)
Align with OpenSSL and do the same.
Update-Note: SSL_CIPHER_get_name will return different values for TLS
1.3 ciphers than before. Note that we did not allow TLS 1.3 ciphers to
be configured at all, so no cipher suite configurations will need to
change, but code logging or asserting on the result of a TLS connection
may observe differences.
It is also recommended that consumers replace uses of
SSL_CIPHER_get_name with SSL_CIPHER_standard_name which gives a much
more consistent naming convention. (BoringSSL supports both standard and
OpenSSL names in the cipher suite configuration, so there's no need to
use OpenSSL names at all.)
Change-Id: I40b1de0689dd7b32af88602acc063934f2877999
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36764
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
I should have noticed this previously, but the SIKE code was exporting
symbols called generic things like “params”. They're not dynamically
exported, but BoringSSL is often statically linked so better to ensure
that these things are prefixed to avoid the risk of collisions.
Change-Id: I3a942dbc8f4eab703d5f1d6898f67513fd7b578c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36745
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
We already have crypto/dh/params.c and some of our downstream consumers
cannot take two source files with the same name in the same build
target.
Change-Id: I324ace094c2215b443e98fc9ae69876ea1929efa
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36744
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
When testing HRSS-SXY and SIKE, we also want a control group. However,
how are clients to indicate that they're part of the 1/3 of the
experiment population that's not advertising CECPQ? And how are servers
to indicate that they would have negotiated CECPQ2 / 2b if only the
client had asked?
This change adds a temporary signaling extension to solve these issues.
Change-Id: Ic087a09149ef10141568b734396981ae97950a9b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36725
Reviewed-by: David Benjamin <davidben@google.com>
ACVP will be the replacement for CAVP. CAVP is the FIPS 140 test-vector
program. This commit contains some very rough support for ACVP.
Currently it only supports hash functions and it's not hard to hit
corner cases, but it's enough of a framework to work from.
Change-Id: Ifcde18ac560710e252220282acd66d08e7507262
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36644
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
* CECPQ2b will use SIKE/p434 instead of SIKE/p503
* KEM uses SHA256 instead of HMAC-256
* implements new starting curve: y^2=x^3 + 6x^2 + x
* adds optimized implementation for aarch64
* adds optimized implementation for AMD64
which do not support MULX/ADOX/ADCX
* syncs the SIKE test code with the NIST Round 2
specification.
* removes references to field size from variables
names, tests and defines.
Change-Id: I5359c6c62ad342354c6d337f7ee525158586ec93
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36704
Reviewed-by: Adam Langley <agl@google.com>
The added code is a one-shot function. A handful of instructions could
be saved by having a context object for repeated use of the same key,
but perhaps it's not needed.
Selected the 2-4 variant to implement because it seems to be
overwhelmingly the most commonly used.
Change-Id: I1e4f699f7dd5a2d35e12245fa116bafbd3439979
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36664
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
This is our bug that we've had since the beginning of PKCS#7 writing
support in eeb9f491: the empty signerInfos SET wasn't emitted. Some
parsers, including OpenSSL, don't like this but it appears to have taken
five years for anyone to notice.
This change does not make parsing strict so that we continue to parse
old messages that we may have produced.
(As ever, PKCS#* should not be used expect where absolutely required for
interoperability.)
Bug: b:135982177
Change-Id: Ia7241de69f105657bdfb5ff75e909deae71748a0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36564
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Go 1.13 will add Ed25519 support to the standard library. Switch the
order of our vendored Ed25519 bits so we do not get mixed up by this.
When Go 1.13 is released, we can then unwind all this in favor of the
standard library version.
Update-Note: See b/135634259
Change-Id: Iddc0ea58db5b2181cecacfcdd3cc058159271787
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36504
Reviewed-by: Adam Langley <agl@google.com>
Clang recognizes the (mask & a) | (~mask & b) pattern as a select. While
it often optimizes this into a cmov, it sometimes inserts branches
instead, particularly when it detects a string of cmovs with the same
condition.
In the long term, we need language-level support for expressing our
constraints. In the short term, introduce value barriers to prevent the
compiler from reasoning about our bit tricks. Thanks to Chandler Carruth
for suggesting this pattern. It should be reasonably robust, short of
value-based PGO or the compiler learning to reason about empty inline
assembly blocks.
Apply barriers to our various constant-time selects. We should invest
more in the valgrind-based tooling to figure out if there are other
instances.
Change-Id: Icc24ce36a61f7fec021a762c27197b9c5bd28c5d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36484
Reviewed-by: Chandler Carruth <chandlerc@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Point addition formulas for short Weierstrass curves are often
incomplete and do not work for P + P. EC implementations usually rely on
constant-time operations never hitting this case, or at least it being
rare[0].
However, the condition checks several values. Our C functions use && and
||, and the P-256 assembly also branches. This can leak intermediate
values via a small side channel. Thanks to David Schrammel and Samuel
Weiser for reporting this.
nistz256 base point multiplication (keygen, ECDSA signing) is unaffected
due to ecp_nistz256_point_add_affine lacking a doubling case. nistp224
and nistp256 base point multiplication, on some compilers, are saved by
quirks of the "mixed" path. The generic code's base point multiplication
and all methods' arbitrary point multiplication (ECDH; ephemeral keys
makes this less interesting) are affected.
Fix the branches in the nistz256 assembly, and use bit operations in C.
Note the C versions are all different because P-224 believes true is 1,
P-256 believes true is any non-zero value, and the generic code believes
true is 0xf...f. This should be double-checked when reviewing.
Aside: The nistz256 assembly also special-cases nontrivial P + (-P) in
arbitrary point multiplication. Fortunately, the formulas in util.c hold
there and I believe one can show P + (-P) is unreachable for all curves.
Still, it would be nice to omit the branch if we can verify the assembly
works anyway.
[0] https://github.com/openssl/openssl/blob/03da376ff7504c63a1d00d57cf41bd7b7e93ff65/crypto/ec/ecp_nistp521.c#L1259
Change-Id: I8958624cd6b5272e5076c6c1605ab089e85f4cb7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36465
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
See I9c20b660ce4b58dc633588cfd5b2e97a40203ec3 for motivation. This aligns with
the other curves. In doing so, I removed the constant-time table lookups from
mul_public because it was easy, which gave a small performance improvement. I
did not further use ec_compute_wNAF, on the assumption that we do not care
enough about P-224 ECDSA performance to bother.
Before:
Did 63756 ECDSA P-224 verify operations in 5032477us (12668.9 ops/sec)
After:
Did 71914 ECDSA P-224 verify operations in 5042356us (14262.0 ops/sec) [+12.5%]
Change-Id: Ifd20293aca09e578c85d4692294caffc1b287909
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36464
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
KWP is Key Wrap with Padding, defined in RFC 5649 and SP 800-38F. Like
Key Wrap, it's a poor-man's AEAD and shouldn't be used. However, some
existing systems use it and we need to interoperate.
The interface of the added functions is a little unfortunate, but they
match the interfaces of the existing Key Wrap functions which, in turn,
match functions in OpenSSL. Hopefully this way, if OpenSSL ever add
support, we'll line up.
Change-Id: I3496c288f32230a891261586ca2e9c4ee8456c09
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36324
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Using signed digits for point multiplication halves the size of the table,
which is a valuable optimization. However, it is dependent on the curve whether
the doubling case in point addition is reachable. Assuming my reasoning is
valid, the condition for the standard table strategy is:
The non-trivial doubling case in single-point scalar multiplication may occur
if and only if the 2^(w-1) bit of the group order is zero.
It would be nice to transcribe this to Coq someday but, for now, check in a
proof in prose. The condition also does not apply to EC_GFp_nistz256_method's
multi-level tables.
This file is now 91% comments by line count.
Change-Id: I29b394289793db957f99e80734e10ed59a96fcec
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36364
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
CMake 3.0 was released June 10, 2014, just over five years ago. Set the minimum
version to 3.0. This cleans up some Mac workarounds. (CMP0025 was introduced
in 3.0, so setting the minimum version to 3.0 also enables it.)
CMP0025 is important because Clang and Apple Clang use different version
numbers. Prior to CMake 3.0, both read as Clang. Starting CMake 3.0, with
CMP0025 enabled, they read as Clang and AppleClang. Without this, we cannot
sanely version-check clang.
Unfortunately, CMP0025 applies at compiler detection, so if BoringSSL is
imported as a CMake subproject, we are dependent on the root project setting
CMP0025. But if we successfully set a minumum of 3.0, we can reasonably ask
consumers to do the same, which will do so.
Next up: In December, we can raise the version to CMake 3.1, which adds support
for specifying C and C++ language versions in CMake. (Alternatively, Abseil's
minimum version is actually 3.5, so maybe we can update more aggressively
here.)
Update-Note: CMake 2.8 is no longer supported. Update your CMake to the latest
version if it has not been updated in five years.
Change-Id: I3378567ad7575fc9fac69e05c403d69ea10332e2
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36444
Reviewed-by: Adam Langley <agl@google.com>
Other build systems will just take a list of the files, including
fips_shared_support.c, so better to make it a no-op in the
non-shared+FIPS case.
Also add it to the other cases so that the CMake build better matches
other builds in that respect.
Change-Id: I1bea4f6b8266da32340a5fc0fed5fc3680f3b18f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36264
Reviewed-by: Adam Langley <agl@google.com>
See I9c20b660ce4b58dc633588cfd5b2e97a40203ec3. Aside for p224-64.c, we'd
already split mul_public into a dedicated function, at which point it's
simpler to just have three functions.
This makes it clearer when we do and don't care about the doubling case
coming up and avoids a bunch of NULL checks.
Change-Id: I7c5dafa7f12f4f53937d912ba22c90cb5a786f04
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36225
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
While it appears that we internally support constant-time
dual multiplication, it is not actually constant-time. Integrating the
two operations means we hit the doubling branch. Instead, replace the
constant-time functions with single multiplication functions, one for
arbitrary points and one for the base point. This simplifies timing
analysis of the EC_METHODs.
This CL only changes the wrapper functions. A subsequent CL will change
the EC_METHOD hooks. We conservatively assume EC_POINT_mul callers
expect secret scalars and split it into two multiplications and an
addition if needed.
Update-Note: EC_POINT_mul may get slower if called with both g_scalar
and p_scalar non-NULL. If the scalars were secret, this plugs a timing
leak (note neither ECDH nor ECDSA signing use such an operation). If
acting on public scalars, notably ECDSA verify, this slowdown is not
inherently necessary. If necessary, we can expose a public version of
ec_point_mul_scalar_public, but callers should be using BoringSSL's
ECDSA verify API instead.
Change-Id: I9c20b660ce4b58dc633588cfd5b2e97a40203ec3
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36224
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This change adds a FIPS integrity check using shared libraries. Unlike
with the static case, a shared build can take advantage of the linker
resolving relocations and thus doesn't need delocation. It does mean
that both .text and .rodata sections need to be handled, however, so the
hashing format is slightly different. inject-hash.go is updated to be
able to rewrite shared libraries to inject the correct hash value.
Change-Id: I9a71910cd6df3a85e4efac896b0913e65b5f875b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36024
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
This is to test that detection of the “md5” tag is correct (although
Clang itself emits inconsist .file directives at the moment) and that
the added .file directive has the correct file number.
Change-Id: I89b48fe16fe142165fb5653cae45c39960578735
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36204
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
These directives contain labels that need to be mapped by delocate. This
starts to bite with DWARF5. Also, auto-detect whether the compiler is
emitting file directives with MD5 checksums and match that for the dummy
entry.
Change-Id: Ia6f3803287354bc77042a5629cf7e94ceb11b9f9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36184
Reviewed-by: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Implements support for hybrid key exchange based on SIKEp503, a post
quantum, isogeny based KEM. This is a hybrid construction mixed with
X25519 key agreement. Code point is 0xFE32. Cloudflare's SIDH
implementation is used for testing. Key exchange can be used with TLS1.3
only.
Change-Id: I3a5f38d6f7d016274e5bcfb629249664e1d983eb
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35264
Reviewed-by: Adam Langley <alangley@gmail.com>
There are reports that RDRAND on these chips can fail. Thus this change
disables the use RDRAND. Outside of FIPS mode, RDRAND is only used for
protection against forks and VM clones anyway.
(Note: I don't have any AMD chips to test on, so this is done blindly
from AMD's docs.)
Change-Id: Id61b2f6ba74c5ecf66804f7268a26e480a5bf815
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36144
Commit-Queue: Adam Langley <alangley@gmail.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
This stores early data tickets regardless of whether early data is enabled in
the initial handshake, and provides an API to query whether early data would be
performed to allow for comparison between early data enabled and disabled
resumptions.
Change-Id: Id3ef62e36b5be48f6a39fcd7c67d332b7d495141
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35964
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
OpenSSL uses the private key to find the leaf certificate. cryptography.io's
tests rely on this.
Update-Note: PKCS12_parse's behavior changes slightly. Affected callers are
recommended to switch to PKCS12_get_key_and_certs, which has much more
predictable behavior and has no pressures from 3rd-party software to match
OpenSSL's quirks.
Change-Id: I4ee2befbd56a0882ee166f00e748f2fe58ac6a86
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36125
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Unencrypted keys go in KeyBags instead of ShroudedKeyBags. OpenSSL generates
these when passed -keypbe NONE. Some of cryptography.io's tests use these.
Also, this is an absurd format.
Change-Id: I707a528118728eb898e923748caf52e7b936725d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36106
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
OpenSSL now defaults to HMAC-SHA256 instead of HMAC-SHA1. Support these.
This is needed for some of cryptography.io's tests to pass. For now, this does
not add support for creating such things or change the default, but I've added
a TODO marking the place where OpenSSL sticks the parameter in its API.
Change-Id: I29de2ee4fdcfa2363f94189f75930f55d5d0cf67
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36124
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This pulls in the following commits from upstream:
5dcfd6c50a216f81bf43e1f21bc5f3fc517ba47a,
41013cd63c068e2f271fabc92702ee67d800f0cb,
83cf7abf8e9abbd4d0b68c63dc1cb43374aafe63, and
13f6857db107b1b6f68daa7fc4a6dd1293428bb1. Of these, the first fixes a bug:
commit 5dcfd6c50a216f81bf43e1f21bc5f3fc517ba47a
Author: Daniel Axtens <dja@axtens.net>
Date: Mon Mar 18 10:22:44 2019 +1100
PPC assembly pack: fix copy-paste error in CTR mode
There are two copy-paste errors in handling CTR mode. When dealing
with a 2 or 3 block tail, the code branches to the CBC decryption exit
path, rather than to the CTR exit path.
This can lead to data corruption: in the Linux kernel we have a copy
of this file, and the bug leads to corruption of the IV, which leads
to data corruption when we call the encryption function again later to
encrypt subsequent blocks.
Originally reported to the Linux kernel by Ondrej Mosnáček <omosnacek@gmail.com>
This bug does not appear to have practical impact the way the function is used
in BoringSSL/OpenSSL. Unlike the CBC functions, the CTR32 functions do not
update the IV, which is the only difference between their epilogs. However, all
the callers either use a temporary buffer for the IV or clobber the counter
portion of the IV with an updated value anyway. (Confirmed that
CipherTest.TestVectors hits this case with AES-GCM and that the clobbered IV
matches in all but the counter portion.)
Change-Id: I25b781152c578155e0bcb0ee1c6d967e9e8cea88
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36104
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Most of the crypto_word_t* casts in third_party/sike are due to p503
being defined with uint64_t. This is a strict aliasing violation and
easily avoided with a TOBN-like macro when defining p503.
This clears almost all of the casts. Also remove an unused stdbool.h
include.
Change-Id: Ife3a4ec620f8b7f4e09c87c6fc43d8b82396046b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36064
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <alangley@gmail.com>
Based on Microsoft's implementation available on github:
Source: https://github.com/Microsoft/PQCrypto-SIDH
Commit: 77044b76181eb61c744ac8eb7ddc7a8fe72f6919
Following changes has been applied
* In intel assembly, use MOV instead of MOVQ:
Intel instruction reference in the Intel Software Developer's Manual
volume 2A, the MOVQ has 4 forms. None of them mentions moving
literal to GPR, hence "movq $rax, 0x0" is wrong. Instead, on 64bit
system, MOV can be used.
* Some variables were wrongly zero-initialized (as per C99 spec).
* Rewrite x86_64 assembly to AT&T format.
* Move assembly for x86_64 and aarch64 to perlasm.
* Changes to aarch64 assembly, to avoid using x18 platform register.
Assembly also correctly constructs linked list of stack-frames as
described in AAPCS64, 5.2.3.
* Move constant values to .RODATA segment, as keeping them in .TEXT
segment is not compatible with XOM.
* Fixes issue in arm64 code related to the fact that compiler doesn't
reserve enough space for the linker to relocate address of a global
variable when used by 'ldr' instructions. Solution is to use 'adrp'
followed by 'add' instruction. Relocations for 'adrp' and 'add'
instructions is generated by prefixing the label with :pg_hi21:
and :lo12: respectively.
* Enable MULX and ADX. Code from MS doesn't support PIC. MULX can't
reference global variable directly. Instead RIP-relative addressing
can be used. This improves performance around 10%-13% on SkyLake
* Check if CPU supports BMI2 and ADOX instruction at runtime. On AMD64
optimized implementation of montgomery multiplication and reduction
have 2 implementations - faster one takes advantage of BMI2
instruction set introduced in Haswell and ADOX introduced in
Broadwell. Thanks to OPENSSL_ia32cap_P it can be decided at runtime
which implementation to choose. As CPU configuration is static by
nature, branch predictor will be correct most of the time and hence
this check very often has no cost.
* Reuse some utilities from boringssl instead of reimplementing them.
This includes things like:
* definition of a limb size (use crypto_word_t instead of digit_t)
* use functions for checking in constant time if value is 0 and/or
less then
* #define's used for conditional compilation
* Use SSE2 for conditional swap on vector registers. Improves
performance a little bit.
* Fix f2elm_t definition. Code imported from MSR defines f2elm_t type as
a array of arrays. This decays to a pointer to an array (when passing
as an argument). In C, one can't assign const pointer to an array with
non-const pointer to an array. Seems it violates 6.7.3/8 from C99
(same for C11). This problem occures in GCC 6, only when -pedantic
flag is specified and it occures always in GCC 4.9 (debian jessie).
* Fix definition of eval_3_isog. Second argument in eval_3_isog mustn't be
const. Similar reason as above.
* Use HMAC-SHA256 instead of cSHAKE-256 to avoid upstreaming cSHAKE
and SHA3 code.
* Add speed and unit tests for SIKE.
Some speed results:
Skylake (64-bit):
Did 408 SIKE/P503 generate operations in 1002573us (407.0 ops/sec)
Did 275 SIKE/P503 encap operations in 1070570us (256.9 ops/sec)
Did 264 SIKE/P503 decap operations in 1098955us (240.2 ops/sec)
Skylake (32-bit):
Did 9 SIKE/P503 generate operations in 1051620us (8.6 ops/sec)
Did 5 SIKE/P503 encap operations in 1038251us (4.8 ops/sec)
Did 5 SIKE/P503 decap operations in 1103617us (4.5 ops/sec)
Change-Id: I22f0bb1f9edff314a35cd74b48e8c4962568e330
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35204
Reviewed-by: Adam Langley <alangley@gmail.com>
Out-of-band errors, the UNIX gift that keeps on giving...
We almost always ignore the result of ssl_send_alert, treating it as
largely a "best effort". Sending an alert is the only place in the TLS
stack where we call back to user code with state in the error queue. (If
we've put something in the error queue, it means we are in the process
of failing an operation.) That user code may mess up state by, say,
calling ERR_clear_error.
In particular, if the underlying BIO is implemented with SSL_write, as
in TLS tunneled over an HTTPS proxy, the call to SSL_write will
ERR_clear_error and clobber our error state. (SSL_write must
ERR_clear_error so that SSL_get_error works. This is one of the few
places we are sensitive to clearing the error queue.)
Split ssl_send_alert into a low-level ssl_send_alert_impl (for the two
places we do honor the return value) an ssl_send_alert wrapper which
saves and restores the error queue across the call, more explicitly
ignoring the return value.
This is intended as a minimal fix to https://crbug.com/959305, in case
we need to merge it to a release branch. As a follow-up, I plan to
rework the handshake state machine so it never calls ssl_send_alert,
instead returning the alert as part of the error. This is the last bit
of I/O still in the handshake. (We have the out_alert calling
convention, but I'm thinking it's worth a small sum type where the error
branch has an alert so we don't forget to supply one everywhere.
Update-Note: This changes our behavior when sending an alert fails.
Bug: chromium:959305
Change-Id: I24033205ad0f7ebd1797964489e4d46414a3e7ec
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35904
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
At one point we had -expect-foo and TestConfig::expect_foo for boolean
flags and -expect-bar and TestConfig::expected_bar for flags that take a
value. This seems to have been confusing and got applied inconsistently.
Match the variable names to the flag names and consistently use
"expect".
Change-Id: Ia346b91ad37b1177918c50392f9f80a384926e27
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35889
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
At one point, the ticket early data extension was under a separate
ticket_early_data_info code point. That was later consolidated. Rename
the tests which still reference the "info" name.
Change-Id: Ie3c9257d32a95569906ad24e7b419434b9faae1c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35887
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
For now just hard-code a tolerance of 1 minute.
SSL_get_early_data_reason and SSL_get_ticket_age_skew will allow us to
tune this.
Bug: 113
Change-Id: I85a530494d5405a3e11198d49bfa9cfd355f4f35
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35886
Reviewed-by: Adam Langley <agl@google.com>
This is to help servers diagnose 0-RTT rejects. (QUIC has a similar
feature, and this will help determine if we need to adjust the ticket
age skew.)
Bug: 113
Change-Id: Icc7e5df326b5fa82e744605021b1205298efba6a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35885
Reviewed-by: Adam Langley <agl@google.com>
We have a generic mechanism for this now. While
-expect-early-data-accept only makes sense for the resumption leg, we
have some tests which send fake early data to a server on the first leg.
This is in preparation for adding an SSL_get_early_data_reason, where
asserting in those cases would be useful.
(Also -expect-early-data-reject works just fine for initial connections.
It might make sense to make that implicit from the lack of
-expect-early-data-accept?)
Change-Id: I41ad0c5bb538409628885183f88f7fbd619bc6aa
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35884
Reviewed-by: Adam Langley <agl@google.com>
cryptography.io expects this API for Ed25519. Replace the now redundant
EVP_PKEY_new_ed25519_* functions. Ours were more static-linker-friendly,
but we weren't taking advantage of it and EVP_PKEY needs an overhaul to
be static-linker-friendly anyway.
Update-Note: EVP_PKEY_new_ed25519_public and
EVP_PKEY_new_ed25519_private are removed in favor of
EVP_PKEY_new_raw_{public,private}_key. I do not believe anyone was using
those functions.
Change-Id: Ibd12b4e9e37cd8dd4dbc7ebc4346ba52655d523a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35806
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
r18 (accessed as x18 and w18) is the platform register. The ABI testing
framework cannot touch it, but we can statically check that our assembly
leaves it alone.
Also fix a comment which cited the wrong register.
Change-Id: Iba2714eef5db19e2e93a6838d12a4e7c9011cc67
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35764
Reviewed-by: Adam Langley <agl@google.com>
In TLS 1.3, if the client doesn't read from the server, the server might hang
from a filled buffer while waiting for the client to read. Instead we avoid
flushing the NewSessionTicket until there is a write from the server.
Update-Note: This delays the flushing of the NewSessionTicket until the first
write. Consumers may need to force an empty write to send the tickets if they
aren't writing any data to the client.
Change-Id: Iec92043567e9a68c0a250533b7745eddeeae2341
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/34948
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Including ssl.h is quite a chunk of code and #defines, so we've tried to
limit its spread internally in the interests of code hygine given that
we have a multi-billion-line repo.
However, header files that mention enums from ssl.h currently need to
include ssl.h. For example, your class may have static class member
functions intended to be callbacks, and they need to be class members
because they'll call other private methods.
C cannot predeclare enums, but C++ can if you explicitly type them.
Sadly C doesn't support explicit types. So option one is to move the
enums into base.h. That works, but the enums properly live in ssl.h and
reading the header file is a lot clearer if you don't have to jump
around to see all the pieces.
So option two (this change) is to explicitly type and predelcare the
enums in base.h for C++ only. The worry now is that C and C++ might
disagree about the type of the enums. However, this has already
happened: at least for |ssl_private_key_result_t|, g++ thinks that it's
an |int| (without any explicit type) and gcc thinks that it's an
|unsigned|. At least they're the same length, I guess?
So, to make sure that this doesn't slip any more, this change also adds
|ssl_test_c.c| which tests that C views the enums as having the same
size as an |int|, at least.
Change-Id: I8248583ec997021f8226d5a798609f6afc96dac4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35664
Reviewed-by: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
The common name fallback does not interact well with name constraints.
Until we remove this fallback, we must resolve this conflict.
Blindly applying name constraints to the common name will reject
"decorative" common names that aren't intended to be hostnames (e.g.
[0]). We need to guess based on format whether the common name is a DNS
name. It is important this same check is applied to *both* name
constraints and name matching, which means the OpenSSL version (see
5bd5dcd49605ca2aa7931599894302a3ac4b0b04,
d02d80b2e80adfdde49f76cf7c7af4e013f45005, and
55a6250f1e7336e8a7d89fb609eb23398715ff6f) is unsuitable as a
compatibility data point.
In theory we could limit this to chains with name constraints, which are
uncommon, but X509_check_host sees only the leaf. We must apply it
uniformly. That means a strict check risks problems with malformed
non-WebPKI setups like [1].
For a first pass, mirror Go's behavior. Like Go, rather than run
SAN-less DNS-like common names through name constraints, we simply
reject all such certificates. Name constraints now exclude all leaf
certificates that can trigger the common name fallback. They are rare
enough that we can hopefully hold them to a higher standard.
Note this does not make misclassified decorative common names any worse,
compared to the checking the name constraint. Such names would not have
matched the constraint anyway.
Update-Note: This can may cause two kinds of errors:
1. Leaf certificates whose chain contains a name constraint and lack
SANs may be rejected with X509_V_ERR_NAME_CONSTRAINTS_WITHOUT_SANS.
2. Leaf certificates which use the common name fallback and verify
against an insufficiently DNS-looking hostname may fail with
X509_V_ERR_HOSTNAME_MISMATCH.
In both cases, the fix is to include the subjectAltName in the
certificate, rather than rely on the common name fallback. (Refining the
heuristic is also an option, but the two failure modes pull it in
opposite directions, so this is tricky.)
[0] https://github.com/golang/go/issues/24151
[1] https://github.com/GoogleCloudPlatform/cloudsql-proxy/issues/194
Change-Id: If25557de428768292a14ba3bdeeffbd74e3a3bf8
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35665
Reviewed-by: Adam Langley <agl@google.com>
This aligns with the Go crypto/x509 behavior and reduces the cases when
the SAN to CN fallback occurs. If the certificate is new enough to have
a SAN list, even if it only contains email or IP addresses, it is
reasonable to assume the certificate is new enough that the common name
is not a DNS name.
Update-Note: Our certificate verification is getting slightly stricter.
Change-Id: I9e3466d8dd8a722405c546181a589f797efa43f9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35647
Reviewed-by: Adam Langley <agl@google.com>
This flag is backwards. We want to check the common name less, not more. See if
anything was actually relying on this.
Update-Note: X509_CHECK_FLAG_ALWAYS_CHECK_SUBJECT is now ignored.
Change-Id: I8288d57540f8117059e58d72cc173aa4d3077fb6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35646
Reviewed-by: Adam Langley <agl@google.com>
cryptography.io uses this and it's also the correct behavior. Ideally it would
be default, but start with just adding the flag. See also
dd60efea955e41a6f0926f93ec1503c6f83c4e58 from upstream.
Change-Id: I9e13cdbfd44c904ba5bd69a5a66c68c4b7596867
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35645
Reviewed-by: Adam Langley <agl@google.com>
This will allow edge servers to pass judgement on the ClientHello before
completing the handoff process. This also means that edge servers will
now enforce ClientHello well-formedness — previously that check didn't
occur until the handshaker tried to parse the handoff submission.
Change-Id: I9804ac0224632b4b4381c1a81f434d188e0b9376
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35584
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
The RSA-PSS salt length was not being copied, and copying an Ed25519
EVP_MD_CTX did not work.
This is rather pointless (an EVP_PKEY_CTX is just a bundle of
parameters), and it's unlikely anyone ever will use this. But since
OpenSSL's EVP_PKEY signing API reuses EVP_MD_CTX and EVP_MD_CTX_copy_ex
is plausible in that scenario, we're stuck making EVP_MD_CTX_copy_ex
reachable for EVP_PKEY too. That then implies EVP_PKEY_dup should exist,
and if it exists we should be testing it.
Change-Id: I189435d0c716a83f58e1d8ac4abc2c409ecfea64
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35626
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
7578f3f0de made it work, but
26ba48a6fb regressed it by losing the
EVP_CIPH_CUSTOM_COPY flag. Additionally, we've since added an alignment
requirement to EVP_AES_GCM_CTX, which complicates things.
Thanks to Guido Vranken for catching this!
Bug: 270
Change-Id: I71784593dc5a34d1334c92a4daa93546ec0ee2c3
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35624
Reviewed-by: Adam Langley <agl@google.com>
AES_set_*_key used to call directly into aes_nohw_set_*_key which
gracefully handles some NULL parameters and invalid bit sizes. However,
we now enable optimized assembly implementations, not all of which
perform these checks. (vpaes does not.)
This is fine for the internal assembly functions themselves. Such checks
are better written in C than assembly, and the calling C code usually
already knows the key size. (Indeed aes_ctr_set_key already assumes the
assembly functions are infallible.) AES_set_*_key are public APIs,
however. The NULL check is silly, but we should handle length-like
checks in public APIs.
Change-Id: I259ae6b9811ceaa9dc5bd7173d5754ca7079cff8
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35564
Reviewed-by: Adam Langley <agl@google.com>
Test invalid nonce lengths more thoroughly to cover this case on all our
AEADs. Thanks to Guido Vranken for catching this!
In doing so, this also reveals we have a ton of redundant error codes
(https://crbug.com/boringssl/269). I'll tidy that up in a separate
change as it may require some changes to code in Android. For now, this
change uses CIPHER_R_UNSUPPORTED_NONCE_SIZE just to be consistent with
the rest of that file.
Bug: 268
Change-Id: I0a479000ec3005ee55c828eaa92c8302b4625847
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35545
Reviewed-by: Adam Langley <agl@google.com>
Child and root CBBs share a type, but are different kinds of things. C++
programmers sometimes mistakenly believe they should use ScopedCBB for
everything. This mostly works because we NULL cbb->child->base on flush,
making CBB_cleanup a no-op. This zeroing also skips the assert in
CBB_cleanup. (If we ran it unconditionally, CBB_zero + CBB_cleanup would
not work.)
However, if a CBB operation fails and a function returns early, the
child CBB is not cleared. ScopedCBB will then call CBB_cleanup which
trips the assert but, in release build, misbehaves.
Run the assert unconditionally and, when the assert fails, still behave
well. To make this work with CBB_zero, negate is_top_level to is_child,
so a flushed child CBB and a (presumably) root CBB in the zero state are
distinguishable.
Update-Note: Code that was using CBB wrong may trip an assert in debug builds.
Change-Id: Ifea7759e1d0331f2e727c59bbafa355d70fb9dba
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35524
Reviewed-by: Adam Langley <agl@google.com>
The new version of googletest deprecates INSTANTIATE_TEST_CASE_P in
favor of INSTANTIATE_TEST_SUITE_P, so apply the change.
This requires blacklisting C4628 on MSVC 2015 which says about digraphs
given foo<::std::tuple<...>>. Disable that warning. Digraphs are not
useful and C++11 apparently explicitly disambiguates that.
It also requires applying
https://github.com/google/googletest/pull/2226, to deal with a warning
in older MSVC.
Update-Note: Consumers using BoringSSL with their own copy of googletest
must ensure googletest was updated to a version from 2019-01-03 or
later for INSTANTIATE_TEST_SUITE_P to work. (I believe all relevant
consumers are fine here. If anyone can't update googletest and is
building BoringSSL tests, building with
-DINSTANTIATE_TEST_SUITE_P=INSTANTIATE_TEST_CASE_P would work as
workaround.)
Bug: chromium:936651
Change-Id: I23ada8de34a53131cab88a36a88d3185ab085c64
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35504
Reviewed-by: Adam Langley <agl@google.com>
We usually name output parameters 'out'. (Someone made a C++ templating
change in Chromium which messed up const-ness, saw the compile error,
and thought it was in MD5_Final.) Also tag the parameters with the
sizes.
Sadly, there's a bit of goofiness around SHA224_Final/SHA256_Final and
SHA384_Final/SHA512_Final, but they're just documentation anyway.
(Though it does touch on the mess that is sha->md_len which would be
nice to clear through somehow.)
Change-Id: I1918b7eecfe13f13b217d01d4414ac2358802354
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35484
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
The new version has trap flag emulation, which is great for our ABI
tests. This CL doesn't enable it yet, however. The emulation is slightly
off on when traps start and stop, so the ABI tester will need to tweaked
to be more lenient.
Change-Id: I0eb20176dc63eaa1c35f77379b34f7bb6c0b0407
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35464
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
When building node with boringssl, `SSL_CTX_get_min_proto_version` and
`SSL_CTX_get_max_proto_version` are used. Openssl exposes those; this
change adds support for boringssl.
For this to work right in DTLS, we switch conf_{min,max}_version to store wire
versions, rather than our internal normalized versions.
Change-Id: I282ed224806c41f69e6f166ca97c6cc05ff51f17
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35404
Reviewed-by: Nitish Sakhawalkar <nitsakh@gmail.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
With bsaes-x86_64.pl gone, it is no longer needed. Depending on how armv7 works
(if vpaes-armv7.pl is too slow AND on-demand vpaes->bsaes key conversion is not
viable), we may need to bring it back, but get it out of the way for now.
Bug: 256
Change-Id: I762c83097bd03d88574ae1ae16b88fca6826f655
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35365
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Brian Smith suggested applying vpaes-armv8's "2x" optimization to
vpaes-x86_64. The registers are a little tight (aarch64 has a whole 32
SIMD registers, while x86_64 only has 16), but it's doable with some
spills and makes vpaes much more competitive with bsaes. At small- and
medium-sized inputs, vpaes now matches bsaes. At large inputs, it's a
~10% perf hit.
bsaes is thus pulling much less weight. Losing an entire AES
implementation and having constant-time AES for SSSE3 is attractive.
Some notes:
- The fact that these are older CPUs tempers the perf hit, but CPUs
without AES-NI are still common enough to matter.
- This CL does regress CBC decrypt performance nontrivially (see below).
If this matters, we can double-up CBC decryption too. CBC in TLS is
legacy and already pays a costly Lucky13 mitigation.
- The difference between 1350 and 8192 bytes is likely bsaes AES-GCM
paying for two slow (and variable-time!) aes_nohw_encrypt
calls for EK0 and the trailing partial block. At larger inputs, those
two calls are more amortized.
- To that end, bsaes would likely be much faster on AES-GCM with smarter
use of bsaes. (Fold one-off calls above into bulk data.) Implementing
this is a bit of a nuisance though, especially considering we don't
wish to regress hwaes.
- I'd discarded the key conversion idea, but I think I did it wrong.
Benchmarks from
https://boringssl-review.googlesource.com/c/boringssl/+/33589 suggest
converting to bsaes format on-demand for large ctr32 inputs should
give the best of both worlds, but at the cost of an entire AES
implementation relative to this CL.
- ARMv7 still depends on bsaes and has no vpaes. It also has 16 SIMD
registers, so my plan is to translate it, with the same 2x
optimization, and see how it compares. Hopefully that, or some
combination of the above, will work for ARMv7.
Sandy Bridge
bsaes (before):
Did 3144750 AES-128-GCM (16 bytes) seal operations in 5016000us (626943.8 ops/sec): 10.0 MB/s
Did 2053750 AES-128-GCM (256 bytes) seal operations in 5016000us (409439.8 ops/sec): 104.8 MB/s
Did 469000 AES-128-GCM (1350 bytes) seal operations in 5015000us (93519.4 ops/sec): 126.3 MB/s
Did 92500 AES-128-GCM (8192 bytes) seal operations in 5016000us (18441.0 ops/sec): 151.1 MB/s
Did 46750 AES-128-GCM (16384 bytes) seal operations in 5032000us (9290.5 ops/sec): 152.2 MB/s
vpaes-1x (for reference, not this CL):
Did 8684750 AES-128-GCM (16 bytes) seal operations in 5015000us (1731754.7 ops/sec): 27.7 MB/s [+177%]
Did 1731500 AES-128-GCM (256 bytes) seal operations in 5016000us (345195.4 ops/sec): 88.4 MB/s [-15.6%]
Did 346500 AES-128-GCM (1350 bytes) seal operations in 5016000us (69078.9 ops/sec): 93.3 MB/s [-26.1%]
Did 61250 AES-128-GCM (8192 bytes) seal operations in 5015000us (12213.4 ops/sec): 100.1 MB/s [-33.8%]
Did 32500 AES-128-GCM (16384 bytes) seal operations in 5031000us (6459.9 ops/sec): 105.8 MB/s [-30.5%]
vpaes-2x (this CL):
Did 8840000 AES-128-GCM (16 bytes) seal operations in 5015000us (1762711.9 ops/sec): 28.2 MB/s [+182%]
Did 2167750 AES-128-GCM (256 bytes) seal operations in 5016000us (432167.1 ops/sec): 110.6 MB/s [+5.5%]
Did 474000 AES-128-GCM (1350 bytes) seal operations in 5016000us (94497.6 ops/sec): 127.6 MB/s [+1.0%]
Did 81750 AES-128-GCM (8192 bytes) seal operations in 5015000us (16301.1 ops/sec): 133.5 MB/s [-11.6%]
Did 41750 AES-128-GCM (16384 bytes) seal operations in 5031000us (8298.5 ops/sec): 136.0 MB/s [-10.6%]
Penryn
bsaes (before):
Did 958000 AES-128-GCM (16 bytes) seal operations in 1000264us (957747.2 ops/sec): 15.3 MB/s
Did 420000 AES-128-GCM (256 bytes) seal operations in 1000480us (419798.5 ops/sec): 107.5 MB/s
Did 96000 AES-128-GCM (1350 bytes) seal operations in 1001083us (95896.1 ops/sec): 129.5 MB/s
Did 18000 AES-128-GCM (8192 bytes) seal operations in 1042491us (17266.3 ops/sec): 141.4 MB/s
Did 9482 AES-128-GCM (16384 bytes) seal operations in 1095703us (8653.8 ops/sec): 141.8 MB/s
Did 758000 AES-256-GCM (16 bytes) seal operations in 1000769us (757417.5 ops/sec): 12.1 MB/s
Did 359000 AES-256-GCM (256 bytes) seal operations in 1001993us (358285.9 ops/sec): 91.7 MB/s
Did 82000 AES-256-GCM (1350 bytes) seal operations in 1009583us (81221.7 ops/sec): 109.6 MB/s
Did 15000 AES-256-GCM (8192 bytes) seal operations in 1022294us (14672.9 ops/sec): 120.2 MB/s
Did 7884 AES-256-GCM (16384 bytes) seal operations in 1070934us (7361.8 ops/sec): 120.6 MB/s
vpaes-1x (for reference, not this CL):
Did 2030000 AES-128-GCM (16 bytes) seal operations in 1000227us (2029539.3 ops/sec): 32.5 MB/s [+112%]
Did 382000 AES-128-GCM (256 bytes) seal operations in 1001949us (381256.9 ops/sec): 97.6 MB/s [-9.2%]
Did 81000 AES-128-GCM (1350 bytes) seal operations in 1007297us (80413.2 ops/sec): 108.6 MB/s [-16.1%]
Did 14000 AES-128-GCM (8192 bytes) seal operations in 1031499us (13572.5 ops/sec): 111.2 MB/s [-21.4%]
Did 7008 AES-128-GCM (16384 bytes) seal operations in 1030706us (6799.2 ops/sec): 111.4 MB/s [-21.4%]
Did 1838000 AES-256-GCM (16 bytes) seal operations in 1000238us (1837562.7 ops/sec): 29.4 MB/s [+143%]
Did 321000 AES-256-GCM (256 bytes) seal operations in 1001666us (320466.1 ops/sec): 82.0 MB/s [-10.6%]
Did 67000 AES-256-GCM (1350 bytes) seal operations in 1010359us (66313.1 ops/sec): 89.5 MB/s [-18.3%]
Did 12000 AES-256-GCM (8192 bytes) seal operations in 1072706us (11186.7 ops/sec): 91.6 MB/s [-23.8%]
Did 5680 AES-256-GCM (16384 bytes) seal operations in 1009214us (5628.1 ops/sec): 92.2 MB/s [-23.5%]
vpaes-2x (this CL):
Did 2072000 AES-128-GCM (16 bytes) seal operations in 1000066us (2071863.3 ops/sec): 33.1 MB/s [+116%]
Did 432000 AES-128-GCM (256 bytes) seal operations in 1000732us (431684.0 ops/sec): 110.5 MB/s [+2.8%]
Did 92000 AES-128-GCM (1350 bytes) seal operations in 1000580us (91946.7 ops/sec): 124.1 MB/s [-4.2%]
Did 16000 AES-128-GCM (8192 bytes) seal operations in 1016422us (15741.5 ops/sec): 129.0 MB/s [-8.8%]
Did 8448 AES-128-GCM (16384 bytes) seal operations in 1073962us (7866.2 ops/sec): 128.9 MB/s [-9.1%]
Did 1865000 AES-256-GCM (16 bytes) seal operations in 1000043us (1864919.8 ops/sec): 29.8 MB/s [+146%]
Did 364000 AES-256-GCM (256 bytes) seal operations in 1001561us (363432.7 ops/sec): 93.0 MB/s [+1.4%]
Did 77000 AES-256-GCM (1350 bytes) seal operations in 1004123us (76683.8 ops/sec): 103.5 MB/s [-5.6%]
Did 14000 AES-256-GCM (8192 bytes) seal operations in 1071179us (13069.7 ops/sec): 107.1 MB/s [-10.9%]
Did 7008 AES-256-GCM (16384 bytes) seal operations in 1074125us (6524.4 ops/sec): 106.9 MB/s [-11.4%]
Penryn, CBC mode decryption
bsaes (before):
Did 159000 AES-128-CBC-SHA1 (16 bytes) open operations in 1001019us (158838.1 ops/sec): 2.5 MB/s
Did 114000 AES-128-CBC-SHA1 (256 bytes) open operations in 1006485us (113265.5 ops/sec): 29.0 MB/s
Did 65000 AES-128-CBC-SHA1 (1350 bytes) open operations in 1008441us (64455.9 ops/sec): 87.0 MB/s
Did 17000 AES-128-CBC-SHA1 (8192 bytes) open operations in 1005440us (16908.0 ops/sec): 138.5 MB/s
vpaes (after):
Did 167000 AES-128-CBC-SHA1 (16 bytes) open operations in 1003556us (166408.3 ops/sec): 2.7 MB/s [+8%]
Did 112000 AES-128-CBC-SHA1 (256 bytes) open operations in 1005673us (111368.2 ops/sec): 28.5 MB/s [-1.7%]
Did 56000 AES-128-CBC-SHA1 (1350 bytes) open operations in 1005647us (55685.5 ops/sec): 75.2 MB/s [-13.6%]
Did 13635 AES-128-CBC-SHA1 (8192 bytes) open operations in 1020486us (13361.3 ops/sec): 109.5 MB/s [-20.9%]
Bug: 256
Change-Id: I11ed773323ec7a5ee61080c9ed9ed4761849828a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35364
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
When servers have a lot of data to send and aren't as latency-sensitive,
it makes sense to send large TLS records, so we care about measuring
both packet-sized and full-sized payloads.
Change-Id: Ib0cf5e0f8660f68a98a04fa86b5989d4a485528b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35344
Reviewed-by: Adam Langley <agl@google.com>
While allocating near INT_MAX BIGNUMs or stack frames would never happen, we
should properly handle overflow here. Rewrite it to just be a STACK_OF(BIGNUM)
plus a stack of indices. Also simplify the error-handling. If we make the
errors truly sticky (rather than just sticky per frame), we don't need to keep
track of err_stack and friends.
Thanks to mlbrown for reporting the integer overflows in the original
implementation.
Bug: chromium:942269
Change-Id: Ie9c9baea3eeb82d65d88b1cb1388861f5cd84fe5
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35328
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
BN_mod_exp_mont is most commonly used in RSA verification, where the exponent
sizes are small enough to use 1-bit "windows". There's no need to allocate the
extra BIGNUM.
Change-Id: I14fb523dfae7d77d2cec10a0209f09f22031d1af
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35327
Reviewed-by: Adam Langley <agl@google.com>
The legacy ASN.1 stack contains an unsalvageable mix of integer types.
82dfea8d9e bounded all inputs to the template
machinery, but sometimes code will call ASN1_get_object directly, such as the
just deleted d2i_ASN1_UINTEGER.
Thanks to mlbrown for reporting the d2i_ASN1_UINTEGER overflow.
Bug: chromium:942269
Change-Id: I2d4c8b7faf5dadd1b68dbdb51a5feae071ea2cb6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35325
Reviewed-by: Adam Langley <agl@google.com>
When the CBC and CTR EVP_CIPHER implementations use bsaes, they never
call dat->block. Note this is *not* true of aes_ctr_set_key which is
used in contexts where it needs single-block operations.
Bug: 256
Change-Id: Ibea4f2117a2220cd5cb09f6cf12b7a50c28bf794
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35168
Reviewed-by: Adam Langley <agl@google.com>
This makes AES-GCM always constant-time on aarch64 (provided assembly is
enabled). Unlike vpaes, this does come at a binary size penalty of 1K
compared to the gcm_*_4bit version.
ABI testing already covered by GCMTest.ABI (GHASH_ASM_ARM covers both
OPENSSL_ARM and OPENSSL_AARCH64.)
Cortex-A53 (Raspberry Pi 3 Model B+)
Before:
Did 274000 AES-128-GCM (16 bytes) seal operations in 1003461us (273055.0 ops/sec): 4.4 MB/s
Did 53000 AES-128-GCM (256 bytes) seal operations in 1007689us (52595.6 ops/sec): 13.5 MB/s
Did 12000 AES-128-GCM (1350 bytes) seal operations in 1075908us (11153.4 ops/sec): 15.1 MB/s
Did 2068 AES-128-GCM (8192 bytes) seal operations in 1089037us (1898.9 ops/sec): 15.6 MB/s
After:
Did 298000 AES-128-GCM (16 bytes) seal operations in 1002917us (297133.3 ops/sec): 4.8 MB/s
Did 64000 AES-128-GCM (256 bytes) seal operations in 1001124us (63928.1 ops/sec): 16.4 MB/s
Did 14000 AES-128-GCM (1350 bytes) seal operations in 1015477us (13786.6 ops/sec): 18.6 MB/s
Did 2497 AES-128-GCM (8192 bytes) seal operations in 1057951us (2360.2 ops/sec): 19.3 MB/s
Bug: 265
Change-Id: I251bf0f2eae0578580bb14192755e5d8ff64cd14
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35285
Reviewed-by: Adam Langley <agl@google.com>
This plugs all bsaes fallback leaks for CBC outside of the key schedule.
The CBC EVP_CIPHERs never call the block function directly when there's
a stream.cbc function available.
This affects CBC decryptions of length < 128 or 16 mod 128.
Performance-wise, we don't really care about CBC apart from passing
glances at its use in TLS. There, the Lucky13 workaround mutes the
effects.
Cortex-A53 (Raspberry Pi 3 Model B+)
Before:
Did 78000 AES-128-CBC-SHA1 (16 bytes) open operations in 3020254us (25825.6 ops/sec): 0.4 MB/s
Did 75000 AES-128-CBC-SHA1 (32 bytes) open operations in 3005760us (24952.1 ops/sec): 0.8 MB/s
Did 71000 AES-128-CBC-SHA1 (64 bytes) open operations in 3038137us (23369.6 ops/sec): 1.5 MB/s
Did 67000 AES-128-CBC-SHA1 (96 bytes) open operations in 3027686us (22129.1 ops/sec): 2.1 MB/s
Did 64000 AES-128-CBC-SHA1 (112 bytes) open operations in 3005491us (21294.4 ops/sec): 2.4 MB/s
Did 59000 AES-128-CBC-SHA1 (128 bytes) open operations in 3020083us (19535.9 ops/sec): 2.5 MB/s
Did 53000 AES-128-CBC-SHA1 (240 bytes) open operations in 3020105us (17549.1 ops/sec): 4.2 MB/s
After:
Did 71668 AES-128-CBC-SHA1 (16 bytes) open operations in 3020896us (23724.1 ops/sec): 0.4 MB/s
Did 71000 AES-128-CBC-SHA1 (32 bytes) open operations in 3040826us (23348.9 ops/sec): 0.7 MB/s
Did 68000 AES-128-CBC-SHA1 (64 bytes) open operations in 3009913us (22592.0 ops/sec): 1.4 MB/s
Did 66000 AES-128-CBC-SHA1 (96 bytes) open operations in 3007597us (21944.4 ops/sec): 2.1 MB/s
Did 59000 AES-128-CBC-SHA1 (112 bytes) open operations in 3002878us (19647.8 ops/sec): 2.2 MB/s
Did 59000 AES-128-CBC-SHA1 (128 bytes) open operations in 3046786us (19364.7 ops/sec): 2.5 MB/s
Did 50000 AES-128-CBC-SHA1 (240 bytes) open operations in 3043643us (16427.7 ops/sec): 3.9 MB/s
Penryn (Mac mini, mid 2010)
Before:
Did 152000 AES-128-CBC-SHA1 (16 bytes) open operations in 1004422us (151330.8 ops/sec): 2.4 MB/s
Did 143000 AES-128-CBC-SHA1 (32 bytes) open operations in 1000443us (142936.7 ops/sec): 4.6 MB/s
Did 136000 AES-128-CBC-SHA1 (48 bytes) open operations in 1006580us (135111.0 ops/sec): 6.5 MB/s
Did 146000 AES-128-CBC-SHA1 (96 bytes) open operations in 1005731us (145168.0 ops/sec): 13.9 MB/s
Did 138000 AES-128-CBC-SHA1 (112 bytes) open operations in 1003330us (137542.0 ops/sec): 15.4 MB/s
Did 133000 AES-128-CBC-SHA1 (128 bytes) open operations in 1005876us (132223.1 ops/sec): 16.9 MB/s
Did 117000 AES-128-CBC-SHA1 (240 bytes) open operations in 1004922us (116426.9 ops/sec): 27.9 MB/s
After:
Did 159000 AES-128-CBC-SHA1 (16 bytes) open operations in 1000505us (158919.7 ops/sec): 2.5 MB/s
Did 157000 AES-128-CBC-SHA1 (32 bytes) open operations in 1006091us (156049.5 ops/sec): 5.0 MB/s
Did 154000 AES-128-CBC-SHA1 (48 bytes) open operations in 1002720us (153582.3 ops/sec): 7.4 MB/s
Did 146000 AES-128-CBC-SHA1 (96 bytes) open operations in 1002567us (145626.2 ops/sec): 14.0 MB/s
Did 135000 AES-128-CBC-SHA1 (112 bytes) open operations in 1001212us (134836.6 ops/sec): 15.1 MB/s
Did 133000 AES-128-CBC-SHA1 (128 bytes) open operations in 1006441us (132148.8 ops/sec): 16.9 MB/s
Did 115000 AES-128-CBC-SHA1 (240 bytes) open operations in 1005246us (114399.9 ops/sec): 27.5 MB/s
Bug: 256
Change-Id: I864b4455ada0d4d245380fce6f869dabb0686354
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35167
Reviewed-by: Adam Langley <agl@google.com>
bsaes_ctr32_encrypt_blocks previously fell back to the table-based
aes_nohw_encrypt for inputs under 128 bytes. Instead, just run the usual
bsaes code, though it means we compute more blocks than needed.
This fixes some (but not all) the timing leaks and is needed for later
bsaes work.
Performance-wise, x86_64 actually sees a performance improvement for all but
tiny inputs. ARM does see a loss at small inputs however.
Cortex-A53 (Raspberry Pi 3 Model B+)
Before:
Did 299000 AES-128-GCM (16 bytes) seal operations in 1001123us (298664.6 ops/sec): 4.8 MB/s
Did 236000 AES-128-GCM (32 bytes) seal operations in 1001611us (235620.4 ops/sec): 7.5 MB/s
Did 167000 AES-128-GCM (64 bytes) seal operations in 1005706us (166052.5 ops/sec): 10.6 MB/s
Did 129000 AES-128-GCM (96 bytes) seal operations in 1006129us (128214.2 ops/sec): 12.3 MB/s
Did 116000 AES-128-GCM (112 bytes) seal operations in 1006302us (115273.5 ops/sec): 12.9 MB/s
Did 107000 AES-128-GCM (128 bytes) seal operations in 1000986us (106894.6 ops/sec): 13.7 MB/s
After:
Did 132000 AES-128-GCM (16 bytes) seal operations in 1005165us (131321.7 ops/sec): 2.1 MB/s
Did 128000 AES-128-GCM (32 bytes) seal operations in 1005966us (127240.9 ops/sec): 4.1 MB/s
Did 120000 AES-128-GCM (64 bytes) seal operations in 1003080us (119631.5 ops/sec): 7.7 MB/s
Did 113000 AES-128-GCM (96 bytes) seal operations in 1000557us (112937.1 ops/sec): 10.8 MB/s
Did 110000 AES-128-GCM (112 bytes) seal operations in 1000407us (109955.2 ops/sec): 12.3 MB/s
Did 108000 AES-128-GCM (128 bytes) seal operations in 1008830us (107054.7 ops/sec): 13.7 MB/s
(Inputs 128 bytes and up are unaffected by this CL.)
Nexus 7
Before:
Did 544000 AES-128-GCM (16 bytes) seal operations in 1001282us (543303.5 ops/sec): 8.7 MB/s
Did 475750 AES-128-GCM (32 bytes) seal operations in 1000244us (475633.9 ops/sec): 15.2 MB/s
Did 370500 AES-128-GCM (64 bytes) seal operations in 1000519us (370307.8 ops/sec): 23.7 MB/s
Did 300750 AES-128-GCM (96 bytes) seal operations in 1000122us (300713.3 ops/sec): 28.9 MB/s
Did 275750 AES-128-GCM (112 bytes) seal operations in 1000702us (275556.6 ops/sec): 30.9 MB/s
Did 251000 AES-128-GCM (128 bytes) seal operations in 1000214us (250946.3 ops/sec): 32.1 MB/s
After:
Did 296000 AES-128-GCM (16 bytes) seal operations in 1001129us (295666.2 ops/sec): 4.7 MB/s
Did 288750 AES-128-GCM (32 bytes) seal operations in 1000488us (288609.2 ops/sec): 9.2 MB/s
Did 267250 AES-128-GCM (64 bytes) seal operations in 1000641us (267078.8 ops/sec): 17.1 MB/s
Did 253250 AES-128-GCM (96 bytes) seal operations in 1000915us (253018.5 ops/sec): 24.3 MB/s
Did 248000 AES-128-GCM (112 bytes) seal operations in 1000091us (247977.4 ops/sec): 27.8 MB/s
Did 249000 AES-128-GCM (128 bytes) seal operations in 1000794us (248802.5 ops/sec): 31.8 MB/s
Penryn (Mac mini, mid 2010)
Before:
Did 1331000 AES-128-GCM (16 bytes) seal operations in 1000263us (1330650.0 ops/sec): 21.3 MB/s
Did 991000 AES-128-GCM (32 bytes) seal operations in 1000274us (990728.5 ops/sec): 31.7 MB/s
Did 780000 AES-128-GCM (48 bytes) seal operations in 1000278us (779783.2 ops/sec): 37.4 MB/s
Did 483000 AES-128-GCM (96 bytes) seal operations in 1000137us (482933.8 ops/sec): 46.4 MB/s
Did 428000 AES-128-GCM (112 bytes) seal operations in 1001132us (427516.1 ops/sec): 47.9 MB/s
Did 682000 AES-128-GCM (128 bytes) seal operations in 1000564us (681615.6 ops/sec): 87.2 MB/s
After:
Did 953000 AES-128-GCM (16 bytes) seal operations in 1000385us (952633.2 ops/sec): 15.2 MB/s
Did 903000 AES-128-GCM (32 bytes) seal operations in 1000998us (902099.7 ops/sec): 28.9 MB/s
Did 850000 AES-128-GCM (48 bytes) seal operations in 1000938us (849203.4 ops/sec): 40.8 MB/s
Did 736000 AES-128-GCM (96 bytes) seal operations in 1000886us (735348.5 ops/sec): 70.6 MB/s
Did 702000 AES-128-GCM (112 bytes) seal operations in 1000657us (701539.1 ops/sec): 78.6 MB/s
Did 676000 AES-128-GCM (128 bytes) seal operations in 1000405us (675726.3 ops/sec): 86.5 MB/s
Bug: 256
Change-Id: I9403da607dd1feaff7b3c9b76fe78b66018fb753
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35166
Reviewed-by: Adam Langley <agl@google.com>
glibc inlines bsearch, so CFI does observe the function pointer mishap.
Binary search is easy enough, aside from thinking through the edge case
at the end, so just implement it by hand. As a bonus, it actually gives
O(lg N) behavior.
sk_*_find needs to return the *first* match, while bsearch does not
promise a particular one. sk_find thus performs a fixup step to find the
first one, but this is linear in the number of matching elements.
Instead, the binary search should take this into account.
This still leaves qsort, but it's not inlined, so hopefully we can leave
it alone.
Bug: chromium:941463
Change-Id: I5c94d6b15423beea3bdb389639466f8b3ff0dc5d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35304
Reviewed-by: Adam Langley <agl@google.com>
With all those structures made opaque, it's not really useful as a build
sanity-check anymore.
Update-Note: This function is removed, but I don't see any actual uses.
Change-Id: Ib5640e778466da980596e7085d97104d22aa9d33
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35184
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
The AES-GCM-SIV code does not use ctr128_f at all so bsaes is simply
identical to aes_nohw. Also, while CCM encrypts with CTR mode, its MAC
is not parallelizable at all.
(Given the existence of non-parallelizable modes, we ought to make a
vpaes-armv7.pl to ensure constant-time AES on NEON. For now, pick the
right implementation for x86_64 at least.)
aes_ctr_set_key and friends probably aren't the right abstraction
(observe the large vs small inputs hint *almost* matches whether you
touch block128_f), but the right abstraction depends on a couple
questions:
- If you don't provide ctr128_f, is there a perf hit to implementing
ctr128_f on top of your block128_f to unify calling code?
- It is almost certainly better to use bsaes with gcm.c by calling
ctr128_f exclusively and paying some copies (a dedicated calling
convention would be even better, but would be a headache) to integrate
leading and trailing blocks into the CTR pass. Is this a win, loss, or
no-op for hwaes, where block128_f is just fine? hwaes is the one mode
we really should not regress.
Hopefully those will get answered as we continue to chip away at this.
Bug: 256
Change-Id: I8f0150b223b671e68f7da6faaff94a3bea398d4d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35169
Reviewed-by: Adam Langley <agl@google.com>
OpenSSL's BN_mul function had a single-word buffer underflow (see
576129cd72ae054d246221f111aabf42b9c6d76d). We already independently
fixed this but, if we hadn't, ASan wouldn't have noticed because of
OPENSSL_malloc.
ASan has runtime hooks we can call to make it more accurate.
Change-Id: Ifc9c3837ece2bc456c5bdc960be707d7b1759904
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35165
Reviewed-by: Adam Langley <agl@google.com>
This patches vpaes-armv8.pl to add vpaes_ctr32_encrypt_blocks. CTR mode
is by far the most important mode these days. It should have access to
_vpaes_encrypt_2x, which gives a considerable speed boost. Also exclude
vpaes_ecb_* as they're not even used.
For iOS, this change is completely a no-op. iOS ARMv8 always has crypto
extensions, and we already statically drop all other AES
implementations.
Android ARMv8 is *not* required to have crypto extensions, but every
ARMv8 device I've seen has them. For those, it is a no-op
performance-wise and a win on size. vpaes appears to be about 5.6KiB
smaller than the tables. ARMv8 always makes SIMD (NEON) available, so we
can statically drop aes_nohw.
In theory, however, crypto-less Android ARMv8 is possible. Today such
chips get a variable-time AES. This CL fixes this, but the performance
story is complex.
The Raspberry Pi 3 is not Android but has a Cortex-A53 chip
without crypto extensions. (But the official images are 32-bit, so even
this is slightly artificial...) There, vpaes is a performance win.
Raspberry Pi 3, Model B+, Cortex-A53
Before:
Did 265000 AES-128-GCM (16 bytes) seal operations in 1003312us (264125.2 ops/sec): 4.2 MB/s
Did 44000 AES-128-GCM (256 bytes) seal operations in 1002141us (43906.0 ops/sec): 11.2 MB/s
Did 9394 AES-128-GCM (1350 bytes) seal operations in 1032104us (9101.8 ops/sec): 12.3 MB/s
Did 1562 AES-128-GCM (8192 bytes) seal operations in 1008982us (1548.1 ops/sec): 12.7 MB/s
After:
Did 277000 AES-128-GCM (16 bytes) seal operations in 1001884us (276479.1 ops/sec): 4.4 MB/s
Did 52000 AES-128-GCM (256 bytes) seal operations in 1001480us (51923.2 ops/sec): 13.3 MB/s
Did 11000 AES-128-GCM (1350 bytes) seal operations in 1007979us (10912.9 ops/sec): 14.7 MB/s
Did 2013 AES-128-GCM (8192 bytes) seal operations in 1085545us (1854.4 ops/sec): 15.2 MB/s
The Pixel 3 has a Cortex-A75 with crypto extensions, so it would never
run this code. However, artificially ignoring them gives another data
point (ARM documentation[*] suggests the extensions are still optional
on a Cortex-A75.) Sadly, vpaes no longer wins on perf over aes_nohw.
But, it is constant-time:
Pixel 3, AES/PMULL extensions ignored, Cortex-A75:
Before:
Did 2102000 AES-128-GCM (16 bytes) seal operations in 1000378us (2101205.7 ops/sec): 33.6 MB/s
Did 358000 AES-128-GCM (256 bytes) seal operations in 1002658us (357051.0 ops/sec): 91.4 MB/s
Did 75000 AES-128-GCM (1350 bytes) seal operations in 1012830us (74049.9 ops/sec): 100.0 MB/s
Did 13000 AES-128-GCM (8192 bytes) seal operations in 1036524us (12541.9 ops/sec): 102.7 MB/s
After:
Did 1453000 AES-128-GCM (16 bytes) seal operations in 1000213us (1452690.6 ops/sec): 23.2 MB/s
Did 285000 AES-128-GCM (256 bytes) seal operations in 1002227us (284366.7 ops/sec): 72.8 MB/s
Did 60000 AES-128-GCM (1350 bytes) seal operations in 1016106us (59049.0 ops/sec): 79.7 MB/s
Did 11000 AES-128-GCM (8192 bytes) seal operations in 1094184us (10053.2 ops/sec): 82.4 MB/s
Note the numbers above run with PMULL off, so the slow GHASH is
dampening the regression. If we test aes_nohw and vpaes paired with
PMULL on, the 20% perf hit becomes a 31% hit. The PMULL-less variant is
more likely to represent a real chip.
This is consistent with upstream's note in the comment, though it is
unclear if 20% is the right order of magnitude: "these results are worse
than scalar compiler-generated code, but it's constant-time and
therefore preferred".
[*] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.100458_0301_00_en/lau1442495529696.html
Bug: 246
Change-Id: If1dc87f5131fce742052498295476fbae4628dbf
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35026
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This is done separately to make the diffs in the subsequent CL easier to
see. Imported from OpenSSL at revision
25ca718150cef41e1c1d9c2c8c58e2b1e2cad3fa.
Bug: 246
Change-Id: I9e7067ea177963fb9b77bf6fb39702ffe6e34ed4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35025
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
The 64-bit version can be fairly straightforwardly translated.
Ironically, this makes 32-bit x86 the first architecture to meet the
goal of constant-time AES-GCM given SIMD assembly. (Though x86_64 could
join by simply giving up on bsaes...)
Bug: 263
Change-Id: Icb2cec936457fac7132bbb5dbb094433bc14b86e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35024
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
The test_support is kind of a mess right now because it's sometimes used in
GTest targets and sometimes not. It really should be split into two libraries,
but do this for now to unbreak the Android build.
Change-Id: I7cd2b0f6ed9eda1a529ec3c69a92390e20da66f8
Reviewed-on: https://boringssl-review.googlesource.com/c/35084
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
The Android NDK docs link to a ARM GNU/Linux Application Binary Interface
Supplement document. Also fix a type in trampoline-armv4.pl. The generic ARM
document is usually shortened AAPCS, not APCS.
I couldn't find a corresponding link for aarch64.
Change-Id: I6e5543f5c9e26955cd3945e9e7a5dcff27c2bd78
Reviewed-on: https://boringssl-review.googlesource.com/c/35064
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
OpenSSL's c1669e1c205dc8e695fb0c10a655f434e758b9f7 switched it to
__ARM_MAX_ARCH__, which we mirrored in assembly but not C. The C version
should be __ARM_MAX_ARCH__ to match. However, __ARM_MAX_ARCH__ is
hardcoded to 8, so just remove the check.
Change-Id: Ic873203db1478f49437b889b84ee7fb28eba1a6d
Reviewed-on: https://boringssl-review.googlesource.com/c/35045
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
bsaes, in its current incarnation, hits various pathological behaviors
at different input sizes. Make it easy to experiment around them.
Bug: 256
Change-Id: Ib6c6ca7d06a570dbf7d4d2ea81c1db0d94d3d0c4
Reviewed-on: https://boringssl-review.googlesource.com/c/34876
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
GCC notices that one function believes < 0 is the error while the other
believes it's != 0. unw_get_reg never returns positive, but match them.
Change-Id: I40af614e6b1400bf3d398bd32beb6d3ec702bc11
Reviewed-on: https://boringssl-review.googlesource.com/c/34985
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
This makes the AES_* functions meet our constant-time goals for
platforms where we have vpaes available. In particular, QUIC packet
number encryption needs single-block operations and those should have
vpaes available.
As a bonus, when vpaes is statically available, the aes_nohw_* functions
should be dropped by the linker. (Notably, NEON is guaranteed on
aarch64. Although vpaes-armv8.pl itself may take some more exploration.
https://crbug.com/boringssl/246#c4)
Bug: 263
Change-Id: Ie1c4727a166ec101a8453761757c87dadc188769
Reviewed-on: https://boringssl-review.googlesource.com/c/34875
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
In particular, consistently pair bsaes with aes_nohw.
Ideally the aes_nohw_* calls in bsaes-*.pl would be patched out and
bsaes grows its own constant-time key setup
(https://crbug.com/boringssl/256), but I'll sort that out separately. In
the meantime, avoid going through AES_* which now dispatch. This avoids
several nuisances:
1. If we were to add, say, a vpaes-armv7.pl the ABI tests would break.
Fundamentally, we cannot assume that an AES_KEY has one and only one
representation and must keep everything matching up.
2. AES_* functions should enable vpaes. This makes AES_* faster and
constant-time for vector-capable CPUs
(https://crbug.com/boringssl/263), relevant for QUIC packet number
encryption, allowing us to add vpaes-armv8.pl
(https://crbug.com/boringssl/246) without carrying a (likely) mostly
unused AES implementation.
3. It's silly to double-dispatch when the EVP layer has already
dispatched.
4. We should avoid asm calling into C. Otherwise, we need to test asm
for ABI compliance as both caller and callee. Currently we only test
it for callee compliance. When asm calls into asm, it *should* comply
with the ABI as caller too, but mistakes don't matter as long as the
called function triggers it. If the function is asm, this is fixed.
If it is C, we must care about arbitrary C compiler output.
Bug: 263
Change-Id: Ic85af5c765fd57cbffeaf301c3872bad6c5bbf78
Reviewed-on: https://boringssl-review.googlesource.com/c/34874
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Unfortunately, it's not enough to be able to turn it on thanks to the
PURE_VIRTUAL macro. But it gets us most of the way there.
Change-Id: Ie6ad5119fcfd420115fa49d7312f3586890244f4
Reviewed-on: https://boringssl-review.googlesource.com/c/34949
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Go 1.12 really wants to record a version in go.mod if there is no
version in there. 1.12 is not yet released, so stick 1.11 in there for
now. We'll bump it to 1.12 and so on as we update our minimum versions.
Change-Id: I79ac85837149ab7cadd2f23acd8ab2d207a1a355
Reviewed-on: https://boringssl-review.googlesource.com/c/34924
Reviewed-by: Adam Langley <agl@google.com>
STRICT_ALIGNMENT is a remnant of OpenSSL code would cast pointers to
size_t* and load more than one byte at a time. Not all architectures
support unaligned access, so it did an alignment check and only enterred
this path if aligned or the underlying architecture didn't care.
This is UB. Unaligned casts in C are undefined on all architectures, so
we switch these to memcpy some time ago. Compilers can optimize memcpy
to the unaligned accesses we wanted. That left our modes logic as:
- If STRICT_ALIGNMENT is 1 and things are unaligned, work byte-by-byte.
- Otherwise, use the memcpy-based word-by-word code, which now works
independent of STRICT_ALIGNMENT.
Remove the first check to simplify things. On x86, x86_64, and aarch64,
STRICT_ALIGNMENT is zero and this is a no-op. ARM is more complex. Per
[0], ARMv7 and up support unaligned access. ARMv5 do not. ARMv6 does,
but can run in a mode where it looks more like ARMv5.
For ARMv7 and up, STRICT_ALIGNMENT should have been zero, but was one.
Thus this change should be an improvement for ARMv7 (right now unaligned
inputs lose bsaes-armv7). The Android NDK does not even support the
pre-ARMv7 ABI anymore[1]. Nonetheless, Cronet still supports ARMv6 as a
library. It builds with -march=armv6 which GCC interprets as supporting
unaligned access, so it too did not want this code.
For completeness, should anyone still care about ARMv5 or be building
with an overly permissive -march flag, GCC does appear unable to inline
the memcpy calls. However, GCC also does not interpret
(uintptr_t)ptr % sizeof(size_t) as an alignment assertion, so such
consumers have already been paying for the memcpy here and throughout
the library.
In general, C's arcane pointer rules mean we must resort to memcpy
often, so, realistically, we must require that the compiler optimize
memcpy well.
[0] https://medium.com/@iLevex/the-curious-case-of-unaligned-access-on-arm-5dd0ebe24965
[1] https://developer.android.com/ndk/guides/abis#armeabi
Change-Id: I3c7dea562adaeb663032e395499e69530dd8e145
Reviewed-on: https://boringssl-review.googlesource.com/c/34873
Reviewed-by: Adam Langley <agl@google.com>
Independent of the underlying CPU architecture, casting unaligned
pointers to uint64_t* is undefined. Just use a memcpy. The compiler
should be able to optimize that itself.
Change-Id: I39210871fca3eaf1f4b1d205b2bb0c337116d9cc
Reviewed-on: https://boringssl-review.googlesource.com/c/34872
Reviewed-by: Adam Langley <agl@google.com>
There is a C implementation of gcm_ghash_4bit to pair with
gcm_gmult_4bit. It's even slightly faster per the numbers below (x86_64
OPENSSL_NO_ASM build), but, more importantly, we trim down the
combinatorial explosion of GCM implementations and free up complexity
budget for potentially using bsaes better in the future.
Old:
Did 2557000 AES-128-GCM (16 bytes) seal operations in 1000057us (2556854.3 ops/sec): 40.9 MB/s
Did 94000 AES-128-GCM (1350 bytes) seal operations in 1009613us (93105.0 ops/sec): 125.7 MB/s
Did 17000 AES-128-GCM (8192 bytes) seal operations in 1024768us (16589.1 ops/sec): 135.9 MB/s
Did 2511000 AES-256-GCM (16 bytes) seal operations in 1000196us (2510507.9 ops/sec): 40.2 MB/s
Did 84000 AES-256-GCM (1350 bytes) seal operations in 1000412us (83965.4 ops/sec): 113.4 MB/s
Did 15000 AES-256-GCM (8192 bytes) seal operations in 1046963us (14327.2 ops/sec): 117.4 MB/s
New:
Did 2739000 AES-128-GCM (16 bytes) seal operations in 1000322us (2738118.3 ops/sec): 43.8 MB/s
Did 100000 AES-128-GCM (1350 bytes) seal operations in 1008190us (99187.7 ops/sec): 133.9 MB/s
Did 17000 AES-128-GCM (8192 bytes) seal operations in 1006360us (16892.6 ops/sec): 138.4 MB/s
Did 2546000 AES-256-GCM (16 bytes) seal operations in 1000150us (2545618.2 ops/sec): 40.7 MB/s
Did 86000 AES-256-GCM (1350 bytes) seal operations in 1000970us (85916.7 ops/sec): 116.0 MB/s
Did 14850 AES-256-GCM (8192 bytes) seal operations in 1023459us (14509.6 ops/sec): 118.9 MB/s
While I'm here, tighten up some of the functions and align the ctr32 and
non-ctr32 paths.
Bug: 256
Change-Id: Id4df699cefc8630dd5a350d44f927900340f5e60
Reviewed-on: https://boringssl-review.googlesource.com/c/34869
Reviewed-by: Adam Langley <agl@google.com>
But for the ABI conversion bits, these are just leaf functions and don't
even need unwind tables. Just renumber the registers on Windows to only
used volatile ones.
In doing so, this switches to writing rdrand explicitly. perlasm already
knows how to manually encode it and our minimum assembler versions
surely cover rdrand by now anyway. Also add the .size directive. I'm not
sure what it's used for, but the other files have it.
(This isn't a generally reusable technique. The more complex functions
will need actual unwind codes.)
Bug: 259
Change-Id: I1d5669bcf8b6e34939885d78aea6f60597be1528
Reviewed-on: https://boringssl-review.googlesource.com/c/34867
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
EVP_get_cipherbyname should work on everything that EVP_do_all_sorted
lists, and conversely, there should be nothing that
EVP_get_cipherbyname works on that EVP_do_all_sorted doesn't list.
node.js uses these APIs to enumerate and instantiate ciphers.
Change-Id: I87fcedce62d06774f7c6ee7acc898326276be089
Reviewed-on: https://boringssl-review.googlesource.com/c/33984
Reviewed-by: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
This was caught by an aarch64 ABI tester. aarch64 has the same
considerations around small arguments as x86_64 does. The aarch64
version of bn_mul_mont does not mask off the upper words of the
argument.
The x86_64 version does, so size_t is, strictly speaking, wrong for
aarch64, but bn_mul_mont already has an implicit size limit to support
its internal alloca, so this doesn't really make things worse than
before.
Change-Id: I39bffc8fdb2287e45a2d1f0d1b4bd5532bbf3868
Reviewed-on: https://boringssl-review.googlesource.com/c/34804
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Update-Note: There's some chance this'll break iOS since I was unable to
test it there. The iPad I have to test on is too new to run 32-bit code
at all.
Change-Id: I6593f91b67a5e8a82828237d3b69ed948b07922d
Reviewed-on: https://boringssl-review.googlesource.com/c/34725
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Unfortunately, due to most OpenSSL assembly using custom exception
handlers to unwind, most of our assembly doesn't work with
non-destructive unwind. For now, CHECK_ABI behaves like
CHECK_ABI_NO_UNWIND on Windows, and CHECK_ABI_SEH will test unwinding on
both platforms.
The tests do, however, work with the unwind-code-based assembly we
recently added, as well as the clmul-based GHASH which is also
code-based. Remove the ad-hoc SEH tests which intentionally hit memory
access exceptions, now that we can test unwind directly.
Now that we can test it, the next step is to implement SEH directives in
perlasm so writing these unwind codes is less of a chore.
Bug: 259
Change-Id: I23a57a22c5dc9fa4513f575f18192335779678a5
Reviewed-on: https://boringssl-review.googlesource.com/c/34784
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
The .type foo, @abi-omnipotent lines weren't being parsed correctly.
This doesn't change the generated files, but some internal state (used
in-progress work on perlasm SEH directives) wasn't quite right.
Change-Id: Id6aec79281a59f45b2eb2aea9f1fb8806b4c483e
Reviewed-on: https://boringssl-review.googlesource.com/c/34786
Reviewed-by: Adam Langley <agl@google.com>
RAND_bytes rarely uses large enough inputs for bsaes to be worth it.
https://boringssl-review.googlesource.com/c/boringssl/+/33589 includes some
rough benchmarks of various bits here. Some observations:
- 8 blocks of bsaes costs roughly 6.5 blocks of vpaes. Note the comparison
isn't quite accurate because I'm measuring bsaes_ctr32_encrypt_blocks against
vpaes_encrypt and vpaes in CTR mode today must make do with a C loop. Even
assuming a cutoff of 6 rather than 7 blocks, it's rare to ask for 96 bytes
of entropy at a time.
- CTR-DRBG performs some stray block operations (ctr_drbg_update), which bsaes
is bad at without extra work to fold them into the CTR loop (not really worth
it).
- CTR-DRBG calculates a couple new key schedules every RAND_bytes call. We
don't currently have a constant-time bsaes key schedule. Unfortunately, even
plain vpaes loses to the current aes_nohw used by bsaes, but it's not
constant-time. Also taking CTR-DRBG out of the bsaes equation
- Machines without AES hardware (clients) are not going to be RNG-bound. It's
mostly servers pushing way too many CBC IVs that care. This means bsaes's
current side channel tradeoffs make even less sense here.
I'm not sure yet what we should do for the rest of the bsaes mess, but it seems
clear that we want to stick with vpaes for the RNG.
Bug: 256
Change-Id: Iec8f13af232794afd007cb1065913e8117eeee24
Reviewed-on: https://boringssl-review.googlesource.com/c/34744
Reviewed-by: Adam Langley <agl@google.com>
Hexadecimals were erroneously recognized as symbols in .xdata.
(Imported from upstream's b068a9b914887af5cc99895754412582fbb0e10b)
Change-Id: I5d8e8e1969669a8961733802d9f034cf26c45552
Reviewed-on: https://boringssl-review.googlesource.com/c/34704
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Android's official documentation seems to assume you're using the NDK
build system or Android Studio. I extracted this from one of their
scripts a while back. May as well put it somewhere we can easily find
it.
Change-Id: I259abc54e6935ab537956a7cbf9f80e924a60b7a
Reviewed-on: https://boringssl-review.googlesource.com/c/34724
Reviewed-by: Adam Langley <agl@google.com>
For now, this is off by default and controlled by SSL_set_enforce_rsa_key_usage.
This may be set as late as certificate verification so we may start by enforcing
it for known roots.
Generalizes ssl_cert_check_digital_signature_key_usage to check any part of the
key_usage, and adds a new error KEY_USAGE_BIT_INCORRECT for the generalized
method.
Bug: chromium:795089
Change-Id: Ifa504c321bec3263a4e74f2dc48513e3b895d3ee
Reviewed-on: https://boringssl-review.googlesource.com/c/34604
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
They were causing a "panic: ServerHello unexpectedly contained extensions"
if the client unconditionally signals support for OCSP or SCTs.
Change-Id: Ia60639431daf78679b269dfe337c1af171fd7d8b
Reviewed-on: https://boringssl-review.googlesource.com/c/34644
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Calling conventions must specify how to handle arguments smaller than a
machine word. Should the caller pad them up to a machine word size with
predictable values (zero/sign-extended), or should the callee tolerate
an arbitrary bit pattern?
Annoyingly, I found no text in either SysV or Win64 ABI documentation
describing any of this and resorted to experiment. The short answer is
that callees must tolerate an arbitrary bit pattern on x86_64, which
means we must test this. See the comment in abi_test::internal::ToWord
for the long answer.
CHECK_ABI now, if the type of the parameter is smaller than
crypto_word_t, fills the remaining bytes with 0xaa. This is so the
number is out of bounds for code expecting either zero or sign
extension. (Not that crypto assembly has any business seeing negative
numbers.)
Doing so reveals a bug in ecp_nistz256_ord_sqr_mont. The rep parameter
is typed int, but the code expected uint64_t. In practice, the compiler
will always compile this correctly because:
- On both Win64 and SysV, rep is a register parameter.
- The rep parameter is always a constant, so the compiler has no reason
to leave garbage in the upper half.
However, I was indeed able to get a bug out of GCC via:
uint64_t foo = (1ull << 63) | 2; // Some global the compiler can't
// prove constant.
ecp_nistz256_ord_sqr_mont(res, a, foo >> 1);
Were ecp_nistz256_ord_sqr_mont a true int-taking function, this would
act like ecp_nistz256_ord_sqr_mont(res, a, 1). Instead, it hung. Fix
this by having it take a full-width word.
This mess has several consequences:
- ABI testing now ideally needs a functional testing component to fully cover
this case. A bad input might merely produce the wrong answer. Still,
this is fairly effective as it will cause most code to either segfault
or loop forever. (Not the enc parameter to AES however...)
- We cannot freely change the type of assembly function prototypes. If the
prototype says int or unsigned, it must be ignoring the upper half and
thus "fixing" it to size_t cannot have handled the full range. (Unless
it was simply wrong of the parameter is already bounded.) If the
prototype says size_t, switching to int or unsigned will hit this type
of bug. The former is a safer failure mode though.
- The simplest path out of this mess: new assembly code should *only*
ever take word-sized parameters. This is not a tall order as the bad
parameters are usually ints that should have been size_t.
Calling conventions are hard.
Change-Id: If8254aff8953844679fbce4bd3e345e5e2fa5213
Reviewed-on: https://boringssl-review.googlesource.com/c/34627
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
It's an assembly function, so types are a little meaningless, but
everything is passed through as BN_ULONG, so be consistent. Also
annotate all the RSAZ prototypes with sizes.
Change-Id: I32e59e896da39e79c30ce9db52652fd645a033b4
Reviewed-on: https://boringssl-review.googlesource.com/c/34625
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This is much less interesting (stack-based parameters, Windows and SysV
match, no SEH concerns as far as I can tell) than x86_64, but it was
easy to do and I'm more familiar with x86 than ARM, so it made a better
second architecture to make sure all the architecture ifdefs worked out.
Also fix a bug in the x86_64 direction flag code. It was shifting in the
wrong direction, making give 0 or 1<<20 rather than 0 or 1.
(Happily, x86_64 appears to be unique in having vastly different calling
conventions between OSs. x86 is the same between SysV and Windows, and
ARM had the good sense to specify a (mostly) common set of rules.)
Since a lot of the assembly functions use the same names and the tests
were written generically, merely dropping in a trampoline and
CallerState implementation gives us a bunch of ABI tests for free.
Change-Id: I15408c18d43e88cfa1c5c0634a8b268a150ed961
Reviewed-on: https://boringssl-review.googlesource.com/c/34624
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
OpenSSL's EVP-level EC API involves a separate "paramgen" operation,
which is ultimately just a roundabout way to go from a NID to an
EC_GROUP. But Node uses this, and it's the pattern used within OpenSSL
these days, so this appears to be the official upstream recommendation.
Also add a #define for OPENSSL_EC_EXPLICIT_CURVE, because Node uses it,
but fail attempts to use it. Explicit curve encodings are forbidden by
RFC 5480 and generally a bad idea. (Parsing such keys back into OpenSSL
will cause it to lose the optimized path.)
Change-Id: I5e97080e77cf90fc149f6cf6f2cc4900f573fc64
Reviewed-on: https://boringssl-review.googlesource.com/c/34565
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This doesn't cover all the functions used by Node, but it's the easy
bits. (EVP_PKEY_paramgen will be done separately as its a non-trivial
bit of machinery.)
Change-Id: I6501e99f9239ffcdcc57b961ebe85d0ad3965549
Reviewed-on: https://boringssl-review.googlesource.com/c/34544
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
We currently require clmul instructions for constant-time GHASH
on x86_64. Otherwise, it falls back to a variable-time 4-bit table
implementation. However, a significant proportion of clients lack these
instructions.
Inspired by vpaes, we can use pshufb and a slightly different order of
incorporating the bits to make a constant-time GHASH. This requires
SSSE3, which is very common. Benchmarking old machines we had on hand,
it appears to be a no-op on Sandy Bridge and a small slowdown for
Penryn.
Sandy Bridge (Intel Pentium CPU 987 @ 1.50GHz):
(Note: these numbers are before 16-byte-aligning the table. That was an
improvement on Penryn, so it's possible Sandy Bridge is now better.)
Before:
Did 4244750 AES-128-GCM (16 bytes) seal operations in 4015000us (1057222.9 ops/sec): 16.9 MB/s
Did 442000 AES-128-GCM (1350 bytes) seal operations in 4016000us (110059.8 ops/sec): 148.6 MB/s
Did 84000 AES-128-GCM (8192 bytes) seal operations in 4015000us (20921.5 ops/sec): 171.4 MB/s
Did 3349250 AES-256-GCM (16 bytes) seal operations in 4016000us (833976.6 ops/sec): 13.3 MB/s
Did 343500 AES-256-GCM (1350 bytes) seal operations in 4016000us (85532.9 ops/sec): 115.5 MB/s
Did 65250 AES-256-GCM (8192 bytes) seal operations in 4015000us (16251.6 ops/sec): 133.1 MB/s
After:
Did 4229250 AES-128-GCM (16 bytes) seal operations in 4016000us (1053100.1 ops/sec): 16.8 MB/s [-0.4%]
Did 442250 AES-128-GCM (1350 bytes) seal operations in 4016000us (110122.0 ops/sec): 148.7 MB/s [+0.1%]
Did 83500 AES-128-GCM (8192 bytes) seal operations in 4015000us (20797.0 ops/sec): 170.4 MB/s [-0.6%]
Did 3286500 AES-256-GCM (16 bytes) seal operations in 4016000us (818351.6 ops/sec): 13.1 MB/s [-1.9%]
Did 342750 AES-256-GCM (1350 bytes) seal operations in 4015000us (85367.4 ops/sec): 115.2 MB/s [-0.2%]
Did 65250 AES-256-GCM (8192 bytes) seal operations in 4016000us (16247.5 ops/sec): 133.1 MB/s [-0.0%]
Penryn (Intel Core 2 Duo CPU P8600 @ 2.40GHz):
Before:
Did 1179000 AES-128-GCM (16 bytes) seal operations in 1000139us (1178836.1 ops/sec): 18.9 MB/s
Did 97000 AES-128-GCM (1350 bytes) seal operations in 1006347us (96388.2 ops/sec): 130.1 MB/s
Did 18000 AES-128-GCM (8192 bytes) seal operations in 1028943us (17493.7 ops/sec): 143.3 MB/s
Did 977000 AES-256-GCM (16 bytes) seal operations in 1000197us (976807.6 ops/sec): 15.6 MB/s
Did 82000 AES-256-GCM (1350 bytes) seal operations in 1012434us (80992.9 ops/sec): 109.3 MB/s
Did 15000 AES-256-GCM (8192 bytes) seal operations in 1006528us (14902.7 ops/sec): 122.1 MB/s
After:
Did 1306000 AES-128-GCM (16 bytes) seal operations in 1000153us (1305800.2 ops/sec): 20.9 MB/s [+10.8%]
Did 94000 AES-128-GCM (1350 bytes) seal operations in 1009852us (93082.9 ops/sec): 125.7 MB/s [-3.4%]
Did 17000 AES-128-GCM (8192 bytes) seal operations in 1012096us (16796.8 ops/sec): 137.6 MB/s [-4.0%]
Did 1070000 AES-256-GCM (16 bytes) seal operations in 1000929us (1069006.9 ops/sec): 17.1 MB/s [+9.4%]
Did 79000 AES-256-GCM (1350 bytes) seal operations in 1002209us (78825.9 ops/sec): 106.4 MB/s [-2.7%]
Did 15000 AES-256-GCM (8192 bytes) seal operations in 1061489us (14131.1 ops/sec): 115.8 MB/s [-5.2%]
Change-Id: I1c3760a77af7bee4aee3745d1c648d9e34594afb
Reviewed-on: https://boringssl-review.googlesource.com/c/34267
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
These tests failed when CECPQ2 was enabled by default. Even if we're
not going to make CECPQ2 the default, it's worth fixing them to be more
robust.
Change-Id: Idef508bca9e17a4ef0e0a8a396755abd975f9908
Reviewed-on: https://boringssl-review.googlesource.com/c/34524
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
If 256-bit ciphers are a requirement for CECPQ2 then that introduces a
link between supported ciphers and supported groups: offering CECPQ2
without a 256-bit cipher is invalid. But that's a little weird since
these things were otherwise independent.
So, rather than require a 256-bit cipher for CECPQ2, just prefer them.
Change-Id: I491749e41708cd9c5eeed5b4ae23c11e5c0b9725
Reviewed-on: https://boringssl-review.googlesource.com/c/34504
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
11.0.2 has since been released, but we are now aware of several more
bugs, so the workaround is unlikely to be removable for the foreseeable
future.
Change-Id: I8e7edcba2f002d0558a21e607306ddf9a205bfb3
Reviewed-on: https://boringssl-review.googlesource.com/c/34484
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
On our bots, debug unit tests take around 2.5x as long to complete as
release tests on Linux, 3x as long on macOS, and 6x as long on Windows.
Our tests are fast, so this does not particularly matter, but SDE
inflates a 13 second test run to 8 minutes. On Windows (MSVC), where we
don't but would like to test with SDE, the difference between optimized
and unoptimized is even larger, and test runs are slower in general.
This suggests running SDE tests in release mode. Release mode tests,
however, are less effective because they do not include asserts. Thus,
add a RelWithAsserts option.
(Chromium does something similar. I believe most of the test-running
configurations on the critical path run is_debug = false and
dcheck_always_on = true.)
Change-Id: I273dd86ab8ea039f34eca431483827c87dc5c461
Reviewed-on: https://boringssl-review.googlesource.com/c/34464
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
qsort shares the same C language bug as mem*. Two of our calls may see
zero-length lists. This trips UBSan.
Change-Id: Id292dd277129881001eb57b1b2db78438cf4642e
Reviewed-on: https://boringssl-review.googlesource.com/c/34447
Reviewed-by: Adam Langley <agl@google.com>
Due to a language flaw in C, left-shifts on signed integers are
undefined for negative numbers. This makes them all but useless. Cast to
the unsigned type, left-shift, and cast back (casts are defined to wrap)
to silence UBSan.
Change-Id: I8fbe739aee1c99cf553462b675863e6d68c2b302
Reviewed-on: https://boringssl-review.googlesource.com/c/34446
Reviewed-by: Adam Langley <agl@google.com>
Casting an unaligned pointer to uint64_t* is undefined, even on
platforms that support unaligned access. Additionally, dereferencing as
uint64_t violates strict aliasing rules. Instead, use memcpys which we
assume any sensible compiler can optimize. Also simplify the PULL64
business with the existing CRYPTO_bswap8.
This also removes the need for the
SHA512_BLOCK_CAN_MANAGE_UNALIGNED_DATA logic. The generic C code now
handles unaligned data and the assembly already can as well. (The only
problematic platform with assembly is old ARM, but sha512-armv4.pl
already handles this via an __ARM_ARCH__ check. See also OpenSSL's
version of this file which always defines
SHA512_BLOCK_CAN_MANAGE_UNALIGNED_DATA if SHA512_ASM is defined.)
Add unaligned tests to digest_test.cc, so we retain coverage of
unaligned EVP_MD inputs.
Change-Id: Idfd8586c64bab2a77292af2fa8eebbd193e57c7d
Reviewed-on: https://boringssl-review.googlesource.com/c/34444
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
With HRSS-SXY, the sampling algorithm now longer has to be the same
between the two parties. Therefore we can change it at will (as long as
it remains reasonably uniform) and thus take the opportunity to make the
output distribution flatter.
Change-Id: I74c667fcf919fe11ddcf2f4fb8a540b5112268bf
Reviewed-on: https://boringssl-review.googlesource.com/c/34404
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
The first attempt involved using Linux's support for hardware
breakpoints to detect when assembly code was run. However, this doesn't
work with SDE, which is a problem.
This version has the assembly code update a global flags variable when
it's run, but only in non-FIPS and non-debug builds.
Update-Note: Assembly files now pay attention to the NDEBUG preprocessor
symbol. Ensure the build passes the symbol in. (If release builds fail
to link due to missing BORINGSSL_function_hit, this is the cause.)
Change-Id: I6b7ced442b7a77d0b4ae148b00c351f68af89a6e
Reviewed-on: https://boringssl-review.googlesource.com/c/33384
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
The multiplication and subtraction circuits were found by djb using GNU
Superoptimizer, and the addition circuit is derived from the subtraction
one by hand. They depend on a different representation: -1 is now (1, 1)
rather than (1, 0), and the latter becomes undefined.
The following Python program checks that the circuits work:
values = [0, 1, -1]
def toBits(v):
if v == 0:
return 0, 0
elif v == 1:
return 0, 1
elif v == -1:
return 1, 1
else:
raise ValueError(v)
def mul((s1, a1), (s2, a2)):
return ((s1 ^ s2) & a1 & a2, a1 & a2)
def add((s1, a1), (s2, a2)):
t = s1 ^ a2
return (t & (s2 ^ a1), (a1 ^ a2) | (t ^ s2))
def sub((s1, a1), (s2, a2)):
t = a1 ^ a2
return ((s1 ^ a2) & (t ^ s2), t | (s1 ^ s2))
def fromBits((s, a)):
if s == 0 and a == 0:
return 0
if s == 0 and a == 1:
return 1
if s == 1 and a == 1:
return -1
else:
raise ValueError((s, a))
def wrap(v):
if v == 2:
return -1
elif v == -2:
return 1
else:
return v
for v1 in values:
for v2 in values:
print v1, v2
result = fromBits(mul(toBits(v1), toBits(v2)))
if result != v1 * v2:
raise ValueError((v1, v2, result))
result = fromBits(add(toBits(v1), toBits(v2)))
if result != wrap(v1 + v2):
raise ValueError((v1, v2, result))
result = fromBits(sub(toBits(v1), toBits(v2)))
if result != wrap(v1 - v2):
raise ValueError((v1, v2, result))
Change-Id: Ie1a4ca5a82c2651057efc62330eca6fdd9878122
Reviewed-on: https://boringssl-review.googlesource.com/c/34344
Reviewed-by: David Benjamin <davidben@google.com>
Since |ssl_renegotiate_never| is the default, this option is moot.
However, OpenSSL defines and supports it so this helps code that wishes
to support both.
Change-Id: I3a2f6e93a078d39526d10f9cd0a990953bd45825
Reviewed-on: https://boringssl-review.googlesource.com/c/34384
Reviewed-by: Adam Langley <alangley@gmail.com>
Commit-Queue: Adam Langley <alangley@gmail.com>
This new version makes it much easier to tell which code is handwritten
and which is verified. For some reason, it also is *dramatically* faster
for 32-bit x86 GCC. Clang x86_64, however, does take a small hit.
Benchmarks below.
x86, GCC 7.3.0, OPENSSL_SMALL
(For some reason, GCC used to be really bad at compiling the 32-bit curve25519
code. The new one fixes this. I'm not sure what changed.)
Before:
Did 17135 Ed25519 key generation operations in 10026402us (1709.0 ops/sec)
Did 17170 Ed25519 signing operations in 10074192us (1704.4 ops/sec)
Did 9180 Ed25519 verify operations in 10034025us (914.9 ops/sec)
Did 17271 Curve25519 base-point multiplication operations in 10050837us (1718.4 ops/sec)
Did 10605 Curve25519 arbitrary point multiplication operations in 10047714us (1055.5 ops/sec)
Did 7800 ECDH P-256 operations in 10018331us (778.6 ops/sec)
Did 24308 ECDSA P-256 signing operations in 10019241us (2426.1 ops/sec)
Did 9191 ECDSA P-256 verify operations in 10081639us (911.7 ops/sec)
After:
Did 99873 Ed25519 key generation operations in 10021810us (9965.6 ops/sec) [+483.1%]
Did 99960 Ed25519 signing operations in 10052236us (9944.1 ops/sec) [+483.4%]
Did 53676 Ed25519 verify operations in 10009078us (5362.7 ops/sec) [+486.2%]
Did 102000 Curve25519 base-point multiplication operations in 10039764us (10159.6 ops/sec) [+491.2%]
Did 60802 Curve25519 arbitrary point multiplication operations in 10056897us (6045.8 ops/sec) [+472.8%]
Did 7900 ECDH P-256 operations in 10054509us (785.7 ops/sec) [+0.9%]
Did 24926 ECDSA P-256 signing operations in 10050919us (2480.0 ops/sec) [+2.2%]
Did 9494 ECDSA P-256 verify operations in 10064659us (943.3 ops/sec) [+3.5%]
x86, Clang 8.0.0 trunk 349417, OPENSSL_SMALL
Before:
Did 82750 Ed25519 key generation operations in 10051177us (8232.9 ops/sec)
Did 82400 Ed25519 signing operations in 10035806us (8210.6 ops/sec)
Did 41511 Ed25519 verify operations in 10048919us (4130.9 ops/sec)
Did 83300 Curve25519 base-point multiplication operations in 10044283us (8293.3 ops/sec)
Did 49700 Curve25519 arbitrary point multiplication operations in 10007005us (4966.5 ops/sec)
Did 14039 ECDH P-256 operations in 10093929us (1390.8 ops/sec)
Did 40950 ECDSA P-256 signing operations in 10006757us (4092.2 ops/sec)
Did 16068 ECDSA P-256 verify operations in 10095996us (1591.5 ops/sec)
After:
Did 80476 Ed25519 key generation operations in 10048648us (8008.6 ops/sec) [-2.7%]
Did 79050 Ed25519 signing operations in 10049180us (7866.3 ops/sec) [-4.2%]
Did 40501 Ed25519 verify operations in 10048347us (4030.6 ops/sec) [-2.4%]
Did 81300 Curve25519 base-point multiplication operations in 10017480us (8115.8 ops/sec) [-2.1%]
Did 48278 Curve25519 arbitrary point multiplication operations in 10092500us (4783.6 ops/sec) [-3.7%]
Did 15402 ECDH P-256 operations in 10096705us (1525.4 ops/sec) [+9.7%]
Did 44200 ECDSA P-256 signing operations in 10037715us (4403.4 ops/sec) [+7.6%]
Did 17000 ECDSA P-256 verify operations in 10008813us (1698.5 ops/sec) [+6.7%]
x86_64, GCC 7.3.0
(Note these P-256 numbers are not affected by this change. Included to get a
sense of noise.)
Before:
Did 557000 Ed25519 key generation operations in 10011721us (55634.8 ops/sec)
Did 550000 Ed25519 signing operations in 10016449us (54909.7 ops/sec)
Did 190000 Ed25519 verify operations in 10014565us (18972.4 ops/sec)
Did 587000 Curve25519 base-point multiplication operations in 10015402us (58609.7 ops/sec)
Did 230000 Curve25519 arbitrary point multiplication operations in 10023827us (22945.3 ops/sec)
Did 179000 ECDH P-256 operations in 10016294us (17870.9 ops/sec)
Did 557000 ECDSA P-256 signing operations in 10014158us (55621.3 ops/sec)
Did 198000 ECDSA P-256 verify operations in 10036694us (19727.6 ops/sec)
After:
Did 569000 Ed25519 key generation operations in 10004965us (56871.8 ops/sec) [+2.2%]
Did 563000 Ed25519 signing operations in 10000064us (56299.6 ops/sec) [+2.5%]
Did 196000 Ed25519 verify operations in 10025650us (19549.9 ops/sec) [+3.0%]
Did 596000 Curve25519 base-point multiplication operations in 10008666us (59548.4 ops/sec) [+1.6%]
Did 229000 Curve25519 arbitrary point multiplication operations in 10028921us (22834.0 ops/sec) [-0.5%]
Did 182910 ECDH P-256 operations in 10014905us (18263.8 ops/sec) [+2.2%]
Did 562000 ECDSA P-256 signing operations in 10011944us (56133.0 ops/sec) [+0.9%]
Did 202000 ECDSA P-256 verify operations in 10046901us (20105.7 ops/sec) [+1.9%]
x86_64, GCC 7.3.0, OPENSSL_SMALL
Before:
Did 350000 Ed25519 key generation operations in 10002540us (34991.1 ops/sec)
Did 344000 Ed25519 signing operations in 10010420us (34364.2 ops/sec)
Did 197000 Ed25519 verify operations in 10030593us (19639.9 ops/sec)
Did 362000 Curve25519 base-point multiplication operations in 10004615us (36183.3 ops/sec)
Did 235000 Curve25519 arbitrary point multiplication operations in 10025951us (23439.2 ops/sec)
Did 32032 ECDH P-256 operations in 10056486us (3185.2 ops/sec)
Did 96354 ECDSA P-256 signing operations in 10007297us (9628.4 ops/sec)
Did 37774 ECDSA P-256 verify operations in 10044892us (3760.5 ops/sec)
After:
Did 343000 Ed25519 key generation operations in 10025108us (34214.1 ops/sec) [-2.2%]
Did 340000 Ed25519 signing operations in 10014870us (33949.5 ops/sec) [-1.2%]
Did 192000 Ed25519 verify operations in 10025082us (19152.0 ops/sec) [-2.5%]
Did 355000 Curve25519 base-point multiplication operations in 10013220us (35453.1 ops/sec) [-2.0%]
Did 231000 Curve25519 arbitrary point multiplication operations in 10010775us (23075.1 ops/sec) [-1.6%]
Did 31540 ECDH P-256 operations in 10009664us (3151.0 ops/sec) [-1.1%]
Did 99012 ECDSA P-256 signing operations in 10090296us (9812.6 ops/sec) [+1.9%]
Did 37695 ECDSA P-256 verify operations in 10092859us (3734.8 ops/sec) [-0.7%]
x86_64, Clang 8.0.0 trunk 349417
(Note these P-256 numbers are not affected by this change. Included to get a
sense of noise.)
Before:
Did 600000 Ed25519 key generation operations in 10000278us (59998.3 ops/sec)
Did 595000 Ed25519 signing operations in 10010375us (59438.3 ops/sec)
Did 184000 Ed25519 verify operations in 10013984us (18374.3 ops/sec)
Did 636000 Curve25519 base-point multiplication operations in 10005250us (63566.6 ops/sec)
Did 229000 Curve25519 arbitrary point multiplication operations in 10006059us (22886.1 ops/sec)
Did 179250 ECDH P-256 operations in 10026354us (17877.9 ops/sec)
Did 547000 ECDSA P-256 signing operations in 10017585us (54604.0 ops/sec)
Did 197000 ECDSA P-256 verify operations in 10013020us (19674.4 ops/sec)
After:
Did 560000 Ed25519 key generation operations in 10009295us (55948.0 ops/sec) [-6.8%]
Did 548000 Ed25519 signing operations in 10007912us (54756.7 ops/sec) [-7.9%]
Did 170000 Ed25519 verify operations in 10056948us (16903.7 ops/sec) [-8.0%]
Did 592000 Curve25519 base-point multiplication operations in 10016818us (59100.6 ops/sec) [-7.0%]
Did 214000 Curve25519 arbitrary point multiplication operations in 10043918us (21306.4 ops/sec) [-6.9%]
Did 180000 ECDH P-256 operations in 10026019us (17953.3 ops/sec) [+0.4%]
Did 550000 ECDSA P-256 signing operations in 10004943us (54972.8 ops/sec) [+0.7%]
Did 198000 ECDSA P-256 verify operations in 10021714us (19757.1 ops/sec) [+0.4%]
x86_64, Clang 8.0.0 trunk 349417, OPENSSL_SMALL
Before:
Did 326000 Ed25519 key generation operations in 10003266us (32589.4 ops/sec)
Did 322000 Ed25519 signing operations in 10026783us (32114.0 ops/sec)
Did 181000 Ed25519 verify operations in 10015635us (18071.7 ops/sec)
Did 335000 Curve25519 base-point multiplication operations in 10000359us (33498.8 ops/sec)
Did 224000 Curve25519 arbitrary point multiplication operations in 10027245us (22339.1 ops/sec)
Did 68552 ECDH P-256 operations in 10018900us (6842.3 ops/sec)
Did 184000 ECDSA P-256 signing operations in 10014516us (18373.3 ops/sec)
Did 76020 ECDSA P-256 verify operations in 10016891us (7589.2 ops/sec)
After:
Did 310000 Ed25519 key generation operations in 10022086us (30931.7 ops/sec) [-5.1%]
Did 308000 Ed25519 signing operations in 10007543us (30776.8 ops/sec) [-4.2%]
Did 173000 Ed25519 verify operations in 10005829us (17289.9 ops/sec) [-4.3%]
Did 321000 Curve25519 base-point multiplication operations in 10027058us (32013.4 ops/sec) [-4.4%]
Did 212000 Curve25519 arbitrary point multiplication operations in 10015203us (21167.8 ops/sec) [-5.2%]
Did 64059 ECDH P-256 operations in 10042781us (6378.6 ops/sec) [-6.8%]
Did 170000 ECDSA P-256 signing operations in 10030896us (16947.6 ops/sec) [-7.8%]
Did 72176 ECDSA P-256 verify operations in 10075369us (7163.6 ops/sec) [-5.6%]
Bug: 254
Change-Id: Ib04c773f01b542bcb8611cceb582466bfa6f6d52
Reviewed-on: https://boringssl-review.googlesource.com/c/34306
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
pkg-config gets confused and doesn't know to look in, say,
/usr/lib/i386-linux-gnu when building for 32-bit. Fortunately, CMake
sets a CMAKE_CROSSCOMPILING variable whenever CMAKE_SYSTEM_NAME is set
manually (as done in util/32-bit-toolchain.cmake).
Change-Id: I638b4d54ea92ade4b2b5baa40a3c5e8c17914d46
Reviewed-on: https://boringssl-review.googlesource.com/c/34305
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
We expect the table to have a slightly nested structure, so just
generate it that way. Avoid risking strict aliasing problems. Thanks to
Brian Smith for pointing this out.
Change-Id: Ie21610c4afab07a610d914265079135dba17b3b7
Reviewed-on: https://boringssl-review.googlesource.com/c/34264
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This allows sharing SSL_CTX between TCP and QUIC connections, such that
common settings can be configured without having to duplicate the
context.
Change-Id: Ie920e7f2a772dd6c6c7b63fdac243914ac5b7b26
Reviewed-on: https://boringssl-review.googlesource.com/c/33904
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
The last instruction did not unwind correctly. Also add .type and .size
annotations so that errors show up properly.
Change-Id: Id18e12b4ed51bdabb90bd5ac66631fd989649eec
Reviewed-on: https://boringssl-review.googlesource.com/c/34190
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
This involves fixing some bugs in aes_nohw_cbc_encrypt's annotations,
and working around a libunwind bug. In doing so, support .cfi_remember_state
and .cfi_restore_state in perlasm.
Change-Id: Iaedfe691356b0468327a6be0958d034dafa760e5
Reviewed-on: https://boringssl-review.googlesource.com/c/34189
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
This is in preparation for adding ABI tests to them.
In doing so, update delocate.go so that OPENSSL_ia32cap_get is consistently
callable outside the module. Right now it's callable both inside and outside
normally, but not in FIPS mode because the function is generated. This is
needed for tests and the module to share headers that touch OPENSSL_ia32cap_P.
Change-Id: Idbc7d694acfb974e0b04adac907dab621e87de62
Reviewed-on: https://boringssl-review.googlesource.com/c/34188
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Linux and Windows ABIs both require that the direction flag be cleared
on function exit, so that functions can rely on it being cleared on
entry. (Some OpenSSL assembly preserves it, which is stronger, but we
only require what is specified by the ABI so CHECK_ABI works with C
compiler output.)
Change-Id: I1a320aed4371176b4b44fe672f1a90167b84160f
Reviewed-on: https://boringssl-review.googlesource.com/c/34187
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This does not actually matter, but writing new CFI directives with the
tester seemed like fun. (It caught two typos, one intentional and one
accidental.)
Change-Id: Iff3e0358f2e56caa26079f658fa7a682772150a1
Reviewed-on: https://boringssl-review.googlesource.com/c/34185
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This uses the x86 trap flag and libunwind to test CFI works at each
instruction. For now, it just uses the system one out of pkg-config and
disables unwind tests if unavailable. We'll probably want to stick a
copy into //third_party and perhaps try the LLVM one later.
This tester caught two bugs in P-256 CFI annotations already:
I47b5f9798b3bcee1748e537b21c173d312a14b42 and
I9f576d868850312d6c14d1386f8fbfa85021b347
An earlier design used PTRACE_SINGLESTEP with libunwind's remote
unwinding features. ptrace is a mess around stop signals (see group-stop
discussion in ptrace(2)) and this is 10x faster, so I went with it. The
question of which is more future-proof is complex:
- There are two libunwinds with the same API,
https://www.nongnu.org/libunwind/ and LLVM's. This currently uses the
system nongnu.org for convenience. In future, LLVM's should be easier
to bundle (less complex build) and appears to even support Windows,
but I haven't tested this. Moreover, setting the trap flag keeps the
test single-process, which is less complex on Windows. That suggests
the trap flag design and switching to LLVM later. However...
- Not all architectures have a trap flag settable by userspace. As far
as I can tell, ARMv8's PSTATE.SS can only be set from the kernel. If
we stick with nongnu.org libunwind, we can use PTRACE_SINGLESTEP and
remote unwinding. Or we implement it for LLVM. Another thought is for
the ptracer to bounce SIGTRAP back into the process, to share the
local unwinding code.
- ARMv7 has no trap flag at all and PTRACE_SINGLESTEP fails. Debuggers
single-step by injecting breakpoints instead. However, ARMv8's trap
flag seems to work in both AArch32 and AArch64 modes, so we may be
able to condition it on a 64-bit kernel.
Sadly, neither strategy works with Intel SDE. Adding flags to cpucap
vectors as we do with ARM would help, but it would not emulate CPUs
newer than the host CPU. For now, I've just had SDE tests disable these.
Annoyingly, CMake does not allow object libraries to have dependencies,
so make test_support a proper static library. Rename the target to
test_support_lib to avoid
https://gitlab.kitware.com/cmake/cmake/issues/17785
Update-Note: This adds a new optional test dependency, but it's disabled
by default (define BORINGSSL_HAVE_LIBUNWIND), so consumers do not need
to do anything. We'll probably want to adjust this in the future.
Bug: 181
Change-Id: I817263d7907aff0904a9cee83f8b26747262cc0c
Reviewed-on: https://boringssl-review.googlesource.com/c/33966
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Maybe someday we'll be able to turn on that warning. (The EVP_CIPHER
hooks take size_t while the functions took long.)
Change-Id: Ic4da44efca9419a7f703e232d3f92638eb4ab37a
Reviewed-on: https://boringssl-review.googlesource.com/c/34084
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Postgres contains a “pqcrypto” module that showcases the worst of 90's
crypto, including Blowfish and CAST5 in CFB, CBC, and ECB modes. (Also,
64-bit keys for both of those.)
In order to minimise the patching needed to build Postgres, put these
things in decrepit.
Change-Id: I8390c5153dd7227eef07293a4363878d79df8b21
Reviewed-on: https://boringssl-review.googlesource.com/c/34044
Reviewed-by: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Unwind testing will make CHECK_ABI much slower. The original
ptrace-based design is some 10,000x slower. I've found an alternate
design that's a mere 1,000x slower, but this probably warrants being
more straightforward. It also removes the weirdness where NDEBUG
controlled which tests were run.
While it does mean we need to write some extra tests for p256-x86_64.pl,
we otherwise do not directly unit test our assembly anyway. Usually we
test the public crypto APIs themselves. So, for most files, this isn't
actually extra work.
Bug: 181
Change-Id: I7cbb7f930c2ea6ae32a201da503dcd36844704f0
Reviewed-on: https://boringssl-review.googlesource.com/c/33965
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Windows is sufficiently different from Linux that running tests under
SDE for Windows, particularly with the new ABI tests, is worthwhile.
Change-Id: I32c4f6de06b2e732ebb2c1492eb1766cae73c0e0
Reviewed-on: https://boringssl-review.googlesource.com/c/34064
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Prior to 82639e6f we used thread-local data for the PRNG state. That
change switched to using a mutex-protected pool instead in order to save
memory in heavily-threaded applications.
However, the pool mutex can get extremely hot in cases where the PRNG is
heavily used. 8e8f2504 was a short-term work around, but supporting both
modes is overly complex.
This change moves back to the state of the prior to 82639e6f. The best
way to review this is to diff the changed files against '82639e6f^' and
note that the only difference is a comment added in rand.c:
https://paste.googleplex.com/4997991748337664
Change-Id: I8febce089696fa6bc39f94f4a1e268127a8f78db
Reviewed-on: https://boringssl-review.googlesource.com/c/34024
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
I don't believe we use this anymore. People using it should upgrade to a newer
NDK (or, worst case, download android-cmake themselves).
Change-Id: Ia99d7b19d6f2ec3f4ffe90795813b00480dc2d60
Reviewed-on: https://boringssl-review.googlesource.com/c/34004
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
The minimum versions are largely bogus, since we do not continuously test them.
Instead, we've been using Abseil's five year guidelines to decide when to rely
on tooling improvements. Document this.
Remove the note on how to build Ninja as that'll just get out of date. For
instance, they appear to support Python 3 when building now.
Explicitly call out that CMake 3.0 will be required next year (released June
2014). 3.0 is the minimum needed to distinguish Clang from AppleClang, without
which version checks on Clang don't work.
Also document that we require a C++11 compiler for more than just tests these
days.
Change-Id: I4e5766934edc1d69f7be01f48e855d400adfb5f2
Reviewed-on: https://boringssl-review.googlesource.com/c/33845
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
While gdb can figure it out, libunwind requires CFI directives to
unwind a leaf function, even though the directives are trivial.
Adding them matches what GCC outputs, and likely gdb has many
heuristics that less complex tools (e.g. profilers) may not.
Bug: 181
Change-Id: I25c72152de33109a29710a828aeb99c608dd0470
Reviewed-on: https://boringssl-review.googlesource.com/c/33964
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This was also caught by the in-progress unwind tester. There are two
issues here. First, .cfi_endproc must come after ret to fully cover the
function. More importantly, this function is confused about whether it
has a frame pointer or not.
It looks like it does (movq %rsp, %rbp), and annotates accordingly, but
it does not actually use the frame pointer. It cannot. $y4 is rbp and
gets clobbered immediately after the preamble!
Remove this instruction and align the CFI annotations with a
frame-pointer-less function.
Bug: 181
Change-Id: I47b5f9798b3bcee1748e537b21c173d312a14b42
Reviewed-on: https://boringssl-review.googlesource.com/c/33947
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This was caught by in-progress work to test unwind information. It was
incorrect at two instructions: immediately before we jump to
.Lpoint_double_shortcut$x. This is needed because
ecp_nistz256_point_add$x tries to be clever about not unwinding the
stack frame in its tail call.
It's also unlikely that the SEH handlers in this file are correct at
this point, but that will be handled separately while overhauling
everything else here. (For Win64, probably the only ABI-compliant option
is to just properly unwind the stack frame. Without a custom handler,
Win64 unwind codes are very restrictive.)
Bug: 181
Change-Id: I9f576d868850312d6c14d1386f8fbfa85021b347
Reviewed-on: https://boringssl-review.googlesource.com/c/33946
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
ecp_nistz256_point_add_affine does not support the doubling case and,
unlike ecp_nistz256_point_add which does a tail call, computes the wrong
answer. Note TestPointAdd in the unit tests skips this case.
This works fine because we only use ecp_nistz256_point_add_affine for
the g_scalar term, which is fully computed before the p_scalar term.
(Additionally it requires that the windowing pattern never hit the
doubling case for single multiplication.)
But this is not obvious from reading the multiplication functions, so
leave a comment at the call site to point this out.
Change-Id: I08882466d98030cdc882a5be9e702ee404e80cce
Reviewed-on: https://boringssl-review.googlesource.com/c/33945
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
The old points weren't even on the curve. I probably had no clue what I
was doing at the time when I generated them. Refresh them with a
checked-in generate script.
Change-Id: Ib4613fe922edcf45fc4ea49fc4c2cc23a9a2a9bd
Reviewed-on: https://boringssl-review.googlesource.com/c/33944
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
We switched from thread-local storage to a mutex-pool in 82639e6f53
because, for highly-threaded processes, the memory used by all the
states could be quite large. I had judged that a mutex-pool should be
fine, but had underestimated the PRNG requirements of some of our jobs.
This change makes rand.c support using either thread-locals or a
mutex-pool. Thread-locals are used if fork-unsafe buffering is enabled.
While not strictly related to fork-safety, we already have the
fork-unsafe control, and it's already set by jobs that care a lot about
PRNG performance, so fits quite nicely here.
Change-Id: Iaf1e0171c70d4c8dbe1e42283ea13df5b613cb2d
Reviewed-on: https://boringssl-review.googlesource.com/c/31564
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
This is all manual right now. Once we've added SEH tests, we can add support
for emitting these in x86_64-xlate.pl, probably based on MASM and Yasm's unwind
directives, and unify with CFI. (Sadly, NASM does not support these
directives.) Then we can push that upstream to replace the error-prone and
non-standard custom handlers.
Change-Id: I5a734fd494b7eaafab24a00e6df624bd03b37d43
Reviewed-on: https://boringssl-review.googlesource.com/c/33785
Reviewed-by: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <alangley@gmail.com>
Commit-Queue: David Benjamin <davidben@google.com>
Dear reader, I must apologize in advance. This CL contains the following:
- A new 256-line perlasm file with non-trivial perl bits and a dual-ABI
variadic function caller.
- C preprocessor gymnastics, with variadic macros and fun facts about
__VA_ARGS__'s behavior on empty argument lists.
- C++ template gymnastics, including variadic arguments, template
specialization, std::enable_if, and machinery to control template argument
deduction.
Enjoy.
This tests that our assembly functions correctly honor platform ABI
conventions. Right now this only tests callee-saved registers, but it should be
extendable to SEH/CFI unwind testing with single-step debugging APIs.
Register-checking does not involve anything funny and should be compatible with
SDE. (The future unwind testing is unlikely to be compatible.)
This CL adds support for x86_64 SysV and Win64 ABIs. ARM, AArch64, and x86 can
be added in the future. The testing is injected in two places. First, all the
assembly tests in p256-x86_64-test.cc are now instrumented. This is the
intended workflow and should capture all registers.
However, we currently do not unit-test our assembly much directly. We should do
that as follow-up work[0] but, in the meantime, I've also wrapped all of the GTest
main function in an ABI test. This is imperfect as ABI failures may be masked
by other stack frames, but it costs nothing[1] and is pretty reliable at
catching Win64 xmm register failures.
[0] An alternate strategy would be, in debug builds, unconditionally instrument
every assembly call in libcrypto. But the CHECK_ABI macro would be difficult to
replicate in pure C, and unwind testing may be too invasive for this. Still,
something to consider when we C++ libcrypto.
[1] When single-stepped unwind testing exists, it won't cost nothing. The
gtest_main.cc call will turn unwind testing off.
Change-Id: I6643b26445891fd46abfacac52bc024024c8d7f6
Reviewed-on: https://boringssl-review.googlesource.com/c/33764
Reviewed-by: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <alangley@gmail.com>
Commit-Queue: David Benjamin <davidben@google.com>
Valgrind's checking of uninitialised memory behaves very much like a
check for constant-time code: branches and memory indexes based on
uninitialised memory trigger warnings. Therefore, if we can tell
Valgrind that some secret is “uninitialised”, it'll give us a warning if
we do something non-constant-time with it.
This was the idea behind https://github.com/agl/ctgrind. But tricks like
that are no longer needed because Valgrind now comes with support for
marking regions of memory as defined or not. Therefore we can use that
API to check constant-time code.
This CL defines |CONSTTIME_SECRET| and |CONSTTIME_DECLASSIFY|, which are
no-ops unless the code is built with
|BORINGSSL_CONSTANT_TIME_VALIDATION| defined, which it isn't by default.
So this CL is a no-op itself so far. But it does show that a couple of
bits of constant-time time are, in fact, constant-time—seemingly even
when compiled with optimisations, which is nice.
The annotations in the RSA code are a) probably not marking all the
secrets as secret, and b) triggers warnings that are a little
interesting:
The anti-glitch check calls |BN_mod_exp_mont| which checks that the
input is less than the modulus. Of course, it is because the input is
the RSA plaintext that we just decrypted, but the plaintext is supposed
to be secret and so branching based on its contents isn't allows by
Valgrind. The answer isn't totally clear, but I've run out of time on
this for now.
Change-Id: I1608ed0b22d201e97595fafe46127159e02d5b1b
Reviewed-on: https://boringssl-review.googlesource.com/c/33504
Reviewed-by: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
At some point after GCC 7.3, but before 8.2, GCC enabled the SSE ABI by
default. However, if it isn't enabled, the vector intrinsics in HRSS
cannot be used. (See https://github.com/grpc/grpc/issues/17540.)
Note that the intrinsics used are SSE2, but that should be ok because
they are guarded by a run-time check. The compile-time check for __SSE__
just ensures that GCC will build the code at all. (SDE does not simulate
anything that doesn't have SSE2, however.)
Change-Id: If092a06a441ed9d38576ea30351b3b40693a3399
Reviewed-on: https://boringssl-review.googlesource.com/c/33744
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
It's excessively complex to worry about leaving these few bits for
extensions. If we need to change things, we can spin a new curve ID in
TLS. We don't need to support two versions during the transition because
a fallback to X25519 is still fine.
Change-Id: I0a4019d5693db0f0f3a5379909d99c2e2c762560
Reviewed-on: https://boringssl-review.googlesource.com/c/33704
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
I'm working on a test harness to check our assembly correctly restores
callee-saved registers. It caught this.
While perlasm tries to smooth over the differences between Windows and SysV
ABIs, it does not capture the difference in xmm registers. All xmm registers
are volatile in SysV, while Windows makes xmm6 through xmm15 callee-saved.
Change-Id: Ia549b0f126885768f7fb330271a590174c483a3d
Reviewed-on: https://boringssl-review.googlesource.com/c/33685
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Seeing the following errors with GCC 6 on ARM:
crypto/hrss/hrss.c:212:12: error: function declaration isn't a prototype [-Werror=strict-prototypes]
static int vec_capable() { return CRYPTO_is_NEON_capable(); }
^~~~~~~~~~~
crypto/hrss/hrss.c: In function 'vec_capable':
crypto/hrss/hrss.c:212:12: error: old-style function definition [-Werror=old-style-definition]
Change-Id: Ice540e6d436b8ada1dbc494f1feca10efff11687
Reviewed-on: https://boringssl-review.googlesource.com/c/33624
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
https://boringssl-review.googlesource.com/12704 pushed it just too far
to the edge. Once we have an established SSL_SESSION, any modifications
need to either be locked or done ahead of time. Do it ahead of time.
session->is_server gives a suitable place to check and X509s are
ref-counted so this should be cheap.
Add a regression test via TSan. Confirmed that TSan indeed catches this.
Change-Id: I30ce7b757d3a44465b318af3c98961ff3667483e
Reviewed-on: https://boringssl-review.googlesource.com/c/33606
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Since we build Chrome with -mfpu=neon anyway, this isn't currently
needed. Additionally, I had included poly3_invert_vec in the assembly
but hadn't gotten around to wiring it up yet. That assembly referenced a
couple of functions in the C code that had been renamed. Surprisingly,
the NDK linker didn't have a problem with the undefined symbols since it
could statically find them to be unreachable.
But that isn't true everywhere. Some builds did fail because of the
undefined symbols although we're not sure what's different about them.
(Different NDK version perhaps?)
Change-Id: Ibac4724d24df05d6f6007499e1cd884e59889101
Reviewed-on: https://boringssl-review.googlesource.com/c/33604
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
We don't call it, so ship less code and reduce the number of places
where we must think about the bsaes -> aes_nohw fallback.
Bug: 256
Change-Id: I10ac2d70e18ec81e679631a9532c36d9edab1c6e
Reviewed-on: https://boringssl-review.googlesource.com/c/33586
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Even if the vector code isn't used in hrss.c, it might call external
assembly that still requires alignment.
Change-Id: I11ceb88f96deec6b20883872030ca090506ca150
Reviewed-on: https://boringssl-review.googlesource.com/c/33584
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
See the IETF thread here:
https://www.ietf.org/mail-archive/web/tls/current/msg27292.html
In particular, although the original publication of RFC 5246 had a
syntax error in the field (the minimum length was unspecified), there is
an errata from 2012 to fix it to be non-empty.
https://www.rfc-editor.org/errata/eid2864
Currently, when empty, we implicitly interpret it as SHA1/*, matching
the server behavior in missing extension in ClientHellos. However that
text does not support doing it for CertificateRequests, and there is not
much reason to. That default (which is in itself confusing and caused
problems such as older OpenSSL only signing SHA-1 given SNI) was
because, at the time, there were concerns over making any ClientHello
extensions mandatory. This isn't applicable for CertificateRequest,
which can freely advertise their true preferences.
Change-Id: I113494d8f66769fde1362795fb08ff2f471ef31d
Reviewed-on: https://boringssl-review.googlesource.com/c/33524
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
If BIO_read returns partial reads, d2i_*_bio currently fails. This is a
partial (hah) regression from 419144adce.
The old a_d2i_fp.c code did *not* tolerate partial reads in the ASN.1
header, but it *did* tolerate them in the ASN.1 body. Since partial
reads are more likely to land in the body than the header, I think we
can say d2i_*_bio was "supposed to" tolerate this but had a bug in the
first few bytes.
Fix it for both cases. Add a regression test for this and the partial
write case (which works fine).
See also https://github.com/google/conscrypt/pull/587.
Change-Id: I886f6388f0b80621960e196cf2a56f5c02a14a04
Reviewed-on: https://boringssl-review.googlesource.com/c/33484
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
It appears to be only used in p256-x86_64_test.cc, which is obviously
64-bit only and do not affected by this. Internal code search doesn't
find any uses and GitHub just finds several thousand copies of bn.h.
Change-Id: If8185bf6275d90efa172c95cb67c62c86a17e394
Reviewed-on: https://boringssl-review.googlesource.com/c/33464
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
It's not clear that any AMD XOP code paths are being properly tested.
AMD dropped XOP starting in Zen.
Here's the one place I found (without looking too hard) where it seems
there is a XOP code path in BoringSSL, in sha512-x86_64.pl. Most of the
other XOP code was removed.
```
$code.=<<___ if ($avx && $SZ==8);
test \$`1<<11`,%r10d # check for XOP
jnz .Lxop_shortcut
```
Change-Id: Id3301b2c84648790d010dae546b8e21ece1c528d
Reviewed-on: https://boringssl-review.googlesource.com/c/33405
Reviewed-by: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
It's not clear that CPUID will always report the correct value here,
especially for hyper-threading environments. It also isn't clear that
the assumptions made by AMD processors are correct and will always be
correct. It also seems likely that, if a code path is
security-sensitive w.r.t. SMT, it is probably also security-sensitive
w.r.t. other processor (mis)features. Finally, it isn't clear that all
dynamic analysis (fuzzing, SDE, etc.) is done separately for the cross
product of all CPU feature combinations * the value of this bit.
With all that in mind, instruct code sensitive to this bit to always
choose the more conservative path.
I only found one place that's sensitive to this bit, though I didn't
look too hard:
```
aes_nohw_cbc_encrypt:
[...]
leaq OPENSSL_ia32cap_P(%rip),%r10
mov (%r10), %r10d
[...]
bt \$28,%r10d
jc .Lcbc_slow_prologue
```
I didn't verify that the code in the HTT-enabled paths is any better
than the code in the HTT-disabled paths.
Change-Id: Ifd643e6a1301e5ca2174b84c344eb933d49e0067
Reviewed-on: https://boringssl-review.googlesource.com/c/33404
Reviewed-by: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
We don't support Windows XP, so we can rely on SRWLOCK. Per
https://crbug.com/592752, SRWLOCKs are more efficient and less of a
hassle to use. We'd previously converted CRYPTO_MUTEX to SRWLOCK, but I
missed this one. Not that this one lock matters much, may as well. It's
less initialization code.
Change-Id: I7ae435be5202b0a19f42015c9abff932dc04dbc7
Reviewed-on: https://boringssl-review.googlesource.com/c/33445
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This way we'll notice if we ever generate a bad padding extension or
duplicate an extension. This did require fixing one of the JDK11 test
vectors. When I manually added a padding extension, I forgot the
contents were all zeros and incorrectly put in "padding" instead.
Change-Id: Ifec5bb01a739014ed0fdf5b49b82a6b514646e9a
Reviewed-on: https://boringssl-review.googlesource.com/c/33444
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This teaches read_symbols.go to use debug/pe, and fixes miscellaneous
issues with NASM. It also reveals a problem with this strategy of
getting symbols out at the linker level: inline functions. I'm thinking
a better long-term mechanism may be to parse our header files.
Change-Id: I11b008543a7a97db3db9d4062ee4ddb910d174b7
Reviewed-on: https://boringssl-review.googlesource.com/c/33349
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
One less bit of special-casing in read_symbols.go. We filter out the
sysv-style symbol table, so we should filter out the macOS one too.
Add tests for util/ar to cover this and the Linux case.
Change-Id: Id16d8b0526c1b6e0149df1df4006848d7b3a4b2f
Reviewed-on: https://boringssl-review.googlesource.com/c/33347
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
It's more verbose, but trimming the panics should make it easier to move
to a library (e.g. a symbol checker) or unit test later.
Change-Id: Iab37eff2689955e58057528be092d6dd5d8d26bc
Reviewed-on: https://boringssl-review.googlesource.com/c/33344
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Squatting these names is rather rude. Also hex_to_string and
string_to_hex do the opposite of what one would expect, so rename them
to something a bit less confusing.
Update-Note: This removes some random utility functions. name_cmp is
very specific to OpenSSL's config file format, so it's unlikely anyone
is relying on it. I removed the one use of hex_to_string and
string_to_hex I could find.
Change-Id: I01554885ad306251e6982100d0b15cd89b1cdea7
Reviewed-on: https://boringssl-review.googlesource.com/c/33364
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Folks keep assuming checked-in assembly files are the source. Between
the preprocessor, delocate, NASM not using the C preprocessor, and GAS's
arch-specific comment syntax, comment markers are kind of a disaster.
This set appears to work for now.
Change-Id: I48e26dafb444dfa310df80dcce87ac291fde8037
Reviewed-on: https://boringssl-review.googlesource.com/c/33304
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
JDK 11 shipped with a TLS 1.3 implementation enabled by default.
Unfortunately, that implementation does not work and fails to send the
SNI extension on resumption. See
https://bugs.openjdk.java.net/browse/JDK-8211806.
This means servers which enable TLS 1.3 will see JDK 11 clients work on
the first connection and then fail on all subsequent connections. Add
SSL_set_jdk11_workaround which configures a workaround to fingerprint
JDK 11 and disable TLS 1.3 with the faulty clients.
JDK 11 also implemented the downgrade signal, which means that
connections that trigger the workaround also must not send the downgrade
signal. Unfortunately, the downgrade signal's security properties are
sensitive to the existence of any unmarked TLS 1.2 ServerHello paths. To
salvage this, pick a new random downgrade marker for this scenario and
modify the client to treat it as an alias of the standard one.
Per the link above, JDK 11.0.2 will fix this bug. Hopefully the
workaround can be retired sometime after it is released.
Change-Id: I0627609a8cadf7cc214073eb7f1e880acdf613ef
Reviewed-on: https://boringssl-review.googlesource.com/c/33284
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
ClusterFuzz folks want to switch to a shared library build, so call into
these another way. The new setup isn't quite ideal because the real code
builds as C and now tests as C++, but it should work.
Bug: chromium:907115
Change-Id: Ia1ffc18832739b09fee21b84ee5d181e61feaa15
Reviewed-on: https://boringssl-review.googlesource.com/c/33285
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
clang-format seems to have decided to format things differently now.
This will eliminate diff noise in the future when there are actual
changes.
Change-Id: I1f94cf0f0859023b6c926119f39bf0a587464e52
Reviewed-on: https://boringssl-review.googlesource.com/c/33266
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Put data in .rodata and, rather than adr, use the combination of adrp :pg_hi21:
and add :lo12:. Unfortunately, iOS uses different syntax, so we must add more
transforms to arm-xlate.pl.
Tested manually by:
1. Use Android NDK r19-beta1
2. Follow usual instructions to configure CMake for aarch64, but pass
-DCMAKE_EXE_LINKER_FLAGS="-fuse-ld=lld -Wl,-execute-only".
3. Build. Confirm with readelf -l tool/bssl that .text is not marked
readable.
4. Push the test binaries onto a Pixel 3. Test normally and with
--cpu={none,neon,crypto}. I had to pass --gtest_filter=-*Thread* to
crypto_test. There appears to be an issue with some runtime function
that's unrelated to our assembly.
No measurable performance difference.
Going forward, to support this, we will need to apply similar changes to
all other AArch64 assembly. This is relatively straightforward, but may
be a little finicky for dual-AArch32/AArch64 files (aesv8-armx.pl).
Update-Note: Assembly syntax is a mess. There's a decent chance some
assembler will get offend.
Change-Id: Ib59b921d4cce76584320fefd23e6bb7ebd4847eb
Reviewed-on: https://boringssl-review.googlesource.com/c/33245
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
The standard computation model for constant-time code is that memory
access patterns must be independent of secret data.
BN_mod_exp_mont_consttime was previously written to a slightly weaker
model: only cacheline access patterns must be independent of secret
data. It assumed accesses within a cacheline were indistinguishable.
The CacheBleed attack (https://eprint.iacr.org/2016/224.pdf) showed this
assumption was false. Cache lines may be divided into cache banks, and
the researchers were able to measure cache bank contention pre-Haswell.
For Haswell, the researchers note "But, as Haswell does show timing
variations that depend on low address bits [19], it may be vulnerable to
similar attacks."
OpenSSL's fix to CacheBleed was not to adopt the standard constant-time
computation model. Rather, it now assumes accesses within a 16-byte
cache bank are indistinguishable, at least in the C copy_from_prebuf
path. These weaker models failed before with CacheBleed, so avoiding
such assumptions seems prudent. (The [19] citation above notes a false
dependence between memory addresses with a distance of 4k, which may be
what the paper was referring to.) Moreover, the C path is largely unused
on x86_64 (which uses mont5 asm), so it is especially questionable for
the generic C code to make assumptions based on x86_64.
Just walk the entire table in the C implementation. Doing so as-is comes
with a performance hit, but the striped memory layout is, at that point,
useless. We regain the performance loss (and then some) by using a more
natural layout. Benchmarks below.
This CL does not touch the mont5 assembly; I haven't figured out what
it's doing yet.
Pixel 3, aarch64:
Before:
Did 3146 RSA 2048 signing operations in 10009070us (314.3 ops/sec)
Did 447 RSA 4096 signing operations in 10026666us (44.6 ops/sec)
After:
Did 3210 RSA 2048 signing operations in 10010712us (320.7 ops/sec)
Did 456 RSA 4096 signing operations in 10063543us (45.3 ops/sec)
Pixel 3, armv7:
Before:
Did 2688 RSA 2048 signing operations in 10002266us (268.7 ops/sec)
Did 459 RSA 4096 signing operations in 10004785us (45.9 ops/sec)
After:
Did 2709 RSA 2048 signing operations in 10001299us (270.9 ops/sec)
Did 459 RSA 4096 signing operations in 10063737us (45.6 ops/sec)
x86_64 Broadwell, mont5 assembly disabled:
(This configuration is not actually shipped anywhere, but seemed a
useful data point.)
Before:
Did 14274 RSA 2048 signing operations in 10009130us (1426.1 ops/sec)
Did 2448 RSA 4096 signing operations in 10046921us (243.7 ops/sec)
After:
Did 14706 RSA 2048 signing operations in 10037908us (1465.0 ops/sec)
Did 2538 RSA 4096 signing operations in 10059986us (252.3 ops/sec)
Change-Id: If41da911d4281433856a86c6c8eadf99cd33e2d8
Reviewed-on: https://boringssl-review.googlesource.com/c/33268
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
cfd50c63 switched to using the add/dbl of p224_64.c, but the outputs
weren't contracted before being returned and could be out of range,
giving invalid results.
Change-Id: I3cc295c7ddbff43375770dbafe73b37a668e4e6b
Reviewed-on: https://boringssl-review.googlesource.com/c/33184
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
C99 added macros such as PRIu64 to inttypes.h, but it said to exclude them from
C++ unless __STDC_FORMAT_MACROS or __STDC_CONSTANT_MACROS was defined. This
text was never incorporated into any C++ standard and explicitly overruled in
C++11.
Some libc headers followed C99. Notably, glibc prior to 2.18
(https://sourceware.org/bugzilla/show_bug.cgi?id=15366) and old versions of the
Android NDK.
In the NDK, although it was fixed some time ago (API level 20), the NDK used to
use separate headers per API level. Only applications using minSdkVersion >= 20
would get the fix. Starting NDK r14, "unified" headers are available which,
among other things, make the fix available (opt-in) independent of
minSdkVersion. In r15, unified headers are opt-out, and in r16 they are
mandatory.
Try removing these and see if anyone notices. The former is past our five year
watermark. The latter is not and Android has hit
https://boringssl-review.googlesource.com/c/boringssl/+/32686 before, but
unless it is really widespread, it's probably simpler to ask consumers to
define __STDC_CONSTANT_MACROS and __STDC_FORMAT_MACROS globally.
Update-Note: If you see compile failures relating to PRIu64, UINT64_MAX, and
friends, update your glibc or NDK. As a short-term fix, add
__STDC_CONSTANT_MACROS and __STDC_FORMAT_MACROS to your build, but get in touch
so we have a sense of how widespread it is.
Bug: 198
Change-Id: I56cca5f9acdff803de1748254bc45096e4c959c2
Reviewed-on: https://boringssl-review.googlesource.com/c/33146
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>
The change seems to have stuck, so bring us closer to C/++11 static asserts.
(If we later find we need to support worse toolchains, we can always use
__LINE__ or __COUNTER__ to avoid duplicate typedef names and just punt on
embedding the message into the type name.)
Change-Id: I0e5bb1106405066f07740728e19ebe13cae3e0ee
Reviewed-on: https://boringssl-review.googlesource.com/c/33145
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>
Chromium has now switched to building our assembly with NASM
(https://crbug.com/766721), which is more maintained. Next step
is to switch remaining folks (Conscrypt, not sure if there's anyone
else) and we'll drop Yasm.
Change-Id: If4f45399b48d0d7477afb47647e83e7250bf854f
Reviewed-on: https://boringssl-review.googlesource.com/c/33144
Reviewed-by: Adam Langley <agl@google.com>
For simplicity, punt order > field or width mismatches. Analogous
optimizations are possible, but the generic path works fine and no
commonly-used curve looks hits those cases.
Before:
Did 5888 ECDSA P-384 verify operations in 3094535us (1902.7 ops/sec)
After [+6.7%]:
Did 6107 ECDSA P-384 verify operations in 3007515us (2030.6 ops/sec)
Also we can fill in p - order generically and avoid extra copies of some
constants.
Change-Id: I38e1b6d51b28ed4f8cb74697b00a4f0fbc5efc3c
Reviewed-on: https://boringssl-review.googlesource.com/c/33068
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
This removes the last mention of LHASH in public headers. This can only
break people who stack-allocate CONF or access the data field. The
latter does not happen (external code never calls lh_CONF_VALUE_*
functions). The former could not work as there would be no way to clean
it up.
Update-Note: CONF is now opaque.
Change-Id: Iad3796c4e75874530d7a70fde2f84a390def2d49
Reviewed-on: https://boringssl-review.googlesource.com/32118
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>
Everyone calls this with NULL anyway. People never actually use
lh_CONF_VALUE_* functions (or any other lh_* functions for that matter).
Also remove unused X509V3_EXT_CRL_add_conf prototype.
This removes one of the last mentions of LHASH_OF in public headers.
Update-Note: X509V3_EXT_conf_nid calls that pass a non-NULL first
parameter will fail to compile.
Change-Id: Ia6302ef7b494efeb9b63ab75a18bc340909dcba3
Reviewed-on: https://boringssl-review.googlesource.com/32117
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>
C and C++ handle inline functions differently. In C++, an inline function is
defined in just the header file, potentially emitted in multiple compilation
units (in cases the compiler did not inline), but each copy must be identical
to satsify ODR. In C, a non-static inline must be manually emitted in exactly
one compilation unit with a separate extern inline declaration.
In both languages, exported inline functions referencing file-local symbols are
problematic. C forbids this altogether (though GCC and Clang seem not to
enforce it). It works in C++, but ODR requires the definitions be identical,
including all names in the definitions resolving to the "same entity". In
practice, this is unlikely to be a problem, but an inline function that returns
a pointer to a file-local symbol could compile oddly.
Historically, we used static inline in headers. However, to satisfy ODR, use
plain inline in C++, to allow inline consumer functions to call our header
functions. Plain inline would also work better with C99 inline, but that is not
used much in practice, extern inline is tedious, and there are conflicts with
the old gnu89 model: https://stackoverflow.com/questions/216510/extern-inline
For dual C/C++ code, use a macro to dispatch between these. For C++-only
code, stop using static inline and just use plain inline.
Update-Note: If you see weird C++ compile or link failures in header
functions, this change is probably to blame. Though this change
doesn't affect C and non-static inline is extremely common in C++,
so I would expect this to be fine.
Change-Id: Ibb0bf8ff57143fc14e10342854e467f85a5e4a82
Reviewed-on: https://boringssl-review.googlesource.com/32116
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>
TARGET_OS_IPHONE isn't defined without including <TargetConditionals.h>. Oops.
Confirmed now that OPENSSL_IOS gets defined where we expect.
Update-Note: There is some chance this will fail to build on some macOS host
builds of Android? https://codereview.chromium.org/538563002 suggests something
weird happens. However those Android builds of BoringSSL would already be
problematic because they'd set OPENSSL_STATIC_ARMCAP thinking they were iOS.
Thus I've intentionally kept the assumption that __APPLE__ implies a Darwin
target. If it goes through, all is well. If not, we'll learn more about that
configuration and that we likely need to revise our OPENSSL_APPLE definition.
Bug: chromium:890115
Change-Id: I1df73ac2321391d2449edbeb9cfa295fd607f935
Reviewed-on: https://boringssl-review.googlesource.com/32204
Reviewed-by: Adam Langley <agl@google.com>
This fixes:
- Undefined function pointer casts.
- Missing X509_INFO_new malloc failure checks.
- Pointless (int) cast on strlen.
- Missing ERR_GET_LIB in PEM_R_NO_START_LINE check.
- Broken error-handling if passing in an existing stack and we hit a
syntax error.
Bug: chromium:785442
Change-Id: I8be3523b0f13bdb3745938af9740d491486f8bf1
Reviewed-on: https://boringssl-review.googlesource.com/32109
Reviewed-by: Adam Langley <agl@google.com>
This one is a little thorny. All the various block cipher modes
functions and callbacks take a void *key. This allows them to be used
with multiple kinds of block ciphers.
However, the implementations of those callbacks are the normal typed
functions, like AES_encrypt. Those take AES_KEY *key. While, at the ABI
level, this is perfectly fine, C considers this undefined behavior.
If we wish to preserve this genericness, we could either instantiate
multiple versions of these mode functions or create wrappers of
AES_encrypt, etc., that take void *key.
The former means more code and is tedious without C++ templates (maybe
someday...). The latter would not be difficult for a compiler to
optimize out. C mistakenly allowed comparing function pointers for
equality, which means a compiler cannot replace pointers to wrapper
functions with the real thing. (That said, the performance-sensitive
bits already act in chunks, e.g. ctr128_f, so the function call overhead
shouldn't matter.)
But our only 128-bit block cipher is AES anyway, so I just switched
things to use AES_KEY throughout. AES is doing fine, and hopefully we
would have the sense not to pair a hypothetical future block cipher with
so many modes!
Change-Id: Ied3e843f0e3042a439f09e655b29847ade9d4c7d
Reviewed-on: https://boringssl-review.googlesource.com/32107
Reviewed-by: Adam Langley <agl@google.com>
Lacking C++, this instead adds a mess of macros. With this done, all the
function-pointer-munging "_of" macros in asn1.h can also be removed.
Update-Note: A number of *really* old and unused ASN.1 macros were
removed.
Bug: chromium:785442
Change-Id: Iab260d114c7d8cdf0429759e714d91ce3f3c04b2
Reviewed-on: https://boringssl-review.googlesource.com/32106
Reviewed-by: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <alangley@gmail.com>
While it is okay to cast function pointers into different types for
generic storage, the pointer must be cast back to the exact same type
when calling. In particular, although C libraries do this sort of thing
all the time, calling a T* d2i function as a void* d2i function is
undefined:
If the function is defined with a type that is not compatible with the
type (of the expression) pointed to by the expression that denotes the
called function, the behavior is undefined
Fix some instances in the PEM/ASN1 wrapper functions. Synthesize helper
functions instead.
This CL just addresses the function pointer issues. The inherited legacy
OpenSSL ASN.1 code is still full other questionable data pointer dances
that will be much more difficult to excise. Continuing to exise that
code altogether (it is already unshipped from Cronet and unshipped from
Chrome but for WebRTC) is probably a better tack there.
This removes one (of many many) places where we require
-fsanitize-cfi-icall-generalize-pointers.
Bug: chromium:785442
Change-Id: Id8056ead6ef471f0fdf263bb50dc659da500e8ce
Reviewed-on: https://boringssl-review.googlesource.com/32105
Reviewed-by: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <alangley@gmail.com>
Debugging a POST failure when it prints nothing is painful. The
|check_test| helper already prints out information when it fails, but
some other paths were not handled. This change adds printfs for those
cases.
Change-Id: Ife71bb292a4f69679d0fa56686863aae9423e451
Updating-Note: updates internal bug 116469121
Reviewed-on: https://boringssl-review.googlesource.com/32145
Reviewed-by: David Benjamin <davidben@google.com>
BoringSSL depends on the platform's locking APIs to make internal global
state thread-safe, including the PRNG. On some single-threaded embedded
platforms, locking APIs may not exist, so this dependency may be disabled
with a build flag.
Doing so means the consumer promises the library will never be used in any
multi-threaded address space. It causes BoringSSL to be globally thread-unsafe.
Setting it inappropriately will subtly and unpredictably corrupt memory and
leak secret keys.
Unfortunately, folks sometimes misinterpreted OPENSSL_NO_THREADS as skipping an
internal thread pool or disabling an optionally extra-thread-safe mode. This is
not and has never been the case. Rename it to
OPENSSL_NO_THREADS_CORRUPT_MEMORY_AND_LEAK_SECRETS_IF_THREADED to clarify what
this option does.
Update-Note: As a first step, this CL makes both OPENSSL_NO_THREADS and
OPENSSL_NO_THREADS_CORRUPT_MEMORY_AND_LEAK_SECRETS_IF_THREADED work. A later CL
will remove the old name, so migrate callers after or at the same time as
picking up this CL.
Change-Id: Ibe4964ae43eb7a52f08fd966fccb330c0cc11a8c
Reviewed-on: https://boringssl-review.googlesource.com/32084
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>
- Add util/read_symbols.go to read exported symbols from an AR
file for use with the symbol prefixing feature
- Move util/fipstools/fipscommon/ar.go -> util/ar/ar.go
- util/ar/ar.go: Support BSD-style AR files
Change-Id: I171b3b952e69c4b87ac04751b7dba3ea9bc2504e
Reviewed-on: https://boringssl-review.googlesource.com/32024
Reviewed-by: David Benjamin <davidben@google.com>
While I don't believe EINTR can occur with a non-blocking getrandom call
when talking to the kernel directly, that may not be true when certain
sandboxing systems are being used.
Additionally, with this change we will no longer silently ignore errors
other than ENOSYS.
Update-Note: update internal bug 115344138.
Change-Id: I952c132cf325dcc17dc38e68f054abc41de1f8b0
Reviewed-on: https://boringssl-review.googlesource.com/32006
Reviewed-by: David Benjamin <davidben@google.com>
This function doesn't actually exist. (If it did, it would be the same as
SHA512_Transform. We currently omit SHA224 and SHA384's low-level transform
functions.)
Change-Id: Ia9d3d7c86e8f70fd5e4f13b8de4f08440dccbdcb
Reviewed-on: https://boringssl-review.googlesource.com/32064
Reviewed-by: Adam Langley <agl@google.com>
This makes running go test, etc., in util/fipstools/delocate work! This
adds a go_executable command to CMake like:
go_executable(delocate boringssl.googlesource.com/boringssl/util/fipstools/delocate)
which internally gets dependencies and whatnot so it behaves like usual
Go.
Update-Note: delocate has been rearranged a bit.
Change-Id: I244a7317dd8d4f2ab77a0daa624ed3e0b385faef
Reviewed-on: https://boringssl-review.googlesource.com/31885
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>
EVP_AEAD reused portions of EVP_CIPHER's GCM128_CONTEXT which contains both the
key and intermediate state for each operation. (The legacy OpenSSL EVP_CIPHER
API has no way to store just a key.) Split out a GCM128_KEY and store that
instead.
Change-Id: Ibc550084fa82963d3860346ed26f9cf170dceda5
Reviewed-on: https://boringssl-review.googlesource.com/32004
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>
This should make it easier for us to reuse Go code properly.
util/fipstools is kind of a mess. runner has been using relative
imports, but Go seems to prefer this mechanism these days.
Update-Note: The import spelling in ssl/test/runner changes. Also we now
require Go 1.11. Or you could clone us into GOPATH, but no one does
that.
Change-Id: I8bf91e1e0345b3d0b3d17f5c642fe78b415b7dde
Reviewed-on: https://boringssl-review.googlesource.com/31884
Reviewed-by: Adam Langley <agl@google.com>
Providing a size hint to the allocator is substantially faster,
especially as we already know/need the size for OPENSSL_cleanse.
We provide a weak symbol that falls back to free when a malloc with
sdallocx is not statically linked with BoringSSL.
Alternatives considered:
* Use dlsym(): This is prone to fail on statically linked binaries
without symbols. Additionally, the extra indirection adds call
overhead above and beyond the linker resolved technique we're using.
* Use CMake rules to identify whether sdallocx is available: Once the
library is built, we may link against a variety of malloc
implementations (not all of which may have sdallocx), so we need to
have a fallback when the symbol is unavailable.
Change-Id: I3a78e88fac5b6e5d4712aa0347d2ba6b43046e07
Reviewed-on: https://boringssl-review.googlesource.com/31784
Reviewed-by: Chris Kennelly <ckennelly@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This was added to support the no_certificate warning alert in SSLv3. That has
since been removed. In the long run, I would like for ssl_send_alert to go
through a flow similar to add_alert so the BIO-free APIs work right and avoid a
host of strangeness surrounding wpend_buf. For now, remove the unused hook.
Change-Id: I1995028b8af4ffa836028794e6b33b2cd1b2435b
Reviewed-on: https://boringssl-review.googlesource.com/31984
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>
In particular, pull Go 1.11 to get module support. Also we don't need to
pull in libfuzzer anymore.
Change-Id: I8098f64cef59422d9d43f7eca5bf3ced69eb70c4
Reviewed-on: https://boringssl-review.googlesource.com/31864
Reviewed-by: Adam Langley <agl@google.com>
MSAN is incompatible with hand-written assembly code. Previously we
required that OPENSSL_NO_ASM be set when building with MSAN, and the
CMake build would take care of this. However, with other build systems
it wasn't always so easy.
This change automatically disables assembly when the compiler is
configured for MSAN.
Change-Id: I6c219120f62d16b99bafc2efb02948ecbecaf87f
Reviewed-on: https://boringssl-review.googlesource.com/31724
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>
Also point out that we're a cryptography library, not a text encoding library.
Not that that'll dissuade anyone.
Change-Id: Ia324e08c5cdd108fa182d2610f80447262e0bd5c
Reviewed-on: https://boringssl-review.googlesource.com/31664
Reviewed-by: Adam Langley <agl@google.com>
We're a far cry from the good old days when we just read from /dev/urandom
without any fuss...
In particular, the threading logic is slightly non-trivial and probably worth
some basic sanity checks. Also write a fork-safety test, and test the
fork-unsafe-buffering path.
The last one is less useful right now, since fork-unsafe-buffering is a no-op
with RDRAND enabled (although we do have an SDE bot...), but it's probably
worth exercising the code in
https://boringssl-review.googlesource.com/c/boringssl/+/31564.
Change-Id: I14b1fc5216f2a93183286aa9b35f5f2309107fb2
Reviewed-on: https://boringssl-review.googlesource.com/31684
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>
- In base.h, if BORINGSSL_PREFIX is defined, include
boringssl_prefix_symbols.h
- In all .S files, if BORINGSSL_PREFIX is defined, include
boringssl_prefix_symbols_asm.h
- In base.h, BSSL_NAMESPACE_BEGIN and BSSL_NAMESPACE_END are
defined with appropriate values depending on whether
BORINGSSL_PREFIX is defined; these macros are used in place
of 'namespace bssl {' and '}'
- Add util/make_prefix_headers.go, which takes a list of symbols
and auto-generates the header files mentioned above
- In CMakeLists.txt, if BORINGSSL_PREFIX and BORINGSSL_PREFIX_SYMBOLS
are defined, run util/make_prefix_headers.go to generate header
files
- In various CMakeLists.txt files, add "global_target" that all
targets depend on to give us a place to hook logic that must run
before all other targets (in particular, the header file generation
logic)
- Document this in BUILDING.md, including the fact that it is
the caller's responsibility to provide the symbol list and keep it
up to date
- Note that this scheme has not been tested on Windows, and likely
does not work on it; Windows support will need to be added in a
future commit
Change-Id: If66a7157f46b5b66230ef91e15826b910cf979a2
Reviewed-on: https://boringssl-review.googlesource.com/31364
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: David Benjamin <davidben@google.com>
Historically, OpenSSL filled in a fake session ID for ticket-only
client sessions. Conscrypt relies on this to implement some weird Java
API where every session has an ID and may be queried out of the client
session cache and, e.g., revoked that way.
(Note that a correct client session cache is not keyed by session ID and
indeed this allows one server to knock out another server's sessions by
matching session IDs. But existing APIs are existing APIs.)
For consistency between TLS 1.2 and TLS 1.3, as well as matching
OpenSSL's TLS 1.3 implementation, do the same in TLS 1.3. Note this
smooths over our cross-version resumption tests by allowing for
something odd: it is now syntactically possible to resume a TLS 1.3
session at TLS 1.2. It doesn't matter either way, but now a different
codepath rejects certain cases.
Change-Id: I9caf4f0c3b2e2e24ae25752826d47bce77e65616
Reviewed-on: https://boringssl-review.googlesource.com/31525
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>
Flattening the build seems to have changed the order of actions when
using Make and output directories for perlasm are no longer created
before Perl is run. Additionally, if the output directory doesn't exist,
the perlasm scripts seem to output to stdout instead.
Change-Id: I59b801f7347951a3b9cef2ff084b28a00b2d5a3c
Reviewed-on: https://boringssl-review.googlesource.com/31645
Reviewed-by: Adam Langley <agl@google.com>
Not sure that I think this is a very valid build error from GCC, but
it's easy enough to work around.
../crypto/cpu-arm-linux_test.cc: In member function ‘virtual void ARMLinuxTest_CPUInfo_Test::TestBody()’:
../crypto/cpu-arm-linux_test.cc:25:10: error: declaration of ‘struct ARMLinuxTest_CPUInfo_Test::TestBody()::Test’ shadows a previous local [-Werror=shadow]
struct Test {
^~~~
In file included from ../crypto/cpu-arm-linux_test.cc:19:
../third_party/googletest/include/gtest/gtest.h:375:23: note: shadowed declaration is here
class GTEST_API_ Test {
Change-Id: Icc1676a621ec26b3665adaf5daf7d6c6f5307ba8
Reviewed-on: https://boringssl-review.googlesource.com/31624
Reviewed-by: Adam Langley <agl@google.com>
The fipsmodule is still separate as that's a lot of build mess. (Though
that too may be worth pulling in eventually. CMake usually has different
opinions on generated files if they're in the same directory. We might
be able to avoid the set_source_properties(GENERATED) thing.)
Change-Id: Ie1f9345009044d4f0e7541ca779e01bdc5ad62f6
Reviewed-on: https://boringssl-review.googlesource.com/31586
Reviewed-by: Adam Langley <agl@google.com>
It was pointed out that "a reference" to C++ programmers means something
very different from what we intend.
Change-Id: I508196f8e3427ea71439c7871eae9b735a4fa5ca
Reviewed-on: https://boringssl-review.googlesource.com/31544
Reviewed-by: Adam Langley <agl@google.com>
I realized looking at the sigalgs parser that I messed up the
space-splitting logic slightly. If the CPU features are "foo bar baz",
it would not parse "baz". This doesn't particular matter (the last one
is "crc32"), but better to parse it correctly.
Fix this and add a unit test. While I'm here, may as well add a fuzzer
too.
Change-Id: Ifc1603b8f70d975f391d10e51ede95deec31a83d
Reviewed-on: https://boringssl-review.googlesource.com/31464
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/31085 wasn't right. We already forbid
creating BN_MONT_CTX on negative numbers, which means almost all moduli already
don't work with BN_mod_exp_mont. Only -1 happened to not get rejected, but it
computed the wrong value. Reject it instead.
Update-Note: BN_mod_exp* will no longer work for negative moduli. It already
didn't work for all negative odd moduli other than -1, so rejecting -1 and
negative evens is unlikely to be noticed.
Bug: 71
Change-Id: I7c713d417e2e6512f3e78f402de88540809977e3
Reviewed-on: https://boringssl-review.googlesource.com/31484
Reviewed-by: Adam Langley <agl@google.com>
This often causes confusion since, for various silly reasons (intrinsic
ref-counting, FOO_METHOD, and RSA's cached Montgomery bits), the thread
safety of some functions don't match the usual const/non-const
distinction. Fix const-ness where easy and document it otherwise.
Change-Id: If2037a4874d7580cc79b18ee21f12ae0f47db7fd
Reviewed-on: https://boringssl-review.googlesource.com/31344
Reviewed-by: Ryan Sleevi <rsleevi@chromium.org>
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>
With Clang 6.0, libFuzzer is now included and there's a new
-fsanitize=fuzzer command to enable the needed compiler actions.
Change-Id: If8c0d649f494655c5bb1e55ebdbf39450940c75b
Reviewed-on: https://boringssl-review.googlesource.com/31324
Reviewed-by: David Benjamin <davidben@google.com>
The client downgrade detection tests were not asserting on the error (would
have caught the missing error string). Additionally, Downgrade-FalseStart-Draft
isn't testing what it's supposed to; it doesn't actually configure a draft
version or anything. Fix that and have it use ALPN rather than NPN, to match
the test above.
Change-Id: I0b759385641aa00994a912303a6f5bd65522b4bb
Reviewed-on: https://boringssl-review.googlesource.com/31204
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>
Imported from upstream's 0971432f6f6d8b40d797133621809bd31eb7bf4e and
7d4c97add12cfa5d4589880b09d6139c3203e2f4, but with missing tests added. Along
the way, make Bytes work with any Span<const uint8_t>-convertable type.
Change-Id: If365f981fe8a8274e12000309ffd99b1bb719842
Reviewed-on: https://boringssl-review.googlesource.com/31086
Reviewed-by: Adam Langley <agl@google.com>
Historically, OpenSSL's modular exponentiation functions tolerated negative
moduli by ignoring the sign bit. The special case for a modulus of 1 should do
the same. That said, this is ridiculous and the only reason I'm importing this
is BN_abs_is_word(1) is marginally more efficient than BN_is_one() and we
haven't gotten around to enforcing positive moduli yet.
Thanks to Guido Vranken and OSSFuzz for finding this issue and reporting to
OpenSSL.
(Imported from upstream's 235119f015e46a74040b78b10fd6e954f7f07774.)
Change-Id: I526889dfbe2356753aa1e6ecfd3aa3dc3a8cd2b8
Reviewed-on: https://boringssl-review.googlesource.com/31085
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This fixes uninitialized memory read reported by Nick Mathewson in
https://github.com/openssl/openssl/issues/6347.
It imports the memset from upstream's 2c739f72e5236a8e0c351c00047c77083dcdb77f,
but I believe that fix is incorrect and instead RC4 shouldn't be allowed in
this context. See
https://github.com/openssl/openssl/pull/6603#issuecomment-413066462 for
details.
Update-Note: Decoding a password-protected PEM block with RC4 will, rather than
derive garbage from uninitialized memory, simply fail. Trying to encode a
password-protect PEM block with an unsupported cipher will also fail, rather
than output garbage (e.g. tag-less AES-GCM).
Change-Id: Ib7e23dbf5514f0a523730926daad3c0bdb989417
Reviewed-on: https://boringssl-review.googlesource.com/31084
Reviewed-by: Adam Langley <agl@google.com>
This isn't actually shorter, but there is a bunch of slicing up of the ticket,
which Span makes a little easier to follow.
Change-Id: I7ea4dfe025641a3b88e2c9b8e34246fefc23412f
Reviewed-on: https://boringssl-review.googlesource.com/29865
Reviewed-by: Adam Langley <agl@google.com>
Works in the 1.3 and 1.2 client handshakes, not implemented on the
server for now.
Creates an SSL_CTX option to reverify the server certificate on session
resumption. Reverification only runs the client's certificate verify callback.
Adds new states to the client handshakes: state_reverify_server_certificate in
TLS 1.2, and state_server_certificate_reverify in TLS 1.3.
Adds a negative test to make sure that by default we don't verify the
certificate on resumption, and positive tests that make sure we do when the
new option is set.
Change-Id: I3a47ff3eacb3099df4db4c5bc57f7c801ceea8f1
Bug: chromium:347402
Reviewed-on: https://boringssl-review.googlesource.com/29984
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>
Along the way, split up the EVPTest Wycheproof tests into separate tests (they
shard better when running in parallel).
Change-Id: I5ee919f7ec7c35a7f2e0cc2af4142991a808a9db
Reviewed-on: https://boringssl-review.googlesource.com/30846
Reviewed-by: Adam Langley <agl@google.com>
Also remove some transition step for a recent format change. Together, this
removes the curve hacks in the converter, which can now be purely syntactic.
The RSA ones are still a bit all over the place in terms of sharded vs
combined, so leaving that alone for now.
Change-Id: I721d6b0de388a53a39543725e366dc5b52e83561
Reviewed-on: https://boringssl-review.googlesource.com/30845
Reviewed-by: Adam Langley <agl@google.com>
The size of an int is 4, not 2. To avoid worrying about this, add a GetVector
counterpart to GetString that handles all this. Apply this uniformly to avoid
all the pointer casts. This is less important for vector<uint8_t>, but even
then we'll now notice a 1-byte OOB read since std::string is NUL-terminated.
Also it's shorter.
Change-Id: Ie96591cb8d8d52742f5fd30d70b6af0511109585
Reviewed-on: https://boringssl-review.googlesource.com/30864
Reviewed-by: Adam Langley <agl@google.com>
We currently write a mix of "if (FOO)" and "if(FOO)". While the former looks
more like a usual language, CMake believes everything, even "if" and "else", is
just a really really funny function call (a "command").
We should pick something for consistency. Upstream CMake writes "if(FOO)", so
go with that one.
Change-Id: I67e0eb650a52670110b417312a362c9f161c8721
Reviewed-on: https://boringssl-review.googlesource.com/30807
Reviewed-by: Adam Langley <agl@google.com>
SSL_CTX_set1_sigalgs_list wants a NUL-terminated string, so we need to use
GetString to give it one.
Bug: oss-fuzz:9808
Change-Id: Id7f676aa514c36de9dea900763db3cbbf5c79a4c
Reviewed-on: https://boringssl-review.googlesource.com/30804
Reviewed-by: Adam Langley <agl@google.com>
The CFI bot is currently failing on a mysterious error message, coming from the
recent clang roll.
Called function is not the same type as the call!
call void @EVP_MD_CTX_init(%struct.env_md_ctx_st* %8), !dbg !72123
LLVM ERROR: Broken function found, compilation aborted!
Chromium actually passes -flto=thin, which seems to avoid the error, testing
locally. Why it does, I haven't the slightest clue. The offending calls to
EVP_MD_CTX_init (and EVP_MD_CTX_cleanup) are those buried in
bssl::ScopedEVP_MD_CTX. However, not all calls are problematic, only the one in
test_config.cc. What's more, if I add a call in async_bio.cc, linked into all
the same targets, the copy in test_config.cc is suddenly fine!?
Maybe there's just a bug in the LTO logic that ThinLTO avoids...
Change-Id: I5266eec75edea2a38dee8ad5591db8d65d3bdede
Reviewed-on: https://boringssl-review.googlesource.com/30805
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>
MSan and TSan both require instrumenting everything. Add some machinery so we
can do this on the bots.
Change-Id: I7d2106bc852ee976455d18787d3a20a35373a9e7
Reviewed-on: https://boringssl-review.googlesource.com/30644
Reviewed-by: Adam Langley <agl@google.com>
ExpectTicketKeyChanged treats its input as an in/out parameter, but the first
time around there isn't a previous key. We could just call
SSL_CTX_get_tlsext_ticket_keys directly, but running it with the "previous"
keys as all zeros seems prudent; the ticket key rotation logic lazily
initializes keys and, were we to accidentally forget to initialize a key, the
zero key seems the most likely culprit.
Change-Id: I7167bef78e0bfcdb178195230ad84597f26d825c
Reviewed-on: https://boringssl-review.googlesource.com/30684
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
These functions can be used to configure the signature algorithms. One
of them is a string mini-languaging parsing function, which we generally
dislike because it defeats static analysis. However, some dependent
projects (in this case TensorFlow) need it and we also dislike making
people patch.
Change-Id: I13f990c896a7f7332d78b1c351357d418ade8d11
Reviewed-on: https://boringssl-review.googlesource.com/30304
Reviewed-by: Steven Valdez <svaldez@google.com>
embed_test_data.go assumes that it's working with 8KB chunks. However,
if the input file contains a '\' then the Go code thinks that it counts
as a byte, but the C compiler will probably merge it with the following
char and thus that string will be slightly too short. ASAN will detect
the out-of-bounds read when 8192 bytes are copied from the string.
Change-Id: If40ccfd39ea013bd6935fcc313cfe188fe985f67
Reviewed-on: https://boringssl-review.googlesource.com/30444
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>
The previous limit was |UINT_MAX|. Windows limits to 600K, but that's
already causing issues. This seems like a balance between being
completely crazy and still large enough not to have to worry for a long
time. It's still probably too large for backend systems wanting to
process arbitrary PKCS#12, but I don't think any fixed value will
satisfy all desires.
Change-Id: I01a3f78d5f2df086f8dbc0e8bacfb95153738f55
Reviewed-on: https://boringssl-review.googlesource.com/30424
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 change syncs several assembly files from upstream. The only meanful
additions are more CFI directives.
Change-Id: I6aec50b6fddbea297b79bae22cfd68d5c115220f
Reviewed-on: https://boringssl-review.googlesource.com/30364
Reviewed-by: Adam Langley <agl@google.com>
In fuzzing builds, session resumptions fail if the PRNG behaves the
same as in the initial session. Not sure of the reason, but a kick to
the PRNG fixes the problem and doesn't compromise determinism, so
... *shrug*?
Change-Id: I8181d98fdff16ae82255e9cda33ce5c4c40b5399
Reviewed-on: https://boringssl-review.googlesource.com/30284
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
OpenSSL 1.0.2 (and thus BoringSSL) accepts keyUsage certSign or a
Netscape CA certificate-type in lieu of basicConstraints in an
intermediate certificate (unless X509_V_FLAG_X509_STRICT) is set.
Update-Note: This change tightens the code so that basicConstraints is required for intermediate certificates when verifying chains. This was previously only enabled if X509_V_FLAG_X509_STRICT was set, but that flag also has other effects.
Change-Id: I9e41f4c567084cf30ed08f015a744959982940af
Reviewed-on: https://boringssl-review.googlesource.com/30185
Reviewed-by: Matt Braithwaite <mab@google.com>
This change adds a new flag, X509_V_FLAG_REQUIRE_CA_BASIC_CONSTRAINTS,
which causes basicConstraints with isCA to be required for intermediate
CA certificates. Without this, intermediates are also acceptable if
they're missing basicConstraints, but include either a certSign
keyUsage, or a CA Netscape certificate type.
This is a short-term change for patching. I'll undo a lot of it and make
this the default in the next change.
Change-Id: I7f42ffd76c57de3037f054108951e230c1b4e415
Reviewed-on: https://boringssl-review.googlesource.com/30184
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Matt Braithwaite <mab@google.com>
The runner currently expects split handshake tests to work is GOOS is
"linux", but that includes Android, which the shim doesn't support.
Rather than try to align these two conditions, have the runner ask the
shim whether it supports split handshakes or not.
Change-Id: I7bea0d94142c4b6ee42b8f54c67b8611da93feb3
Reviewed-on: https://boringssl-review.googlesource.com/30204
Reviewed-by: Matt Braithwaite <mab@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>
The new binary, called |handshaker|, allows split-handshakes to be
tested using shim and handshaker binaries built at different
revisions.
The shim now proxies traffic to the handshaker during the split
handshake. The handoff and handback steps serialize additional state
about the test being performed, and its results.
The proxy and handshaker make heavy use of Unix-isms, and so
split-handshake tests are now restricted to Linux.
Change-Id: I048f0540c3978a31b3e573e00da17caf41a8059e
Reviewed-on: https://boringssl-review.googlesource.com/29348
Reviewed-by: Adam Langley <agl@google.com>
Setting OPENSSL_NO_ASM skips enabling the “ASM” language in CMake.
However, the FIPS module fundamentally needs to build asm because
delocate works via textual assembly. Thus this combination is currently
broken with CMake.
This change ensures that support for building asm is enabled in CMake
for this combination.
Change-Id: I4516cf3a6f579ee7c72f04ac25d15785926cf125
Reviewed-on: https://boringssl-review.googlesource.com/29884
Reviewed-by: Adam Langley <agl@google.com>
This change adds a function so that an ECDH and the hashing of the
resulting 'x' coordinate can occur inside the FIPS boundary.
Change-Id: If93c20a70dc9dcbca49056f10915d3ce064f641f
Reviewed-on: https://boringssl-review.googlesource.com/30104
Reviewed-by: Adam Langley <agl@google.com>
Future versions of the Wycheproof vectors will specify the curve for a
group of tests, rather than for each test. This change works with both
the old and new style.
Change-Id: I0d9a503c8357eb4c617544e727d8f4a703c2c2b0
Reviewed-on: https://boringssl-review.googlesource.com/30084
Reviewed-by: Adam Langley <agl@google.com>
MSan works by instrumenting memory accesses in the compiler. Accesses from
uninstrumented code, such as assembly, are invisible to it. MSan will
incorrectly report reads from assembly-initialized memory as uninitialized.
To avoid confusing downstream consumers with false positives, catch this at
compile-time with a more useful error.
Update-Note: BoringSSL with MSan and assembly doesn't work, but now rather than
crashing at runtime, it will fail to build altogether. It's possible someone
was building BoringSSL with MSan and either not running it at all or just not
exercising the codepaths that break.
Bug: 252
Change-Id: I0c8b0fa3c2d1e584b3f40d532a668a8c9be06cb7
Reviewed-on: https://boringssl-review.googlesource.com/29928
Reviewed-by: Adam Langley <agl@google.com>
There were some subtleties in this one. I'm not sure if TSan covers it all, but
it's better than nothing.
Change-Id: I239e3aee2fea84caa2e48f555d08c6d89f430402
Reviewed-on: https://boringssl-review.googlesource.com/29927
Reviewed-by: Adam Langley <agl@google.com>
Otherwise, if the output BIGNUM was previously negative, we'd incorrectly give
a negative result. Thanks to Guide Vranken for reporting this issue!
Fortunately, this does not appear to come up in any existing caller. This isn't
all that surprising as negative numbers never really come up in cryptography.
Were it not for OpenSSL historically designing a calculator API, we'd just
delete the bit altogether. :-(
Bug: chromium:865924
Change-Id: I28fdc986dfaba3e38435b14ebf07453d537cc60a
Reviewed-on: https://boringssl-review.googlesource.com/29944
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>
In particular, although CertificateRequest comes before Certificate and
CertificateVerify in TLS 1.3, we must not resolve the CertificateRequest until
afterwards. (This is rather annoying ordering, but does mean the
CertificateRequest is covered in the signature, which is nice to have.)
Change-Id: Iab95813de5efd674aa8e2459cfc7456b146ee754
Reviewed-on: https://boringssl-review.googlesource.com/29826
Reviewed-by: Jesse Selover <jselover@google.com>
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>
Modern fuzz testers are very effective and we wish to use them to ensure that no silly bugs creep into BoringSSL.
We primarily use Clang's [libFuzzer](http://llvm.org/docs/LibFuzzer.html) for fuzz testing and there are a number of fuzz testing functions in `fuzz/`. They are not built by default because they require libFuzzer at build time.
We use Clang's [libFuzzer](http://llvm.org/docs/LibFuzzer.html) for fuzz testing and there are a number of fuzz testing functions in `fuzz/`. They are not built by default because they require that the rest of BoringSSL be built with some changes that make fuzzing much more effective, but are completely unsafe for real use.
In order to build the fuzz tests you will need at least Clang 3.7. Pass `-DFUZZ=1` on the CMake command line to enable building BoringSSL with coverage and AddressSanitizer, and to build the fuzz test binaries. You'll probably need to set the `CC` and `CXX` environment variables too, like this:
In order to build the fuzz tests you will need at least Clang 6.0. Pass `-DFUZZ=1` on the CMake command line to enable building BoringSSL with coverage and AddressSanitizer, and to build the fuzz test binaries. You'll probably need to set the `CC` and `CXX` environment variables too, like this:
```
mkdir build
cd build
CC=clang CXX=clang++ cmake -GNinja -DFUZZ=1 ..
ninja
```
In order for the fuzz tests to link, the linker needs to find libFuzzer. This is not commonly provided and you may need to download the [Clang source code](http://llvm.org/releases/download.html) and do the following:
```
svn co http://llvm.org/svn/llvm-project/llvm/trunk/lib/Fuzzer
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Adam Langley
Nick Harper
David Benjamin
Daniel McArdle
Steven Valdez
Brian Smith
Ilya Tokar
Pete Bentley
Jesko Jochum
Anna Sarai Rosenberg
Steven Valdez
Adam Langley
Wiktor Garbacz
Yannic Bonenberger
Shelley Vohr
Matthew Braithwaite
David Schinazi
Augusto Righetto
Jooyung Han
Gurleen Grewal
Kris Kwiatkowski
David Van Cleve
Alessandro Ghedini
Daniel McArdle
Goutam Tamvada
Zola Bridges
Michel Promonet
Alexei Lozovsky
Manoj Gupta
Gurleen Grewal
Bob Haarman
Peter Collingbourne
Yun Liu
Watson Ladd
Julien Desgats
John Sheu
Christopher Patton
Nitish Sakhawalkar
Jeremy Apthorp
Robert Sloan
Kaustubha Govind
Katrin Leinweber
Jesse Selover
Filippo Valsorda
Alessandro Ghedini
Tom Tan
Raul Tambre
Andrii Shyshkalov
Junghoon Jang
Nir Drucker
armfazh
Aaron Green
Yoshisato Yanagisawa
Joshua Liebow-Feeser
Chris Kennelly
Phillipp Schoppmann
Tom Bridgwater
Michał Janiszewski
Ryan Tseng
Daniel Hirche