AES-GCM should have a 12-byte nonce. However, non-standard nonce sizes
are defined by NIST and, although they are a bad idea, people have used
them because they've confused an IV with an nonce and passed in a
16-byte nonce.
This change adds a test for this.
Change-Id: If1efa1aaa19f0119ad4cab9a02a6417c040f45b2
Also implement it without reference to crypto/asn1 or fake ASN1_INTEGERs and
add a test. Some platform crypto APIs only give back the key size, and not the
encoded signature length. No sense in implementing it twice.
BUG=347404,499653
Change-Id: I9aa27d52674375f8b036e57bb5850f091c9b25dd
Reviewed-on: https://boringssl-review.googlesource.com/5080
Reviewed-by: Adam Langley <agl@google.com>
Platform crypto APIs for PKCS#1 RSA signatures vary between expecting the
caller to prepend the DigestInfo prefix (RSA_sign_raw) and prepending it
internally (RSA_sign). Currently, Chromium implements sign or sign_raw as
appropriate. To avoid needing both variants, the new asynchronous methods will
only expose the higher-level one, sign.
To satisfy ports which previously implemented sign_raw, expose the DigestInfo
prefix as a utility function.
BUG=347404
Change-Id: I04c397b5e9502b2942f6698ecf81662a3c9282e6
Reviewed-on: https://boringssl-review.googlesource.com/4940
Reviewed-by: Adam Langley <agl@google.com>
Also tighten X509_cmp_time to reject more than three fractional
seconds in the time; and to reject trailing garbage after the offset.
CVE-2015-1789
(Imported from upstream's 9bc3665ac9e3c36f7762acd3691e1115d250b030)
Change-Id: I2091b2d1b691c177d58dc7960e2e7eb4c97b1f69
Reviewed-on: https://boringssl-review.googlesource.com/5124
Reviewed-by: Adam Langley <agl@google.com>
If gdb is attached, it's convenient to be able to continue running.
Change-Id: I3bbb2634d05a08f6bad5425f71da2210dbb80cfe
Reviewed-on: https://boringssl-review.googlesource.com/5125
Reviewed-by: Adam Langley <agl@google.com>
Mirrors SSL_SESSION_to_bytes. It avoids having to deal with object-reuse, the
non-size_t length parameter, and trailing data. Both it and the object-reuse
variant back onto an unexposed SSL_SESSION_parse which reads a CBS.
Note that this changes the object reuse story slightly. It's now merely an
optional output pointer that frees its old contents. No d2i_SSL_SESSION
consumer in Google that's built does reuse, much less reuse with the assumption
that the top-level object won't be overridden.
Change-Id: I5cb8522f96909bb222cab0f342423f2dd7814282
Reviewed-on: https://boringssl-review.googlesource.com/5121
Reviewed-by: Adam Langley <agl@google.com>
The binaries for these already have underscores in, best to have the
source files match.
Change-Id: I32a419f32ec7786fe2537d061eb0706a7bc73f4a
Reviewed-on: https://boringssl-review.googlesource.com/5101
Reviewed-by: Adam Langley <agl@google.com>
Per malloc(3):
The UNIX 98 standard requires malloc(), calloc(), and realloc() to set
errno to ENOMEM upon failure. Glibc assumes that this is done (and the
glibc versions of these routines do this); if you use a private malloc
implementation that does not set errno, then certain library routines may
fail without having a reason in errno.
Notably, thread_test otherwise fails an assertion deep in glibc.
Change-Id: Ia2c0ab306987476e7d6570d4bbf04a2641398925
Reviewed-on: https://boringssl-review.googlesource.com/5111
Reviewed-by: Adam Langley <agl@google.com>
BN_copy can fail on malloc failure. The case in crypto/rsa was causing the
malloc tests in all_tests.go to infinite loop.
Change-Id: Id5900512013fba9960444d78a8c056aa4314fb2d
Reviewed-on: https://boringssl-review.googlesource.com/5110
Reviewed-by: Adam Langley <agl@google.com>
When cross-compiling for Windows on a Linux system, the filesystem is
case sensitive and so #includes with uppercase characters cause errors.
Change-Id: I6fe6d677887ce84ba8b2c3136cf2c70998d96e81
Reviewed-on: https://boringssl-review.googlesource.com/5060
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
In doing so, check for malloc failures and use scopers as appropriate.
This should clear rsa_test for use with malloc tests. Also replace the
SetKey macro and exploded RSA keys with a DER RSAPrivateKey structure.
Much less tedious.
Change-Id: I3ce092ef67e7ac2af74f509abbdf84b7f2b6d45d
Reviewed-on: https://boringssl-review.googlesource.com/5043
Reviewed-by: Adam Langley <agl@google.com>
We have need of it internally.
Change-Id: I564af468728b22245e8eab384ea7018b7e88cc86
Reviewed-on: https://boringssl-review.googlesource.com/5022
Reviewed-by: Matt Braithwaite <mab@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Mac wants a stdlib.h. Windows wants a void and doesn't like static const in
array declarations.
Change-Id: If1e8fb141e41200cf8a7348c6918c2f22465f5fe
Reviewed-on: https://boringssl-review.googlesource.com/5030
Reviewed-by: Adam Langley <agl@google.com>
This change makes |CBS_get_any_asn1_element| only handle DER elements.
Another function, |CBS_get_any_ber_asn1_element| is exposed internally
for the cases where we need to process BER data.
Change-Id: I544141a1a3d7913986352a8fd9a6d00b9f282652
Reviewed-on: https://boringssl-review.googlesource.com/4994
Reviewed-by: Adam Langley <agl@google.com>
The documentation for |CBS_get_any_asn1_element| says that
|out_header_len| may be NULL, but in the case of an indefinite-length
element it would be written unconditionally.
Thanks to Doug Hogan for noticing this.
Change-Id: I17609b3465df73d42dd9efd75e783159aa99a59b
Reviewed-on: https://boringssl-review.googlesource.com/4993
Reviewed-by: Adam Langley <agl@google.com>
The client and server both have to decide on behaviour when resuming a
session where the EMS state of the session doesn't match the EMS state
as exchanged in the handshake.
Original handshake
| No Yes
------+--------------------------------------------------------------
|
R | Server: ok [1] Server: abort [3]
e No | Client: ok [2] Client: abort [4]
s |
u |
m |
e |
Yes | Server: don't resume No problem
| Client: abort; server
| shouldn't have resumed
[1] Servers want to accept legacy clients. The draft[5] says that
resumptions SHOULD be rejected so that Triple-Handshake can't be done,
but we'll rather enforce that EMS was used when using tls-unique etc.
[2] The draft[5] says that even the initial handshake should be aborted
if the server doesn't support EMS, but we need to be able to talk to the
world.
[3] This is a very weird case where a client has regressed without
flushing the session cache. Hopefully we can be strict and reject these.
[4] This can happen when a server-farm shares a session cache but
frontends are not all updated at once. If Chrome is strict here then
hopefully we can prevent any servers from existing that will try to
resume an EMS session that they don't understand. OpenSSL appears to be
ok here: https://www.ietf.org/mail-archive/web/tls/current/msg16570.html
[5] https://tools.ietf.org/html/draft-ietf-tls-session-hash-05#section-5.2
BUG=492200
Change-Id: Ie1225a3960d49117b05eefa5a36263d8e556e467
Reviewed-on: https://boringssl-review.googlesource.com/4981
Reviewed-by: Adam Langley <agl@google.com>
This implementation does not prompt for a password. It's just enough
to ensure that the many functions that take a tuple of
|pem_password_cb| and a |void *| to a password work in a reasonable
way when the latter is non-NULL.
Change-Id: Ic6bfc484630c67b5ede25277e14eb3b00c2024f0
Reviewed-on: https://boringssl-review.googlesource.com/4990
Reviewed-by: Adam Langley <agl@google.com>
It would be nice if assert(x) reduced to ((void) x) when NDEBUG was
defined, but it doesn't. Because of this, locally define CHECK, which
does. This avoids warnings with Clang.
Change-Id: I70882741da4984a025bcfaac1969032387f369de
Reviewed-on: https://boringssl-review.googlesource.com/4991
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
bsaes-armv7.S implements bsaes_cbc_encrypt if #if __ARM_MAX_ARCH__ >= 7
but e_aes.c instead used #if __ARM_ARCH >= 7 causing duplicate symbols
for linkers that care about that
Change-Id: I10ad8e24be75fdc03b0670869a53078b0477950b
Reviewed-on: https://boringssl-review.googlesource.com/4943
Reviewed-by: Adam Langley <agl@google.com>
The only flag is EVP_MD_CTX_FLAG_NO_INIT and no good can possibly come of
anyone outside EVP_PKEY_HMAC calling it. (And indeed no one calls it.
EVP_MD_CTX_set_flags has a caller in wpa_supplicant, but it uses
EVP_MD_CTX_FLAG_NON_FIPS_ALLOW which we don't define. The call is guarded by a
pair of ifdefs for some FIPS mode wpa_supplicant.)
Change-Id: I70ab8ffa646f3f75dfa4d37c96b9e82448ff1e40
Reviewed-on: https://boringssl-review.googlesource.com/4971
Reviewed-by: Adam Langley <agl@google.com>
It's never called externally and for good reason; the only flag to set is
EVP_MD_CTX_FLAG_NO_INIT which is an implementation detail of EVP_PKEY_HMAC
(hopefully to be removed eventually). Indeed, only EVP_PKEY_HMAC ever calls
this function. Except there's no need to because the HMAC_CTX has already been
initialized at that point. (And were it not initialized, that call would not
bode well for the poor HMAC_CTX.)
The legacy EVP_PKEY_HMAC API has test coverage and still works after this
change.
Change-Id: I2fb0bede3c24ad1519f9433f957606de15ba86c7
Reviewed-on: https://boringssl-review.googlesource.com/4970
Reviewed-by: Adam Langley <agl@google.com>
Not terribly important given that we already have NIST vectors, but may as
well. These tests come from upstream's
2cfbdd71dde0c3ddf4597eb20cc3e3fb8485fc15.
Change-Id: I4f8dadc7d5d1599d0b75ecdef06f2fc6a5cd8003
Reviewed-on: https://boringssl-review.googlesource.com/4962
Reviewed-by: Adam Langley <agl@google.com>
The SSL_PROTOCOL_METHOD table needs work, but this makes it clearer
exactly what the shared interface between the upper later and TLS/DTLS
is.
BUG=468889
Change-Id: I38931c484aa4ab3f77964d708d38bfd349fac293
Reviewed-on: https://boringssl-review.googlesource.com/4955
Reviewed-by: Adam Langley <agl@google.com>
Enough code fails to check their return codes anyway. We ought to make
it official.
Change-Id: Ie646360fd7073ea943036f5e21bed13df7e1b77a
Reviewed-on: https://boringssl-review.googlesource.com/4954
Reviewed-by: Adam Langley <agl@google.com>
The SHA-2 family has some exceptions, but they're all programmer errors
and should be documented as such. (Are the failure cases even
necessary?)
Change-Id: I00bd0a9450cff78d8caac479817fbd8d3de872b8
Reviewed-on: https://boringssl-review.googlesource.com/4953
Reviewed-by: Adam Langley <agl@google.com>
Use sized integer types rather than unsigned char/int/long. The latter
two are especially a mess as they're both used in lieu of uint32_t.
Sometimes the code just blindly uses unsigned long and sometimes it uses
unsigned int when an LP64 architecture would notice.
Change-Id: I4c5c6aaf82cfe9fe523435588d286726a7c43056
Reviewed-on: https://boringssl-review.googlesource.com/4952
Reviewed-by: Adam Langley <agl@google.com>
At some point we might need to make this defined by the consumer.
BUG=495146
Change-Id: Iedac305f234cb383799a5afc14046cd10fb3256a
Reviewed-on: https://boringssl-review.googlesource.com/4963
Reviewed-by: Adam Langley <agl@google.com>
bn_test's output is meant to be piped to bc, but this got broken somewhat:
- OpenSSL uses uppercase hex rather than BoringSSL's lowercase. bc only accepts
uppercase. Document that this needs some shell pipeline until we replace
them with better tests because this is all ridiculous.
- Some stderr outputs moved to stdout to avoid cluttering stdout. Just remove
them. The operations are fast enough to not need progress.
- To cut down on noise, only write the bc transcript given a command-line flag.
Also remove the -results flag since it's pointless. (It writes only the
results and not the inputs.)
Change-Id: I08f87cac1e03fab461f0dc40b9d4285bd877807d
Reviewed-on: https://boringssl-review.googlesource.com/4896
Reviewed-by: Adam Langley <agl@google.com>
While this isn't really an issue, don't use the a - b comparator pattern since
it doesn't account for overflows. (They'll also break silently if that field
ever becomes unsigned as it should be.)
Change-Id: I613d19df6e4a785efd4cffd46e8b03dbc95b98e2
Reviewed-on: https://boringssl-review.googlesource.com/4890
Reviewed-by: Adam Langley <agl@google.com>
Android needs to be able to read a PKCS#7 blob from a Java
InputStream. This change adds |BIO_read_asn1| which reads a single
ASN.1 object from the start of a BIO without overreading.
Change-Id: I74776e686529c8e58af1c26a4909f9bd4e87b707
If BN_rand is called with |bits| set to 1 and |top| set to 1 then a 1 byte
buffer overflow can occur.
See also upstream's efee575ad464bfb60bf72dcb73f9b51768f4b1a1. But rather than
making |BN_rand| fail, be consistent with the |bits| = 0 case and just don't
set the bits that don't exist. Add tests to ensure the degenerate cases behave.
Change-Id: I5e9fbe6fd8f7f7b2e011a680f2fbe6d7ed4dab65
Reviewed-on: https://boringssl-review.googlesource.com/4893
Reviewed-by: Adam Langley <agl@google.com>
The functions BN_rshift and BN_lshift shift their arguments to the right or
left by a specified number of bits. Unpredicatable results (including
crashes) can occur if a negative number is supplied for the shift value.
Thanks to Mateusz Kocielski (LogicalTrust), Marek Kroemeke and Filip Palian
for discovering and reporting this issue.
(Imported from upstream's 7cc18d8158b5fc2676393d99b51c30c135502107.)
Change-Id: Ib9f5e410a46df3d7f02a61374807fba209612bd3
Reviewed-on: https://boringssl-review.googlesource.com/4892
Reviewed-by: Adam Langley <agl@google.com>
See upstream's 344c271eb339fc2982e9a3584a94e51112d84584. We had the error check
already. But, for consistency with the rest of that function's error paths,
pushing an error on the error queue would be prudent.
Change-Id: I8b702abc679dc94dffa79c19a9b7c3d0adc0638b
Reviewed-on: https://boringssl-review.googlesource.com/4889
Reviewed-by: Adam Langley <agl@google.com>
(obj_dat.h and obj_mac.h are generated from the objects.txt change.)
See upstream's 3c161d081e2d30549e787437d05ffa08122a5114. Also see upstream's
12048657a91b12e499d03ec9ff406b42aba67366 to give zlib a better comment.
Change-Id: I86937f037f8e0f6179ba8072ccd972eca773c7ce
Reviewed-on: https://boringssl-review.googlesource.com/4882
Reviewed-by: Adam Langley <agl@google.com>
Support is spotty enough with compiler/library mismatches, and this doesn't
leak to public headers. It's probably simplest to just have consumers supply
it as a build flag.
BUG=491808
Change-Id: I0576a0514a266ee90d644317ae0f49cdddbafd1d
Reviewed-on: https://boringssl-review.googlesource.com/4880
Reviewed-by: Yoshisato Yanagisawa <yyanagisawa@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
With NO_ASM defined, the recent AEAD changes broke the tests. The
problem is that the generic CBC mode code tests whether in != out and
omits to save the IV, assuming that it'll be able to read the old
ciphertext block.
However, consider the case where out = in - 16:
1 2 3 4
|-------|-------|------|-------|
^ ^
| |
out in
First time around, 1 = decrypt(2) ^ iv and everything is fine, because
the IV was preconfigured. However, the next iteration of the loop sets
2 = decrypt(3) and tries to XOR it with the contents of the previous
ciphertext block… from 2.
Change-Id: Ibabff430704fad246de132b4d6d514f6a0362734
This isn't exhaustive. There are still failures in some tests which probably
ought to get C++'d first.
Change-Id: Iac58df9d98cdfd94603d54374a531b2559df64c3
Reviewed-on: https://boringssl-review.googlesource.com/4795
Reviewed-by: Adam Langley <agl@google.com>
Currently far from passing and I haven't even tried with a leak checker yet.
Also bn_test is slow.
Change-Id: I4fe2783aa5f7897839ca846062ae7e4a367d2469
Reviewed-on: https://boringssl-review.googlesource.com/4794
Reviewed-by: Adam Langley <agl@google.com>
tls1_enc is now SSL_AEAD_CTX_{open,seal}. This starts tidying up a bit
of the record-layer logic. This removes rr->input, as encrypting and
decrypting records no longer refers to various globals. It also removes
wrec altogether. SSL3_RECORD is now only used to maintain state about
the current incoming record. Outgoing records go straight to the write
buffer.
This also removes the outgoing alignment memcpy and simply calls
SSL_AEAD_CTX_seal with the parameters as appropriate. From bssl speed
tests, this seems to be faster on non-ARM and a bit of a wash on ARM.
Later it may be worth recasting these open/seal functions to write into
a CBB (tweaked so it can be malloc-averse), but for now they take an
out/out_len/max_out trio like their EVP_AEAD counterparts.
BUG=468889
Change-Id: Ie9266a818cc053f695d35ef611fd74c5d4def6c3
Reviewed-on: https://boringssl-review.googlesource.com/4792
Reviewed-by: Adam Langley <agl@google.com>
Looks like it was the use in type_check.h that was still causing
problems, not that MSVC doesn't short-circuit #if statements.
Change-Id: I574e8dd463c46b0133a989b221a7bb8861b3eed9
6e1f6456 tried to do this, but MSVC doesn't short-circuit #if
statements. So this change tries having the test be in a different #if.
Change-Id: Id0074770c166a2b7cd9ba2c8cd06245a68b77af8
While the compiler on OS X sets the macros as if it supports C11
atomics, stdatomic.h is actually missing.
Change-Id: Ifecaf1c8df6390e6b994663adedc284d9b8130b7
At this point, none of these functions or macros are used so they can
just be deleted.
Change-Id: I8ed1aae7a252e886864bf43e3096eff2228183cd
Reviewed-on: https://boringssl-review.googlesource.com/4777
Reviewed-by: Adam Langley <agl@google.com>
These ASN.1 macros are the last references to the old-style OpenSSL
locks that remain. The ASN.1 reference count handling was changed in a
previous commit to use |CRYPTO_refcount_*| so these lock references were
unused anyway.
Change-Id: I1b27eef140723050a8e6878a1bea11da3409d0eb
Reviewed-on: https://boringssl-review.googlesource.com/4776
Reviewed-by: Adam Langley <agl@google.com>
|SSL_CTX| and |X509_STORE| have grown their own locks. Several static
locks have been added to hack around not being able to use a
|CRYPTO_once_t| in public headers. Lastly, support for calling
|SSL_CTX_set_generate_session_id| concurrently with active connections
has been removed. No other property of an |SSL_CTX| works like that.
Change-Id: Iff5fe3ee3fdd6ea9c9daee96f850b107ad8a6bca
Reviewed-on: https://boringssl-review.googlesource.com/4775
Reviewed-by: Adam Langley <agl@google.com>
It's no longer needed after the conversion to |CRYPTO_refcount_t|.
Change-Id: Ied129c4c247fcd426745fa016350528b7571aaaa
Reviewed-on: https://boringssl-review.googlesource.com/4774
Reviewed-by: Adam Langley <agl@google.com>
This change converts the reference counts in crypto/ to use
|CRYPTO_refcount_t|. The reference counts in |X509_PKEY| and |X509_INFO|
were never actually used and so were dropped.
Change-Id: I75d572cdac1f8c1083c482e29c9519282d7fd16c
Reviewed-on: https://boringssl-review.googlesource.com/4772
Reviewed-by: Adam Langley <agl@google.com>
OpenSSL has traditionally done reference counting with |int|s and the
|CRYPTO_add| function. Unless a special callback is installed (rare),
this is implemented by doing the reference count operations under a
lock.
This change adds infrastructure for handling reference counts and uses
atomic operations when C11 support is available.
Change-Id: Ia023ce432319efd00f77a7340da27d16ee4b63c3
Reviewed-on: https://boringssl-review.googlesource.com/4771
Reviewed-by: Adam Langley <agl@google.com>
DH groups less than 1024 bits are clearly not very safe. Ideally servers
would switch to ECDHE because 1024 isn't great either, but this will
serve for the short term.
BUG=490240
Change-Id: Ic9aac714cdcdcbfae319b5eb1410675d3b903a69
Reviewed-on: https://boringssl-review.googlesource.com/4813
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
SSLeay is a compatibility function for OpenSSL, but I got it wrong. It
doesn't return a string, it returns a number. This doesn't end up making
any difference, but it fixes a warning when building OpenSSH.
Change-Id: I327ab4f70313c93c18f81d8804ba4acdc3bc1a4a
Reviewed-on: https://boringssl-review.googlesource.com/4811
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
This change import's upstream's beeb0fa7 and fixes a UAF in X509.
Thankfully, this shouldn't impact Chromium, which doesn't use OpenSSL
for certificate verification.
BUG=489764
Change-Id: I0ce2ec05083f7c588ba5504bb12151437dec593e
Reviewed-on: https://boringssl-review.googlesource.com/4810
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
Unlike the standalone build, builds generated from util/generate_build_files.py
do not exclude x86_64-gcc.c. Match the consumer builds by making the standalone
build unconditionally include it. (This would have noticed the missing
preprocessor checks in the file.)
Change-Id: I8d20f269dea63776320ae636ee1e5339cb85fa30
Reviewed-on: https://boringssl-review.googlesource.com/4761
Reviewed-by: Adam Langley <agl@google.com>
Android (on OS X) builds with NO_ASM and was getting both generic.c and
x86_64-gcc.c. This change updates the latter so that it's excluded in
NO_ASM builds.
Change-Id: I1f0e1c5e551eed9c575ce632ec3016fce7ec9d2e
Reviewed-on: https://boringssl-review.googlesource.com/4741
Reviewed-by: Adam Langley <agl@google.com>
We can't actually catch this with MSan because it requires all code be
instrumented, so it needs a NO_ASM build which no disables that code. valgrind
doesn't notice either, possibly because there's some computation being done on
it. Still, we shouldn't use uninitialized memory.
Also get us closer to being instrumentable by MSan, but the runner tests will
need to build against an instrumented STL and I haven't tried that yet.
Change-Id: I2d65697a3269b5b022899f361730a85c51ecaa12
Reviewed-on: https://boringssl-review.googlesource.com/4760
Reviewed-by: Adam Langley <agl@google.com>
This change exposes the functions needed to support arbitrary elliptic
curve groups. The Java API[1] doesn't allow a provider to only provide
certain elliptic curve groups. So if BoringSSL is an ECC provider on
Android, we probably need to support arbitrary groups because someone
out there is going to be using it for Bitcoin I'm sure.
Perhaps in time we can remove this support, but not yet.
[1] https://docs.oracle.com/javase/7/docs/api/java/security/spec/ECParameterSpec.html
Change-Id: Ic1d76de96f913c9ca33c46b451cddc08c5b93d80
Reviewed-on: https://boringssl-review.googlesource.com/4740
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
Derived from upstream's new evp_test. The tests were taken from upstream
but tweaked so the diff from the old cipher_test.txt is more obvious.
Change-Id: Ic82593a8bb6aaee9b69fdc42a8b75516b03c1c5a
Reviewed-on: https://boringssl-review.googlesource.com/4707
Reviewed-by: Adam Langley <agl@google.com>
The generic RC4 implementation may read and write just past the end of the
buffer; when input and output are aligned, it always reads an RC4_CHUNK at a
time. It appropriately masks off and preserves the excess bytes off the end, so
this can only have practical effects if it crosses a page boundary. There's an
alignment check, so that can't happen; page boundaries are always aligned. But
it makes ASan unhappy and strictly speaking is a memory error.
Instead, fall through to the generic codepath which just reads it byte by byte.
This should fix the other bot failure.
Change-Id: I3cbd3bfc6cb0537e87f3252dea12d40ffa78d590
Reviewed-on: https://boringssl-review.googlesource.com/4722
Reviewed-by: Adam Langley <agl@google.com>
As with CRYPTO_ctr128_encrypt_ctr32, NULL in and out are legal in the
degenerate case when len is 0. This fixes one of the two failures on the bots.
Change-Id: If6016dfc3963d9c06c849fc8eba9908556f66666
Reviewed-on: https://boringssl-review.googlesource.com/4721
Reviewed-by: Adam Langley <agl@google.com>
Change-Id: I3002d95d2b9db4dd05e1c56ef6ae410315b97ab9
Reviewed-on: https://boringssl-review.googlesource.com/4710
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
This change makes it safe to call EVP_AEAD_CTX_cleanup after a failed
EVP_AEAD_CTX_init.
Change-Id: I608ed550e08d638cd7e941f5067edd3da4c850ab
Reviewed-on: https://boringssl-review.googlesource.com/4692
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
(The huge if-else was hard to visually parse.)
Change-Id: Ic2c94120f345085b619304181e861f662a931a29
Reviewed-on: https://boringssl-review.googlesource.com/4691
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
This imports the EVP_PKEY test data of upstream's evptests.txt, but
modified to fit our test framework and with a new test driver. The
remainder of the test data will be imported separately into aead_test
and cipher_test.
Some minor changes to the test format were made to account for test
framework differences. One test has different results since we don't
support RSA signatures with omitted (rather than NULL) parameters.
Otherwise, the biggest difference in test format is that the ad-hoc
result strings are replaced with checking ERR_peek_error.
Change-Id: I758869abbeb843f5f2ac6c1cbd87333baec08ec3
Reviewed-on: https://boringssl-review.googlesource.com/4703
Reviewed-by: Adam Langley <agl@google.com>
This matches how upstream imported that test. evp_test will be used for
the subset of upstream's evp_test which land in our crypto/evp layer.
(Some of crypto/evp is in crypto/cipher for us, so those tests will be
in a ported cipher_test.)
Change-Id: Ic899442794b66350e73a706bb7c77a6ff3d2564b
Reviewed-on: https://boringssl-review.googlesource.com/4702
Reviewed-by: Adam Langley <agl@google.com>
This adds a file-based test framework to crypto/test. It knows how to
parse formats similar to either upstream's evp_test and our aead_test.
hmac_test has been converted to that with tests from upstream's
evp_test. Upstream tests it against the deprecated EVP_PKEY_HMAC API,
which will be tested by running evp_test against the same input file, to
avoid having to duplicate the test vectors. hmac_test runs those same
inputs against the supported HMAC_CTX APIs.
Change-Id: I9d2b6adb9be519760d1db282b9d43efd6f9adffb
Reviewed-on: https://boringssl-review.googlesource.com/4701
Reviewed-by: Adam Langley <agl@google.com>
NULL in and out are legal in the degenerate case when len is 0.
Change-Id: Ibf0600a4f635a03103b1ae914918fdcf23a75a39
Reviewed-on: https://boringssl-review.googlesource.com/4705
Reviewed-by: Adam Langley <agl@google.com>
Like the non-stitched variant, this "AEAD" uses the output buffer as
scratch space for the MAC. Thus it should require that max_out_len is
large enough to fit that, even though it will never return that large of
input.
Change-Id: I5b30b0756408c2e433448f540e7c65251336d2f8
Reviewed-on: https://boringssl-review.googlesource.com/4704
Reviewed-by: Adam Langley <agl@google.com>
inttypes.h kindly requires a feature macro in C++ on some platforms, due
to a bizarre footnote in C99 (see footnote 191 in section 7.8.1). As
bn.h is a public header, we must leak this wart to the consumer. On
platforms with unfriendly inttypes.h headers, using BN_DEC_FMT1 and
friends now require the feature macro be defined externally.
This broke the Chromium Android Clang builder:
http://build.chromium.org/p/chromium.linux/builders/Android%20Clang%20Builder%20%28dbg%29/builds/59288
Change-Id: I88275a6788c7babd0eae32cae86f115bfa93a591
Reviewed-on: https://boringssl-review.googlesource.com/4688
Reviewed-by: Adam Langley <agl@google.com>
Change |EC_KEY_new_by_curve_name| to report |ERR_R_MALLOC_FAILURE|
itself, so that reporting of |EC_R_UNKNOWN_GROUP| is not confused by
the caller's addition of a spurious |ERR_R_MALLOC_FAILURE|.
Change-Id: Id3f5364f01eb8e3597bcddd6484bc03d5578befb
Reviewed-on: https://boringssl-review.googlesource.com/4690
Reviewed-by: Adam Langley <agl@google.com>
Trusty doesn't have setjmp.h and nor does it have threads.
Change-Id: I005f7a009a13e6632513be9fab2bbe62294519a4
Reviewed-on: https://boringssl-review.googlesource.com/4660
Reviewed-by: Adam Langley <agl@google.com>
This is used with a platform API, so it should use the corresponding
platform type, saving us the size assert. It's ever defined in an
internal header, so we can freely use windows.h and friends.
Change-Id: Idc979309436adcf54524c835ddc2c98c3870d2e2
Reviewed-on: https://boringssl-review.googlesource.com/4680
Reviewed-by: Adam Langley <agl@google.com>
The interface for this is very similar to upstream, but the code is
quite different.
Support for “resuming” (i.e. calling |CMAC_Final| and then computing the
CMAC for an extension of the message) has been dropped. Also, calling
|CMAC_Init| with magic argument to reset it has been replaced with
|CMAC_Reset|.
Lastly, a one-shot function has been added because it can save an
allocation and that's what most callers actually appear to want to do.
Change-Id: I9345220218bdb16ebe6ca356928d7c6f055d83f6
Reviewed-on: https://boringssl-review.googlesource.com/4630
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
This reverts commit 68de407b5f. The NaCl fix has
rolled into Chromium.
Change-Id: I9fd6a6ae727c95fa89b8ce27e301f2a748d0acc9
Reviewed-on: https://boringssl-review.googlesource.com/4651
Reviewed-by: Adam Langley <agl@google.com>
The only place using it is export keying material which can do the
version check inline.
Change-Id: I1893966c130aa43fa97a6116d91bb8b04f80c6fb
Reviewed-on: https://boringssl-review.googlesource.com/4615
Reviewed-by: Adam Langley <agl@google.com>
It's only called for client certificates with NULL. The interaction with
extra_certs is more obvious if we handle that case externally. (We
shouldn't attach extra_certs if there is no leaf.)
Change-Id: I9dc26f32f582be8c48a4da9aae0ceee8741813dc
Reviewed-on: https://boringssl-review.googlesource.com/4613
Reviewed-by: Adam Langley <agl@google.com>
Or rather fix in so far as that call will always fail now, rather than
mix up EC and DH EVP_PKEY. We don't implement EVP_PKEY_DH.
Change-Id: I752978f3440b59d963b5c13f2349284d7d799182
Reviewed-on: https://boringssl-review.googlesource.com/4567
Reviewed-by: Adam Langley <agl@google.com>
Document them while I'm here. This adds a new 'preprocessor
compatibility section' to avoid breaking #ifdefs. The CTRL values
themselves are defined to 'doesnt_exist' to catch anything calling
SSL_ctrl directly until that function can be unexported completely.
BUG=404754
Change-Id: Ia157490ea8efe0215d4079556a0c7643273e7601
Reviewed-on: https://boringssl-review.googlesource.com/4553
Reviewed-by: Adam Langley <agl@google.com>
This avoids callers having to worry about |CRYPTO_add| and what the
correct lock to use it with is. (Esp since we'll probably change the way
that reference counts work in the future.)
Change-Id: I972bf0cc3be6099e0255e64a0fd50249062d1eb4
Reviewed-on: https://boringssl-review.googlesource.com/4623
Reviewed-by: Adam Langley <agl@google.com>
BoringSSL always uses uncompressed points. This function aborts if
another form is requested or does nothing if uncompressed points are
requested.
Change-Id: I80bc01444cdf9c789c9c75312b5527bf4957361b
I think these two things were written at the same time and so the
AES-CTR-HMAC AEADs never explicitly set these values.
Change-Id: I0a142ad2b0fb9e893e290c1def5e5c6b193a3cc8
I tried so hard to get rid of AES-192, but it's called from too many
places. I suspect that those places don't actually use it, but it's
dangerous to assume that.
Change-Id: I6208b64a463e3539973532abd21882e0e4c55a1c
Previously I've been using the Linaro toolchains and just building
static binaries. However, the Linaro toolchains have a broken
pthread_rwlock_wrlock—it does nothing and then unlocking corrupts the
lock.
Building with the Android NDK avoids this.
These build instructions depend on
https://github.com/taka-no-me/android-cmake which people will need to
clone into util/ if they want to use the Android NDK.
Change-Id: Ic64919f9399af2a57e8df4fb4b3400865ddb2427
Reviewed-on: https://boringssl-review.googlesource.com/4600
Reviewed-by: Adam Langley <agl@google.com>
Android uses BIO reference counting.
This reverts commit 9bde6aeb76.
Change-Id: Ibf4a7f42477549d10829a424ea3b52f09098666c
Reviewed-on: https://boringssl-review.googlesource.com/4472
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
Clang (3.6, at least) doesn't like .arch when its internal as is used.
Instead, one has to pass -march=armv8-a+crypto on the command line.
Change-Id: Ifc5b57fbebd0eb53658481b0a0c111e808c81d93
Reviewed-on: https://boringssl-review.googlesource.com/4411
Reviewed-by: Adam Langley <agl@google.com>
The immediate in this operation is too large for ARM. GCC will
automatically rewrite it to use bic (where bic does an AND NOT). Clang,
however doesn't, and reasonably throws an error.
This change switches to using bic in the source file, thus making both
happy.
Change-Id: I958fa29b88bffeab20c6ee11660736222a2e6986
Reviewed-on: https://boringssl-review.googlesource.com/4410
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
These functions were #if 0'ed out in the code, which is a distraction.
Change-Id: I186196ab512565507476f9b56682bf59d003d85f
Reviewed-on: https://boringssl-review.googlesource.com/4604
Reviewed-by: Adam Langley <agl@google.com>
Finish up crypto, minus the legacy modules we haven't been touching much.
Change-Id: I0e9e1999a627aed5fb14841f8a2a7d0b68398e85
Reviewed-on: https://boringssl-review.googlesource.com/4517
Reviewed-by: Adam Langley <agl@google.com>
First batch of the alphabet.
Change-Id: If4e60f4fbb69e04eb4b70aa1b2240e329251bfa5
Reviewed-on: https://boringssl-review.googlesource.com/4514
Reviewed-by: Adam Langley <agl@google.com>
This is consistent with C's free function and upstream's convention.
Change-Id: I83f6e2f5824e28f69a9916e580dc2d8cb3b94234
Reviewed-on: https://boringssl-review.googlesource.com/4512
Reviewed-by: Adam Langley <agl@google.com>
While *pval is usually a pointer in rare circumstances it can be a long
value. One some platforms (e.g. WIN64) where
sizeof(long) < sizeof(ASN1_VALUE *) this will write past the field.
*pval is initialised correctly in the rest of ASN1_item_ex_new so setting it
to NULL is unecessary anyway.
Thanks to Julien Kauffmann for reporting this issue.
(Imported from upstream's f617b4969a9261b9d7d381670aefbe2cf766a2cb.)
Change-Id: I8cc777f7ab126dcef3a0278a82d3fc91faf4c231
Reviewed-on: https://boringssl-review.googlesource.com/4510
Reviewed-by: Adam Langley <agl@google.com>
This addresses
- request for improvement for faster key setup in RT#3576;
- clearing registers and stack in RT#3554 (this is more of a gesture to
see if there will be some traction from compiler side);
- more commentary around input parameters handling and stack layout
(desired when RT#3553 was reviewed);
- minor size and single block performance optimization (was lying around);
(Imported from upstream's 23f6eec71dbd472044db7dc854599f1de14a1f48)
This one is best reviewed by verifying that
23f6eec71dbd472044db7dc854599f1de14a1f48^ in upstream has the exact same
versions of these files (we had no local diffs), so we can just copy them
wholesale.
bssl speed reports a wash on my Mac. If I keep running it, different ones win
each time.
Change-Id: I729bd39cf0b3a30cc24de839e1c734dcaef972b8
Reviewed-on: https://boringssl-review.googlesource.com/4491
Reviewed-by: Adam Langley <agl@google.com>
XTS bug spotted and fix suggested by Adrian Kotelba.
(Imported from upstream's e620e5ae37bc3fc5e457ebf3edcdd01b20f8c5dd.)
Another patch we missed.
Change-Id: Ibea40eeec01a49b29064b14631706756795c9592
Reviewed-on: https://boringssl-review.googlesource.com/4489
Reviewed-by: Adam Langley <agl@google.com>
This facilitates "universal" builds, ones that target multiple
architectures, e.g. ARMv5 through ARMv7.
(Imported from upstream's c1669e1c205dc8e695fb0c10a655f434e758b9f7)
This is a change from a while ago which was a source of divergence between our
perlasm and upstream's. This change in upstream came with the following comment
in Configure:
Note that -march is not among compiler options in below linux-armv4
target line. Not specifying one is intentional to give you choice to:
a) rely on your compiler default by not specifying one;
b) specify your target platform explicitly for optimal performance,
e.g. -march=armv6 or -march=armv7-a;
c) build "universal" binary that targets *range* of platforms by
specifying minimum and maximum supported architecture;
As for c) option. It actually makes no sense to specify maximum to be
less than ARMv7, because it's the least requirement for run-time
switch between platform-specific code paths. And without run-time
switch performance would be equivalent to one for minimum. Secondly,
there are some natural limitations that you'd have to accept and
respect. Most notably you can *not* build "universal" binary for
big-endian platform. This is because ARMv7 processor always picks
instructions in little-endian order. Another similar limitation is
that -mthumb can't "cross" -march=armv6t2 boundary, because that's
where it became Thumb-2. Well, this limitation is a bit artificial,
because it's not really impossible, but it's deemed too tricky to
support. And of course you have to be sure that your binutils are
actually up to the task of handling maximum target platform.
Change-Id: Ie5f674d603393f0a1354a0d0973987484a4a650c
Reviewed-on: https://boringssl-review.googlesource.com/4488
Reviewed-by: Adam Langley <agl@google.com>
Pointer out and suggested by: Ard Biesheuvel.
(Imported from upstream's 5dcf70a1c57c2019bfad640fe14fd4a73212860a)
This is from a while ago, but it's one source of divergence between our copy of
these files and master's.
Change-Id: I6525a27f25eb86a92420c32996af47ecc42ee020
Reviewed-on: https://boringssl-review.googlesource.com/4487
Reviewed-by: Adam Langley <agl@google.com>
(Imported from upstream's 7eeeb49e1103533bc81c234eb19613353866e474)
Here are the performance numbers on a Nexus 9 (32-bit binary):
Before:
Did 4376000 AES-128-GCM (16 bytes) seal operations in 1000016us (4375930.0 ops/sec): 70.0 MB/s
Did 642000 AES-128-GCM (1350 bytes) seal operations in 1001090us (641301.0 ops/sec): 865.8 MB/s
Did 126000 AES-128-GCM (8192 bytes) seal operations in 1001460us (125816.3 ops/sec): 1030.7 MB/s
Did 4120000 AES-256-GCM (16 bytes) seal operations in 1000004us (4119983.5 ops/sec): 65.9 MB/s
Did 547000 AES-256-GCM (1350 bytes) seal operations in 1001165us (546363.5 ops/sec): 737.6 MB/s
Did 99000 AES-256-GCM (8192 bytes) seal operations in 1000027us (98997.3 ops/sec): 811.0 MB/s
After:
Did 4569000 AES-128-GCM (16 bytes) seal operations in 1000011us (4568949.7 ops/sec): 73.1 MB/s
Did 796000 AES-128-GCM (1350 bytes) seal operations in 1000161us (795871.9 ops/sec): 1074.4 MB/s
Did 162000 AES-128-GCM (8192 bytes) seal operations in 1003828us (161382.2 ops/sec): 1322.0 MB/s
Did 4398000 AES-256-GCM (16 bytes) seal operations in 1000001us (4397995.6 ops/sec): 70.4 MB/s
Did 634000 AES-256-GCM (1350 bytes) seal operations in 1001290us (633183.2 ops/sec): 854.8 MB/s
Did 122000 AES-256-GCM (8192 bytes) seal operations in 1005650us (121314.6 ops/sec): 993.8 MB/s
Change-Id: I2fef921069ad174f5651dfe59be262625fb3f7c9
Reviewed-on: https://boringssl-review.googlesource.com/4483
Reviewed-by: Adam Langley <agl@google.com>
ARM has optimized Cortex-A5x pipeline to favour pairs of complementary
AES instructions. While modified code improves performance of post-r0p0
Cortex-A53 performance by >40% (for CBC decrypt and CTR), it hurts
original r0p0. We favour later revisions, because one can't prevent
future from coming. Improvement on post-r0p0 Cortex-A57 exceeds 50%,
while new code is not slower on r0p0, or Apple A7 for that matter.
[Update even SHA results for latest Cortex-A53.]
(Imported from upstream's 94376cccb4ed5b376220bffe0739140ea9dad8c8)
Change-Id: I581c65b566116b1f4211fb1bd5a1a54479889d70
Reviewed-on: https://boringssl-review.googlesource.com/4481
Reviewed-by: Adam Langley <agl@google.com>
(Imported from upstream's 7b644df899d0c818488686affc0bfe2dfdd0d0c2)
Looking at update_gypi_and_asm.py with git diff -w, the only differences seem
to be that .asciz fixed a bug where a space after a ',' got swallowed (sigh).
BUG=338886
Change-Id: Ib52296f4a62bc6f892a0d4ee7367493a8c639a3b
Reviewed-on: https://boringssl-review.googlesource.com/4480
Reviewed-by: Adam Langley <agl@google.com>
MSVC seems to dislike the zero-array trick in C++, but not C. Turns out there
was no need for the include, so that's an easy fix.
Change-Id: I6def7b430a450c4ff7eeafa3611f0d40f5fc5945
Reviewed-on: https://boringssl-review.googlesource.com/4580
Reviewed-by: Adam Langley <agl@google.com>
RFC 5915 requires the use of the I2OSP primitive as defined in RFC 3447
for encoding ECPrivateKey. Fix this and add a test.
See also upstream's 30cd4ff294252c4b6a4b69cbef6a5b4117705d22, though it mixes
up degree and order.
Change-Id: I81ba14da3c8d69e3799422c669fab7f16956f322
Reviewed-on: https://boringssl-review.googlesource.com/4469
Reviewed-by: Adam Langley <agl@google.com>
Follow-up to sha256-armv4.pl in cooperation with Ard Biesheuvel
(Linaro) and Sami Tolvanen (Google).
(Imported from upstream's b1a5d1c652086257930a1f62ae51c9cdee654b2c.)
Change-Id: Ibc4f289cc8f499924ade8d6b8d494f53bc08bda7
Reviewed-on: https://boringssl-review.googlesource.com/4467
Reviewed-by: Adam Langley <agl@google.com>
(Imported from upstream's 51f8d095562f36cdaa6893597b5c609e943b0565.)
I don't see why we'd care, but just to minimize divergence.
Change-Id: I4b07e72c88fcb04654ad28d8fd371e13d59a61b5
Reviewed-on: https://boringssl-review.googlesource.com/4466
Reviewed-by: Adam Langley <agl@google.com>
In cooperation with Ard Biesheuvel (Linaro) and Sami Tolvanen (Google).
(Imported from upstream's 2ecd32a1f8f0643ae7b38f59bbaf9f0d6ef326fe)
Change-Id: Iac5853220654b6ef4cb3bb7f8d1efe0eb2ecf634
Reviewed-on: https://boringssl-review.googlesource.com/4463
Reviewed-by: Adam Langley <agl@google.com>
The 2 arg OpenSSL sk_find() returned -1 on error and >= 0 on
success. BoringSSL's 3 arg sk_find() returns -1 if the sk argument
is NULL, 0 if the item is not found, and 1 if found.
In practice, all callers of the sk_find() macros in BoringSSL only
check for zero/non-zero. If sk is ever NULL, it looks like most
callers are going to use uninitialized data as the index because
the return value check is insufficient.
Change-Id: I640089a0f4044aaa8d50178b2aecd9c3c1fe2f9c
Reviewed-on: https://boringssl-review.googlesource.com/4500
Reviewed-by: Adam Langley <agl@google.com>
See upstream's a0eed48d37a4b7beea0c966caf09ad46f4a92a44. Rather than import
that, we should just ensure neg + zero isn't a possible state.
Add some tests for asc2bn and dec2bn while we're here. Also fix a bug with
dec2bn where it doesn't actually ignore trailing data as it's supposed to.
Change-Id: I2385b67b740e57020c75a247bee254085ab7ce15
Reviewed-on: https://boringssl-review.googlesource.com/4484
Reviewed-by: Adam Langley <agl@google.com>
arm-xlate.pl conditions some things on the flavour matching /linux/. This
change will need to be mirrored in update_gypi_and_asm.py.
Change-Id: I60483aaf40fd13181173373f12f6d3651a2a8a0c
Reviewed-on: https://boringssl-review.googlesource.com/4460
Reviewed-by: Adam Langley <agl@google.com>
This is as partial import of upstream's
9b05cbc33e7895ed033b1119e300782d9e0cf23c. It includes the perlasm changes, but
not the CPU feature detection bits as we do those differently. This is largely
so we don't diverge from upstream, but it'll help with iOS assembly in the
future.
sha512-armv8.pl is modified slightly from upstream to switch from conditioning
on the output file to conditioning on an extra argument. This makes our
previous change from upstream (removing the 'open STDOUT' line) more explicit.
BUG=338886
Change-Id: Ic8ca1388ae20e94566f475bad3464ccc73f445df
Reviewed-on: https://boringssl-review.googlesource.com/4405
Reviewed-by: Adam Langley <agl@google.com>
CRYPTO_MUTEX was the wrong size. Fortunately, Apple was kind enough to define
pthread_rwlock_t unconditionally, so we can be spared fighting with feature
macros. Some of the stdlib.h removals were wrong and clang is pick about
multiply-defined typedefs. Apparently that's a C11 thing?
BUG=478598
Change-Id: Ibdcb8de9e5d83ca28e4c55b2979177d1ef0f9721
Reviewed-on: https://boringssl-review.googlesource.com/4404
Reviewed-by: Adam Langley <agl@google.com>
This is taken from upstream, although it originally came from us. This
will only take effect on 64-bit systems (x86-64 and aarch64).
Before:
Did 1496 ECDH P-256 operations in 1038743us (1440.2 ops/sec)
Did 2783 ECDSA P-256 signing operations in 1081006us (2574.5 ops/sec)
Did 2400 ECDSA P-256 verify operations in 1059508us (2265.2 ops/sec)
After:
Did 4147 ECDH P-256 operations in 1061723us (3905.9 ops/sec)
Did 9372 ECDSA P-256 signing operations in 1040589us (9006.4 ops/sec)
Did 4114 ECDSA P-256 verify operations in 1063478us (3868.4 ops/sec)
Change-Id: I11fabb03239cc3a7c4a97325ed4e4c97421f91a9
We don't support the SSL BIO so this is a no-op change.
Change-Id: Iba9522b837ebb0eb6adc80d5df6dcac99abf2552
Reviewed-on: https://boringssl-review.googlesource.com/4360
Reviewed-by: Adam Langley <agl@google.com>
Instead, each module defines a static CRYPTO_EX_DATA_CLASS to hold the values.
This makes CRYPTO_cleanup_all_ex_data a no-op as spreading the
CRYPTO_EX_DATA_CLASSes across modules (and across crypto and ssl) makes cleanup
slightly trickier. We can make it do something if needbe, but it's probably not
worth the trouble.
Change-Id: Ib6f6fd39a51d8ba88649f0fa29c66db540610c76
Reviewed-on: https://boringssl-review.googlesource.com/4375
Reviewed-by: Adam Langley <agl@google.com>
No functions for using it were ever added.
Change-Id: Iaee6e5bc8254a740435ccdcdbd715b851d8a0dce
Reviewed-on: https://boringssl-review.googlesource.com/4374
Reviewed-by: Adam Langley <agl@google.com>
No wrappers were ever added and codesearch confirms no one ever added to it
manually. Probably anyone doing complex things with BIOs just made a custom
BIO_METHOD. We can put it back with proper functions if the need ever arises.
Change-Id: Icb5da7ceeb8f1da6d08f4a8854d53dfa75827d9c
Reviewed-on: https://boringssl-review.googlesource.com/4373
Reviewed-by: Adam Langley <agl@google.com>
Callers are required to use the wrappers now. They still need OPENSSL_EXPORT
since crypto and ssl get built separately in the standalone shared library
build.
Change-Id: I61186964e6099b9b589c4cd45b8314dcb2210c89
Reviewed-on: https://boringssl-review.googlesource.com/4372
Reviewed-by: Adam Langley <agl@google.com>
It's unused and requires ex_data support a class number per type.
Change-Id: Ie1fb55053631ef00c3318f3253f7c9501988f522
Reviewed-on: https://boringssl-review.googlesource.com/4371
Reviewed-by: Adam Langley <agl@google.com>
This is never used and we can make the built-in one performant.
Change-Id: I6fc7639ba852349933789e73762bc3fa1341b2ff
Reviewed-on: https://boringssl-review.googlesource.com/4370
Reviewed-by: Adam Langley <agl@google.com>
This one really needs to get C++'d.
Change-Id: I088f3b77867af0cfc2da8324ba87954ef4cbba74
Reviewed-on: https://boringssl-review.googlesource.com/4350
Reviewed-by: Adam Langley <agl@google.com>
MSVC doesn't like |const size_t len| in a function definition where the
declaration was just |size_t len| without the |const|. Also, MSVC needs
declarations of parameterless functions to have a |void| parameter list.
Change-Id: I91e01a12aca657b2ee1d653926f09cc52da2faed
Reviewed-on: https://boringssl-review.googlesource.com/4329
Reviewed-by: Adam Langley <agl@google.com>
OpenSSH, especially, does some terrible things that mean that it needs
the EVP_CIPHER structure to be exposed ☹. Damian is open to a better API
to replace this, but only if OpenSSL agree too. Either way, it won't be
happening soon.
Change-Id: I393b7a6af6694d4d2fe9ebcccd40286eff4029bd
Reviewed-on: https://boringssl-review.googlesource.com/4330
Reviewed-by: Adam Langley <agl@google.com>
This introduces a per-RSA/DSA/DH lock. This is good for lock contention,
although pthread locks are depressingly bloated.
Change-Id: I07c4d1606fc35135fc141ebe6ba904a28c8f8a0c
Reviewed-on: https://boringssl-review.googlesource.com/4324
Reviewed-by: Adam Langley <agl@google.com>
Prior to this, BoringSSL was using OpenSSL's technique of having users
register a callback for locking operation. This change adds native mutex
support.
Since mutexes often need to be in objects that are exposed via public
headers, the non-static mutexes are defined in thread.h. However, on
Windows we don't want to #include windows.h for CRITICAL_SECTION and, on
Linux, pthread.h doesn't define pthread_rwlock_t unless the feature
flags are set correctly—something that we can't control in general
for public header files. Thus, on both platforms, the mutex is defined
as a uint8_t[] of equal or greater size and we depend on static asserts
to ensure that everything works out ok.
Change-Id: Iafec17ae7e3422325e587878a5384107ec6647ab
Reviewed-on: https://boringssl-review.googlesource.com/4321
Reviewed-by: Adam Langley <agl@google.com>
It appears that this reference “count” is set to one at creation and
never touched after that.
Change-Id: I3238a6d3dd702953771b8ec725c1c5712c648fba
Reviewed-on: https://boringssl-review.googlesource.com/4320
Reviewed-by: Adam Langley <agl@google.com>
Avoiding superflous references to MD5 makes it easier to audit the code
to find unsafe uses of it. It also avoids subtly encouraging users to
choose MD5 instead of a better alternative.
Change-Id: Ic78eb5dfbf44aac39e4e4eb29050e3337c4445cc
Reviewed-on: https://boringssl-review.googlesource.com/3926
Reviewed-by: Adam Langley <agl@google.com>
Beyond generally eliminating unnecessary includes, eliminate as many
includes of headers that declare/define particularly error-prone
functionality like strlen, malloc, and free. crypto/err/internal.h was
added to remove the dependency on openssl/thread.h from the public
openssl/err.h header. The include of <stdlib.h> in openssl/mem.h was
retained since it defines OPENSSL_malloc and friends as macros around
the stdlib.h functions. The public x509.h, x509v3.h, and ssl.h headers
were not changed in order to minimize breakage of source compatibility
with external code.
Change-Id: I0d264b73ad0a720587774430b2ab8f8275960329
Reviewed-on: https://boringssl-review.googlesource.com/4220
Reviewed-by: Adam Langley <agl@google.com>
C4701 is "potentially uninitialized local variable 'buf' used". It
sometimes results in false positives, which can now be suppressed
using the macro OPENSSL_SUPPRESS_POTENTIALLY_UNINITIALIZED_WARNINGS.
Change-Id: I15068b5a48e1c704702e7752982b9ead855e7633
Reviewed-on: https://boringssl-review.googlesource.com/3160
Reviewed-by: Adam Langley <agl@google.com>
`cmake -GNinja .. -DCMAKE_BUILD_TYPE=Release` fails without this
patch, when building using MSVC 2013.
MSVC will detect (in release builds only, it seems) that functions that
call abort will never return, and then warn that any code after a call
to one of them is unreachable. Since we treat warnings as errors when
building, this breaks the build. While this is usually desirable, it
isn't desirable in this case.
Change-Id: Ie5f24b1beb60fd2b33582a2ceef4c378ad0678fb
Reviewed-on: https://boringssl-review.googlesource.com/3960
Reviewed-by: Adam Langley <agl@google.com>
The only dependency the low-level crypto modules have on code in
crypto/obj is their use of OBJ_nid2sn, which is trivial to avoid.
This facilitates future simplification of crypto/obj, including
possibly the removal of functions like OBJ_nid2sn and the complex
build infrastructure that supports them.
This change also removes EVP_CIPHER_name and EVP_MD_name.
Change-Id: I34ce7dc7e58d5c08b52f95d25eba3963590cf2f7
Reviewed-on: https://boringssl-review.googlesource.com/3932
Reviewed-by: Adam Langley <agl@google.com>
Limiting uses of crypto/bio to code that really need to it by avoiding
the use of BIO just to write to stdout/stderr.
Change-Id: I34e0f773161aeec073691e439ac353fb7b1785f3
Reviewed-on: https://boringssl-review.googlesource.com/3930
Reviewed-by: Adam Langley <agl@google.com>
A previous change in BoringSSL renamed ERR_print_errors_fp to
BIO_print_errors_fp as part of refactoring the code to improve the
layering of modules within BoringSSL. Rename it back for better
compatibility with code that was using the function under the original
name. Move its definition back to crypto/err using an implementation
that avoids depending on crypto/bio.
Change-Id: Iee7703bb1eb4a3d640aff6485712bea71d7c1052
Reviewed-on: https://boringssl-review.googlesource.com/4310
Reviewed-by: Adam Langley <agl@google.com>
Avoiding superflous references to RC4 makes it easier to audit the code
to find unsafe uses of it. It also avoids subtly encouraging users to
choose RC4 instead of a better alternative.
Change-Id: Ia27d7f4cd465e143d30a28b36c7871f7c30411ea
Reviewed-on: https://boringssl-review.googlesource.com/3990
Reviewed-by: Adam Langley <agl@google.com>
Prior to this change, when EC_GROUP_get0_generator fails, BN_CTX_end
would get called even though BN_CTX_start hadn't been called yet, in
the case where the caller-supplied |ctx| is not NULL.
Change-Id: I6f728e74f0167193891cdb6f122b20b0770283dc
Reviewed-on: https://boringssl-review.googlesource.com/4271
Reviewed-by: Adam Langley <agl@google.com>
Now that ERR is using thread-local storage, there's very little that the
THREADID code is doing and it can be turned into stub functions.
Change-Id: I668613fec39b26c894d029b10a8173c3055f6019
Since ERR will soon have thread-local storage, we don't need to worry
about high-performance implementations and thus don't need to be able to
switch two different implementations at run-time.
Change-Id: I0598054ee8a8b499ac686ea635a96f5d03c754e0
Amazingly, asn1_GetSequence isn't completely unused? Keep that around for now
and ditch everything else. This lets us enable C4311 in MSVC which is actually
a pretty reasonable warning.
Change-Id: I43bb9206b1745e8a68224f3a435713d2a74e04ea
Reviewed-on: https://boringssl-review.googlesource.com/4256
Reviewed-by: Adam Langley <agl@google.com>
Change-Id: If15f2f0e2b4627318c9cdfbc76d5ca56a6894e3f
Reviewed-on: https://boringssl-review.googlesource.com/4270
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
all_tests.go will still complain if tab_test is missing.
Change-Id: I97c3684a4397caa55aaae2ec6555b16ee8366233
Reviewed-on: https://boringssl-review.googlesource.com/4250
Reviewed-by: Adam Langley <agl@google.com>
Implement ECDSA_SIG_new and ECDSA_SIG_free manually in preparation for
removing all crypto/asn1 dependencies from ECDSA signature verification.
Change-Id: I0e84d74fa8e757af0cfb09daef03d59f428143cc
Reviewed-on: https://boringssl-review.googlesource.com/4153
Reviewed-by: Adam Langley <agl@google.com>
Sadly, it turns out that we have need of this, at least for now. The
code is taken from upstream and changed only as much as needed.
This only imports keys and doesn't know how to actually perform
operations on them for now.
Change-Id: I0db70fb938186cb7a91d03f068b386c59ed90b84
After sharding the session cache for fallbacks, the numbers have been pretty
good; 0.03% on dev and 0.02% on canary. Stable is at 0.06% but does not have
the sharded session cache. Before sharding, stable, beta, and dev had been
fairly closely aligned. Between 0.03% being low and the fallback saving us in
all but extremely contrived cases, I think this should be fairly safe.
Add tests for both the cipher suite and protocol version mismatch checks.
BUG=441456
Change-Id: I2374bf64d0aee0119f293d207d45319c274d89ab
Reviewed-on: https://boringssl-review.googlesource.com/3972
Reviewed-by: Adam Langley <agl@google.com>
The encoding of an INTEGER should not have leading zeros, except to pad for the
sign bit.
Change-Id: I80d22818cf1d2ca9d27e215620392e1725372aa5
Reviewed-on: https://boringssl-review.googlesource.com/4218
Reviewed-by: Adam Langley <agl@google.com>
Also check for overflow, although it really shouldn't happen.
Change-Id: I34dfe8eaf635aeaa8bef2656fda3cd0bad7e1268
Reviewed-on: https://boringssl-review.googlesource.com/4235
Reviewed-by: Adam Langley <agl@google.com>
Separate actually writing the fragment to the network from assembling it so
there is no need for is_fragment. record_split_done also needn't be a global;
as of 7fdeaf1101, it is always reset to 0 whether
or not SSL3_WANT_WRITE occurred, despite the comment.
I believe this is sound, but the pre-7fdeaf1 logic wasn't quiiite right;
ssl3_write_pending allows a retry to supply *additional* data, so not all
plaintext had been commited to before the IV was randomized. We could fix this
by tracking how many bytes were committed to the last time we fragmented, but
this is purely an optimization and doesn't seem worth the complexity.
This also fixes the alignment computation in the record-splitting case. The
extra byte was wrong, as demonstrated by the assert.
Change-Id: Ia087a45a6622f4faad32e501942cc910eca1237b
Reviewed-on: https://boringssl-review.googlesource.com/4234
Reviewed-by: Adam Langley <agl@google.com>
