No source changes, just a rename.
Change-Id: Iaef406d2a04dc8c68c94eb2a98eec6378eaeab66
Reviewed-on: https://boringssl-review.googlesource.com/12975
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
BUG=97
Change-Id: I4799cc99511e73af44def1d4daa36a8b4699f62d
Reviewed-on: https://boringssl-review.googlesource.com/12904
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>
Change-Id: If565a5fdfa0f314422aa26c2e8f869965ca08c1b
Reviewed-on: https://boringssl-review.googlesource.com/12969
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <alangley@gmail.com>
Chaining doesn't make much sense. This means we have a discontinuity
when buffer BIOs are empty. For a general filter BIO, this isn't even
meaningful. E.g., the base64 BIO's next_bio doesn't use the same units
(There's one consumer which does call BIO_pending on a base64 BIO, hits
this case, and is only working on accident, I've left it alone for this
CL until we can fix that consumer.)
The DTLS code, notably, assumes BIO_wpending to only report what's in
the buffer BIO. Ideally we'd get rid of the buffer BIO (I'll work on
this next), but, in the meantime, get the sizing right. The immediate
motivation is ssl_test using a BIO pair for DTLS doesn't work. We've
just been lucky none of the tests have been near the MTU.
The buffer BIO is actually unused outside of the SSL stack, so this
shouldn't break external consumers. But for the base64 BIO consumer
mentioned above, I see nothing else which relies on this BIO_[w]pending
chaining.
Change-Id: I6764df8ede0f89fe73c774a8f7c9ae4c054d4184
Reviewed-on: https://boringssl-review.googlesource.com/12964
Reviewed-by: Adam Langley <agl@google.com>
The perl script is a little nuts. obj_dat.pl actually parses the header
file that objects.pl emits to figure out what all the objects are.
Replace it all with a single Go script.
BUG=16
Change-Id: Ib1492e22dbe4cf9cf84db7648612b156bcec8e63
Reviewed-on: https://boringssl-review.googlesource.com/12963
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>
I thought I'd rewritten this, but apparently didn't. The old version
dated to a prior iteration which used macros.
Change-Id: Idefbdb2c11700a44dd5b0733b98efec102b10dd2
Reviewed-on: https://boringssl-review.googlesource.com/12968
Reviewed-by: Adam Langley <agl@google.com>
Most C standard library functions are undefined if passed NULL, even
when the corresponding length is zero. This gives them (and, in turn,
all functions which call them) surprising behavior on empty arrays.
Some compilers will miscompile code due to this rule. See also
https://www.imperialviolet.org/2016/06/26/nonnull.html
Add OPENSSL_memcpy, etc., wrappers which avoid this problem.
BUG=23
Change-Id: I95f42b23e92945af0e681264fffaf578e7f8465e
Reviewed-on: https://boringssl-review.googlesource.com/12928
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This avoids having more generated bits. The table is quite small,
especially so when we take out anything we don't implement. There's no
real need to do the binary search. (Exotic things like GOST, the legacy
NID_rsa and NID_dsa_2 spellings of RSA and DSA, and hash functions we
don't implement.)
Mostly this saves me from having to reimplement obj_xref.pl.
(obj_xref.pl processes nid.h, formerly obj_mac.h, so we can't just use
the existing one and still change nid.h.)
Change-Id: I90911277e691a8b04ea8930f3f314d517f314d29
Reviewed-on: https://boringssl-review.googlesource.com/12962
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Chromium on Linux builds against libstdc++'s debug mode which makes
clang unhappy due to:
../crypto/bytestring/bytestring_test.cc:910:7: error: chosen constructor
is explicit in copy-initialization
{},
^~
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/debug/vector:79:7:
note: constructor declared here
vector(const _Allocator& __a = _Allocator())
^
I believe this was fixed here, but it's too recent:
36f540c70b
Change-Id: I2942d153e1278785c3b81294bc99b86f297cf719
Reviewed-on: https://boringssl-review.googlesource.com/12967
Reviewed-by: Adam Langley <agl@google.com>
X509_STORE_set0_additional_untrusted allows one to set a stack of
additional untrusted certificates that can be used during chain
building. These will be merged with the untrusted certificates set on
the |X509_STORE_CTX|.
Change-Id: I3f011fb0854e16a883a798356af0a24cbc5a9d68
Reviewed-on: https://boringssl-review.googlesource.com/12980
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>
Simplify the code, and in particular make |BN_div|, |BN_mod|, and
|BN_nnmod| insensitive to |BN_FLG_CONSTTIME|. This improves the
effectiveness of testing by reducing the number of branches that are
likely to go untested or less tested.
There is no performance-sensitive code that uses BN_div but doesn't
already use BN_FLG_CONSTTIME except RSA signature verification and
EC_GROUP creation. RSA signature verification, ECDH, and ECDSA
performance aren't significantly different with this change.
Change-Id: Ie34c4ce925b939150529400cc60e1f414c7676cd
Reviewed-on: https://boringssl-review.googlesource.com/9105
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
MSAN doesn't hook |syscall| and thus doesn't know that the kernel has
filled the output buffer when |getrandom| is called.
This change tells MSAN to trust that the memory that |getrandom| writes
to has been initialised. This should avoid false-positives when code
operates on |RAND_bytes| output.
Change-Id: I0a74ebb21bcd1de1f28eda69558ee27f82db807a
Reviewed-on: https://boringssl-review.googlesource.com/12903
Reviewed-by: Adam Langley <alangley@gmail.com>
Commit-Queue: Adam Langley <alangley@gmail.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This reverts commit 97db926cf7,
effectively unreverting the two changes that it contained. A subsequent
change will fix this code for MSAN.
Change-Id: I54a82b667b7a4208c7a960aa28b01cb246bc78c7
Reviewed-on: https://boringssl-review.googlesource.com/12902
Commit-Queue: Adam Langley <alangley@gmail.com>
Reviewed-by: David Benjamin <davidben@google.com>
Get one step closer to removing the dependency on |BN_div| from most
programs. Also get one step closer to a constant-time implementation of
|BN_MONT_CTX_set|; we now "just" need to create a constant-time variant
of |BN_mod_lshift1_quick|.
Note that this version might actually increase the side channel signal,
since the variance in timing in |BN_div| is probably less than the variance
from the many conditional reductions in the new method.
On one Windows x64 machine, the speed of RSA verification using the new
version is not too different from the speed of the old code. However,
|BN_div| is generally slow on Windows x64 so I expect this isn't faster
on all platforms. Regardless, we generally consider ECDSA/EdDSA
signature verification performance to be adaquate and RSA signature
verification is much, much faster even with this change.
For RSA signing the performance is not a significant factor since
performance-sensitive applications will cache the |RSA| structure and
the |RSA| structure will cache the Montgomery contexts.
Change-Id: Ib14f1a35c99b8da435e190342657f6a839381a1a
Reviewed-on: https://boringssl-review.googlesource.com/10520
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>
Call |RSA_check_key| after parsing an RSA private key in order to
verify that the key is consistent. This is consistent with ECC key
parsing, which does a similar key check.
Call |RSA_check_key| after key generation mostly as a way of
double-checking the key generation was done correctly. A similar check
was not added to |EC_KEY_generate| because |EC_KEY_generate| is used
for generating ephemeral ECDH keys, and the check would be too
expensive for that use.
Change-Id: I5759d0d101c00711bbc30f81a3759f8bff01427c
Reviewed-on: https://boringssl-review.googlesource.com/7522
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This is imported from upstream's
71bbc79b7d3b1195a7a7dd5f547d52ddce32d6f0 and test vectors taken
initially from 2d7bbd6c9fb6865e0df480602c3612652189e182 (with a handful
more added).
The tests are a little odd because OpenSSL supports this "salt length
recovery" mode and they go through that codepath for all verifications.
Change-Id: I220104fe87e2a1a1458c99656f9791d8abfbbb98
Reviewed-on: https://boringssl-review.googlesource.com/12822
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This reverts commits 36ca21415a and
7b668a873e. We believe that we need to
update ASAN to be aware of getrandom before we can use it. Otherwise it
believes that the memory with the entropy from this syscall is
uninitialised.
Change-Id: I1ea1c4d3038b3b2cd080be23d7d8b60fc0c83df2
Reviewed-on: https://boringssl-review.googlesource.com/12901
Reviewed-by: Adam Langley <alangley@gmail.com>
Commit-Queue: Adam Langley <alangley@gmail.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This change includes C versions of some of the functions from the x86-64
P-256 code that are currently implemented in assembly. These functions
were part of the original submission by Intel and are covered by the ISC
license.
No semantic change; code is commented out.
Change-Id: Ifdd2fac6caeb73d375d6b125fac98f3945003b32
Reviewed-on: https://boringssl-review.googlesource.com/12861
Reviewed-by: Adam Langley <agl@google.com>
This gives a 15-16% perf boost for 1024-bit RSA keys, but 1024-bit RSA
keys are no longer important enough for this code to carry its weight.
Change-Id: Ia9f0e7fec512c28e90754ababade394c1f11984d
Reviewed-on: https://boringssl-review.googlesource.com/12841
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>
These are regression tests for
https://boringssl-review.googlesource.com/c/12525/ that target the
RSAZ-512 code rather than the disabled RSAZ-1024 code.
These were created by extracting p and dmp1 from
ssl/test/rsa_1024_key.pem and creating similar test vectors as with the
AVX2 test vectors. They currently fail, but pass if the RSAZ-512 code is
disabled.
Change-Id: I99dd3f385941ddbb1cc64b5351f4411081b42dd7
Reviewed-on: https://boringssl-review.googlesource.com/12840
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Note that this adds new non-constant-time code into the RSAZ-based
code path.
Change-Id: Ibca3bc523ede131b55c70ac5066c0014df1f5a70
Reviewed-on: https://boringssl-review.googlesource.com/12525
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>
The input base, |a|, isn't reduced mod |m| in the RSAZ case so
incorrect results are given for out-of-range |a| when the RSAZ
implementation is used. On the other hand, the RSAZ implementation is
more correct as far as constant-time operation w.r.t. |a| is concerned.
Change-Id: Iec4d0195cc303ce442ce687a4b7ea42fb19cfd06
Reviewed-on: https://boringssl-review.googlesource.com/12524
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>
The original bug only affected their big-endian code which we don't
have, but import the test vector anyway. Imported from upstream's
b47f116b1e02d20b1f8a7488be5a04f7cf5bc712.
Change-Id: I349e41d87006533da0e18c948f9cc7dd15f42a44
Reviewed-on: https://boringssl-review.googlesource.com/12820
Reviewed-by: Steven Valdez <svaldez@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>
$1<<32>>32 worked fine with either 32- or 64-bit perl for a good while,
relying on quirk that [pure] 32-bit perl performed it as $1<<0>>0. But
this apparently changed in some version past minimally required 5.10,
and operation result became 0. Yet, it went unnoticed for another while,
because most perl package providers configure their packages with
-Duse64bitint option.
(Imported from upstream's 82e089308bd9a7794a45f0fa3973d7659420fbd8.)
Change-Id: Ie9708bb521c8d7d01afd2e064576f46be2a811a5
Reviewed-on: https://boringssl-review.googlesource.com/12821
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Querying a bit in a BIT STRING is a little finicky. Add some functions
to help with this.
Change-Id: I813b9b6f2d952d61d8717b47bca1344f0ad4b7d1
Reviewed-on: https://boringssl-review.googlesource.com/12800
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This change removes the use of |X509_get_pubkey| from the TLS <= 1.2
code. That function is replaced with a shallow parse of the certificate
to extract the public key instead.
Change-Id: I8938c6c5a01b32038c6b6fa58eb065e5b44ca6d2
Reviewed-on: https://boringssl-review.googlesource.com/12707
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 error value is -2, but at this point ret has already been set to
some running answer and must be reset to -2.
(This is unreachable. BN_rshift only fails on caller or malloc error,
and it doesn't need to malloc when running in-place.)
Change-Id: I33930da84b00d1906bdee9d09b9504ea8121fac4
Reviewed-on: https://boringssl-review.googlesource.com/12681
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Change-Id: Iaac633616a54ba1ed04c14e4778865c169a68621
Reviewed-on: https://boringssl-review.googlesource.com/12703
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>
Change-Id: Ie947ab176d10feb709c6e135d5241c6cf605b8e8
Reviewed-on: https://boringssl-review.googlesource.com/12700
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>
A recent change to curl[1] added support for HTTPS proxies, which
involves running a TLS connection inside another TLS connection. This
was done by using SSL BIOs, which we removed from BoringSSL for being
crazy.
This change adds a stripped-down version of the SSL BIO to decrepit in
order to suport curl.
[1] cb4e2be7c6
Change-Id: I9cb8f2db5b28a5a70724f6f93544297c380ac124
Reviewed-on: https://boringssl-review.googlesource.com/12631
Reviewed-by: Adam Langley <agl@google.com>
d2i_X509 will free an existing |X509*| on parse failure. Thus
|X509_parse_from_buffer| would double-free the result on error.
Change-Id: If2bca2f1e1895bc426079f6ade4b82008707888d
Reviewed-on: https://boringssl-review.googlesource.com/12635
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>
Change-Id: I6514d68435ac4b7e2c638c7612b57bde5886bbba
Reviewed-on: https://boringssl-review.googlesource.com/12629
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>
We've taken to writing bssl::UniquePtr in full, so it's not buying
us much.
Change-Id: Ia2689366cbb17282c8063608dddcc675518ec0ca
Reviewed-on: https://boringssl-review.googlesource.com/12628
Reviewed-by: David Benjamin <davidben@google.com>
This was only used by Chromium and was since replaced with a custom BIO.
Though it meant a new ring buffer implementation, custom BIOs seem a
better solution for folks who wish to do particularly complicated
things, until the new SSL API is available. External-buffer BIO pairs
were effectively a really confusing and leaky abstraction over a ring
buffer anyway.
Change-Id: I0e201317ff87cdccb17b2f8c260ee5bb06c74771
Reviewed-on: https://boringssl-review.googlesource.com/12626
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
AES-GCM-SIV is an AEAD with nonce-misuse resistance. It can reuse
hardware support for AES-GCM and thus encrypt at ~66% the speed, and
decrypt at 100% the speed, of AES-GCM.
See https://tools.ietf.org/html/draft-irtf-cfrg-gcmsiv-02
This implementation is generic, not optimised, and reuses existing AES
and GHASH support as much as possible. It is guarded by !OPENSSL_SMALL,
at least for now.
Change-Id: Ia9f77b256ef5dfb8588bb9ecfe6ee0e827626f57
Reviewed-on: https://boringssl-review.googlesource.com/12541
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This change will cause getrandom to be used in preference to
/dev/urandom when supported by the kernel.
This will also cause BoringSSL-using processes to block until the
entropy pool is initialised on systems that support getrandom(2).
Change-Id: I2d3a17891502c85884c77138ef0f3a719d7ecfe6
Reviewed-on: https://boringssl-review.googlesource.com/12421
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>
There only needs to be a single place where we do the generic
initialisation. All the processor-specific implementations can just
return early.
Change-Id: Ifd8a9c3bd7bec1ee8307aaa7bbeb9afe575e8a47
Reviewed-on: https://boringssl-review.googlesource.com/12540
Reviewed-by: Adam Langley <alangley@gmail.com>
Commit-Queue: Adam Langley <alangley@gmail.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Previously, gcm.c contained a lot of workarounds for cases where BSWAP8
wasn't defined. Rather than handle this in each place, just make it
always available.
While we're here, make these macros inline functions instead and rename
them to something less likely to collide.
Change-Id: I9f2602f8b9965c63a86b177a8a084afb8b53a253
Reviewed-on: https://boringssl-review.googlesource.com/12479
Commit-Queue: Adam Langley <alangley@gmail.com>
Reviewed-by: Adam Langley <agl@google.com>
CRYPTO_ghash_init exposes the (often hardware accelerated) internals for
evaluating GHASH. These can be used for evaluating POLYVAL[1] on
platforms where we don't have dedicated code for it.
[1] https://tools.ietf.org/html/draft-irtf-cfrg-gcmsiv-02#section-3
Change-Id: Ida49ce4911f8657fa384b0bca968daa2ac6b26c1
Reviewed-on: https://boringssl-review.googlesource.com/12478
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>
The key is only needed during initialisation because after that point it
is implicit in the table of powers. So no need to keep it around. There
was a non-specific “haunted house” comment about not changing this, but
I've successfully tested with all the assembly versions so I think that
comment is no longer true.
Change-Id: Id110156afb528904f114d9a4ff2440e03a1a69b8
Reviewed-on: https://boringssl-review.googlesource.com/12477
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
The GCM code has lots of cases of big-endian support left over from
OpenSSL. Since we don't support big-endian systems, drop that code.
Change-Id: I28eb95a9c235c6f705a145fbea72e7569dad2c70
Reviewed-on: https://boringssl-review.googlesource.com/12476
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
j and md_size are public values, so this can just be done directly. (If
they weren't, we'd have worse problems.) This makes the loop look the
same as the rotation loop below.
Change-Id: Ic75550ad4e40b2015668cb12c26ca2d20bd285b6
Reviewed-on: https://boringssl-review.googlesource.com/12474
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Some declarations can be moved closer to use, etc.
Change-Id: Ifa9a51ad77639b94020b15478af234c82466390f
Reviewed-on: https://boringssl-review.googlesource.com/12473
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
