Partially fixes build with -Wmissing-prototypes -Wmissing-declarations.
Change-Id: I6048f5b7ef31560399b25ed9880156bc7d8abac2
Signed-off-by: Piotr Sikora <piotrsikora@google.com>
Reviewed-on: https://boringssl-review.googlesource.com/7511
Reviewed-by: David Benjamin <davidben@google.com>
This is an attempt to make MSVC happy. Currently it's saying:
..\tool\speed.cc(508) : error C2536: 'SpeedSPAKE2::<lambda_…>::SpeedSPAKE2::<lambda_…>::alice_msg' : cannot specify explicit initializer for arrays
Change-Id: Ifba1df26b5d734f142668a41834645c1549f9f52
Reviewed-on: https://boringssl-review.googlesource.com/7248
Reviewed-by: David Benjamin <davidben@google.com>
We don't actually have an API to let you know if the value is legal to
interpret as a curve ID. (This was kind of a poor API. Oh well.) Also add tests
for key_exchange_info. I've intentionally left server-side plain RSA missing
for now because the SSL_PRIVATE_KEY_METHOD abstraction only gives you bytes and
it's probably better to tweak this API instead.
(key_exchange_info also wasn't populated on the server, though due to a
rebasing error, that fix ended up in the parent CL. Oh well.)
Change-Id: I74a322c8ad03f25b02059da7568c9e1a78419069
Reviewed-on: https://boringssl-review.googlesource.com/6783
Reviewed-by: Adam Langley <agl@google.com>
Make it slightly easier for people to use.
Change-Id: I567e95bf1a5c203170a0b9732fd522fcbe5b7bc1
Reviewed-on: https://boringssl-review.googlesource.com/6773
Reviewed-by: Adam Langley <agl@google.com>
OPENSSL_SMALL will still cause the smaller base-point table to be used
and so won't be as fast at signing as the full version, but Ed25519 will
now work in those builds.
Without OPENSSL_SMALL:
Did 20000 Ed25519 key generation operations in 1008347us (19834.4 ops/sec)
Did 20000 Ed25519 signing operations in 1025594us (19500.9 ops/sec)
Did 6138 Ed25519 verify operations in 1001712us (6127.5 ops/sec)
Did 21000 Curve25519 base-point multiplication operations in 1019237us (20603.6 ops/sec)
Did 7095 Curve25519 arbitrary point multiplication operations in 1065986us (6655.8 ops/sec)
With (on the same machine):
Did 8415 Ed25519 key generation operations in 1020958us (8242.3 ops/sec)
Did 8952 Ed25519 signing operations in 1077635us (8307.1 ops/sec)
Did 6358 Ed25519 verify operations in 1047533us (6069.5 ops/sec)
Did 6620 Curve25519 base-point multiplication operations in 1008922us (6561.5 ops/sec)
Did 7183 Curve25519 arbitrary point multiplication operations in 1096285us (6552.1 ops/sec)
Change-Id: Ib443c0e2bdfd11e044087e66efd55b651a5667e7
Reviewed-on: https://boringssl-review.googlesource.com/6772
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
For completeness. In so far as we care about legacy ciphers' performance at
all, we should have the others too.
Change-Id: Idd2d93345f3af8b6ac5772a1cb3c201f84fe3197
Reviewed-on: https://boringssl-review.googlesource.com/6750
Reviewed-by: Adam Langley <agl@google.com>
Handy to test servers with misbehaving client auth.
Change-Id: I93f7b77c35e223761edade648bc03d1f97ed82fd
Reviewed-on: https://boringssl-review.googlesource.com/6614
Reviewed-by: Adam Langley <agl@google.com>
The consumers have all been updated, so we can move EVP_aead_chacha20_poly1305
to its final state. Unfortunately, the _rfc7539-suffixed version will need to
stick around for just a hair longer. Also the tls1.h macros, but the remaining
consumers are okay with that changing underneath them.
Change-Id: Ibbb70ec1860d6ac6a7e1d7b45e70fe692bf5ebe5
Reviewed-on: https://boringssl-review.googlesource.com/6600
Reviewed-by: Adam Langley <agl@google.com>
The keylog BIO is internally synchronized by the SSL_CTX lock, but an
application may wish to log keys from multiple SSL_CTXs. This is in
preparation for switching Chromium to use a separate SSL_CTX per profile
to more naturally split up the session caches.
It will also be useful for routing up SSLKEYLOGFILE in WebRTC. There,
each log line must be converted to an IPC up from the renderer
processes.
This will require changes in Chromium when we roll BoringSSL.
BUG=458365,webrtc:4417
Change-Id: I2945bdb4def0a9c36e751eab3d5b06c330d66b54
Reviewed-on: https://boringssl-review.googlesource.com/6514
Reviewed-by: Adam Langley <agl@google.com>
MSVC doesn't like unary minus on unsigned types. Also, the speed test
always failed because the inputs were all zeros and thus had small
order.
Change-Id: Ic2d3c2c9bd57dc66295d93891396871cebac1e0b
PKCS#12 files may not necessarily include keys.
Change-Id: Ibb43b609783b02aa9cbb192fea377081169666ff
Reviewed-on: https://boringssl-review.googlesource.com/6456
Reviewed-by: Adam Langley <agl@google.com>
This simply converts a cipher suite string to the list of cipher suites
that it implies.
Change-Id: Id8b31086715d619ea6601c40a6eb84dc0d8c500d
Reviewed-on: https://boringssl-review.googlesource.com/6370
Reviewed-by: Adam Langley <agl@google.com>
QUIC has a complex relationship with BoringSSL owing to it living both
in Chromium and the Google-internal repository. In order for it to
handle the ChaCha20-Poly1305 AEAD switch more easily this change gives
the unsuffixed name to the old AEAD, for now.
Once QUIC has moved to the “_old” version the unsuffixed name can be
given to the new version.
Change-Id: Id8a77be6e3fe2358d78e022413fe088e5a274dca
Reviewed-on: https://boringssl-review.googlesource.com/6361
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <alangley@gmail.com>
∙ host:port parsing, where unavoidable, is now IPv6-friendly.
∙ |BIO_C_GET_CONNECT| is simply removed.
∙ bssl -accept now listens on both IPv6 and IPv4.
Change-Id: I1cbd8a79c0199bab3ced4c4fd79d2cc5240f250c
Reviewed-on: https://boringssl-review.googlesource.com/6214
Reviewed-by: Adam Langley <alangley@gmail.com>
It just calls CRYPTO_library_init and doesn't do anything else. If
anything, I'd like to make CRYPTO_library_init completely go away too.
We have CRYPTO_once now, so I think it's safe to assume that, if ssl/
ever grows initialization needs beyond that of crypto/, we can hide it
behind a CRYPTO_once and not burden callers.
Change-Id: I63dc362e0e9e98deec5516f4620d1672151a91b6
Reviewed-on: https://boringssl-review.googlesource.com/6311
Reviewed-by: Adam Langley <alangley@gmail.com>
Some compilers complain and it's worth checking. Maybe the file changed in size
between ftell and fread.
Change-Id: I7898b8517556ec6899bd6e8866ba3d1cd7efd5f4
Reviewed-on: https://boringssl-review.googlesource.com/5763
Reviewed-by: Adam Langley <agl@google.com>
This is analogous to openssl s_client's -sess_in and -sess_out. Use PEM to
align with OpenSSL. This is useful for debugging session resumption and also
generating things to test serialization against.
Change-Id: Idc58e8fa3dd4c2385f6a2d647e66ef11427be60d
Reviewed-on: https://boringssl-review.googlesource.com/5761
Reviewed-by: Adam Langley <agl@google.com>
This is a simpler implementation than OpenSSL's, lacking responder IDs
and request extensions support. This mirrors the client implementation
already present.
Change-Id: I54592b60e0a708bfb003d491c9250401403c9e69
Reviewed-on: https://boringssl-review.googlesource.com/5700
Reviewed-by: Adam Langley <agl@google.com>
This also removes support for the “old” Channel ID extension.
Change-Id: I1168efb9365c274db6b9d7e32013336e4404ff54
Reviewed-on: https://boringssl-review.googlesource.com/5462
Reviewed-by: Adam Langley <agl@google.com>
This allows BoringSSL to build on OpenBSD with gcc/g++ 4.9.2.
Change-Id: Icce23de87b0358a581124eb8cd37dc48a1f096c9
Reviewed-on: https://boringssl-review.googlesource.com/5401
Reviewed-by: Adam Langley <agl@google.com>
This removes the version field from RSA and instead handles versioning
as part of parsing. (As a bonus, we now correctly limit multi-prime RSA
to version 1 keys.)
Most consumers are also converted. old_rsa_priv_{de,en}code are left
alone for now. Those hooks are passed in parameters which match the old
d2i/i2d pattern (they're only used in d2i_PrivateKey and
i2d_PrivateKey).
Include a test which, among other things, checks that public keys being
serialized as private keys are handled properly.
BUG=499653
Change-Id: Icdd5f0382c4a84f9c8867024f29756e1a306ba08
Reviewed-on: https://boringssl-review.googlesource.com/5273
Reviewed-by: Adam Langley <agl@google.com>
This just tries to convince MSVC that we're not going to use |nprimes|
without initialising it first:
tool\genrsa.cc(63) : warning C4701: potentially uninitialized local
variable 'nprimes' used
Change-Id: If8a68ad4fe2c2fb7a8073b7ba43d540467ddf8f8
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>
One more flag we'd need for bssl client to mimic Chromium.
Change-Id: I66bb43f0d6789c8ab922679747b7e9bc28c1d849
Reviewed-on: https://boringssl-review.googlesource.com/5010
Reviewed-by: Adam Langley <agl@google.com>
This reverts commit e60e2a483b. Turns out we do
still use clock_gettime in speed.cc.
Change-Id: Idab42ef2863345c3d1409b5d33c3e36b41739e1f
Reviewed-on: https://boringssl-review.googlesource.com/4894
Reviewed-by: Adam Langley <agl@google.com>
I think, long ago, I tried to use the monotonic clock in speed.cc, which
needs -lrt. However, the current code doesn't use that and thus doesn't
need -lrt.
Change-Id: Ibcbf90f91ae6b852c0975dff006346125243df54
Reviewed-on: https://boringssl-review.googlesource.com/4622
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
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>
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
This change adds a benchmark for the RNG and also allows specific speed
tests to be selected via a command-line argument, since the full speed
suite is getting quite lengthy now and is only going to get longer in
the future.
Change-Id: If62c69177d58d3eb945d6108524c144ea0044137
Reviewed-on: https://boringssl-review.googlesource.com/4326
Reviewed-by: Adam Langley <agl@google.com>
The rand subcommand outputs entropy to stdout.
Change-Id: I95c2769a1784a8dd4c21efc15009080006d51349
Reviewed-on: https://boringssl-review.googlesource.com/4325
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>
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>
This fixes the standalone build on Windows and matches Chromium.
Change-Id: I194f53e0a610c5ae9cef53c826b22f7bded5f357
Reviewed-on: https://boringssl-review.googlesource.com/4201
Reviewed-by: Adam Langley <agl@google.com>
This is in preparation for using RAII in the unit tests. Those tests are built
in Chromium as well, but Chromium does not have C++11 library support across
all its toolchains. Compiler support is available, so add a partial
reimplementation of std::unique_ptr and std::move under crypto/test/. The
scopers for the crypto/ library are also moved there while the ones for ssl/
stay in ssl/test/.
Change-Id: I38f769acbc16a870db34649928575c7314b6e9f6
Reviewed-on: https://boringssl-review.googlesource.com/4120
Reviewed-by: Adam Langley <agl@google.com>
MinGW on Linux needs lowercase include files. On Windows this doesn't
matter since the filesystems are case-insensitive, but building
BoringSSL on Linux with MinGW has case-sensitive filesystems.
Change-Id: Id9c120d819071b041341fbb978352812d6d073bc
Reviewed-on: https://boringssl-review.googlesource.com/4090
Reviewed-by: Adam Langley <agl@google.com>
This exposes the features needed to mimic Chrome's ClientHello, which is useful
in testing. Also use bssl_shim's scopers for SSL objects.
Change-Id: Icb88bb00c0a05c27610134d618f466a24f7f757a
Reviewed-on: https://boringssl-review.googlesource.com/4113
Reviewed-by: Adam Langley <agl@google.com>
The TLS AEADs require EVP_AEAD_CTX_init_with_direction now. The speed command
was never updated to account for this.
BUG=467762
Change-Id: I8c7d4566b51d54d91d17318b8f4813ad8f19c777
Reviewed-on: https://boringssl-review.googlesource.com/3971
Reviewed-by: Adam Langley <agl@google.com>
Windows x64 uses the IL32P64 data model, which means that unsigned int
is 32 bits and size_t is 64 bits. Previously, the expression
|~(alignment - 1)| resulted in the 32-bit value 0xFFFFFFF0, which was
then extended to the 64-bit value 0x00000000FFFFFFF0 when promoted to
size_t. When the input pointer was masked with this value, the result
was a pointer that was usually way outside the boundaries of the array.
The new code casts |alignment| to size_t first prior to the bitwise
negation, resulting in the correct mask value of 0xFFFFFFFFFFFFFFF0.
Change-Id: I04754aa9e1ce7a615c2b4c74051cfcca38dbb52f
Reviewed-on: https://boringssl-review.googlesource.com/3961
Reviewed-by: Adam Langley <agl@google.com>
Including string.h in base.h causes any file that includes a BoringSSL
header to include string.h. Generally this wouldn't be a problem,
although string.h might slow down the compile if it wasn't otherwise
needed. However, it also causes problems for ipsec-tools in Android
because OpenSSL didn't have this behaviour.
This change removes string.h from base.h and, instead, adds it to each
.c file that requires it.
Change-Id: I5968e50b0e230fd3adf9b72dd2836e6f52d6fb37
Reviewed-on: https://boringssl-review.googlesource.com/3200
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
This avoids having Windows be different and is also easier for testing
because it's a simple matter to unalign the pointer if needed.
Change-Id: I32cfa5834e3fe4f16304a25092b9c71946d4744d
Reviewed-on: https://boringssl-review.googlesource.com/3131
Reviewed-by: Adam Langley <agl@google.com>
This avoids a conflict with the Chromium build system, which
defines WIN32_LEAN_AND_MEAN with a different value.
BUG=crbug.com/453196
Change-Id: Ia15ec7c20325c1961af4f32e5208266e5f846f35
Reviewed-on: https://boringssl-review.googlesource.com/3150
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
Define WIN32_LEAN_AND_MEAN before including Windows Platform SDK
headers to preempt naming conflicts and to make the build faster. Avoid
including those headers in BoringSSL headers. Document that Platform
SDK 8.1 or later is required on Windows.
Change-Id: I907ada21dc722527ea37e839c71c5157455a7003
Reviewed-on: https://boringssl-review.googlesource.com/3100
Reviewed-by: Adam Langley <agl@google.com>
We deal with the difference between binary and text modes on Windows by
doing all I/O in binary mode (including, in particular,
stdin/stdout/stderr) and by treating text mode as equivalent to binary
mode (i.e. we use Unix line ending semantics).
Change-Id: I76a46d8d02cd7efe1931c8272d8f2c311aef3acb
Reviewed-on: https://boringssl-review.googlesource.com/3070
Reviewed-by: Adam Langley <agl@google.com>
Android might want to replace the system *sum (i.e. md5sum, sha256sum
etc) binaries with a symlink to the BoringSSL tool binary.
This change also allows the tool to figure out what to do based on
argv[0] if it matches one of the known commands.
Change-Id: Ia4fc3cff45ce2ae623dae6786eea5d7ad127d44b
Reviewed-on: https://boringssl-review.googlesource.com/2940
Reviewed-by: Adam Langley <agl@google.com>
This change adds the AES-128-CBC-SHA and AES-256-CBC-SHA AEADs to the
speed test. These AEADs need an 11 byte additional data so the test is
extended to be able to provide that.
Change-Id: I9a57c2321a979a68ab0df9faf1bb26b44a3009c4
Reviewed-on: https://boringssl-review.googlesource.com/2922
Reviewed-by: Adam Langley <agl@google.com>
This eliminates a source of variability from the benchmarks.
Change-Id: I8ce07bd68e7591f8c5545040b02b96d21609a0e5
Reviewed-on: https://boringssl-review.googlesource.com/2920
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
This lets us run bssl speed at least. bssl client is currently compiled
out until we clean up our socket story on Windows and get it working.
Change-Id: Ib1dc0d0e0a6eed7544207e7bbe138503731fda67
Reviewed-on: https://boringssl-review.googlesource.com/2103
Reviewed-by: Adam Langley <agl@google.com>
In order to minimise the upstream diffs needed for bits of Android to
build with BoringSSL, this change implements the old style PKCS#12
functions as wrappers around the modern parser.
The function to read all the contents of a BIO could almost be a utility
function but I'll wait until there are two uses for it first.
The important change from the original functions is that these will
always read the complete buffer/BIO/FILE passed in. Based on a survey of
uses of d2i_PKCS12 that I found, this appears to be universally what
callers want anyway.
Change-Id: I3f5b84e710b161d975f91f4d16c83d44371368d1
Reviewed-on: https://boringssl-review.googlesource.com/1791
Reviewed-by: Adam Langley <agl@google.com>
Configures the SSL stack to log session information to a BIO. The intent is to
support NSS's SSLKEYLOGFILE environment variable. Add support for the same
environment variable to tool/client.cc.
Tested against Wireshark 1.12.0.
BUG=393477
Change-Id: I4c231f9abebf194eb2df4aaeeafa337516774c95
Reviewed-on: https://boringssl-review.googlesource.com/1699
Reviewed-by: Adam Langley <agl@google.com>
This is cleaner than the OpenSSL code was, at least, but it's hardly
beautiful due to the "standard" that it's trying to implement. (See
[1].)
The references from the PKCS#8 code to various ciphers have digests have
been made into function pointer references rather than NIDs so that the
linker will be able to drop RC2 code for binaries that don't call PKCS#8
or #12 functions.
A bug that crashed OpenSSL/BoringSSL when parsing a malformed PKCS#8
structure has been fixed too.
See https://www.cs.auckland.ac.nz/~pgut001/pubs/pfx.html
Change-Id: Iaa1039e04ed7877b90792835e8ce3ebc3b29f89e
Reviewed-on: https://boringssl-review.googlesource.com/1592
Reviewed-by: Adam Langley <agl@google.com>
This change adds the stitched RC4-MD5 code from upstream OpenSSL but
exposes it as an AEAD. It's not a normal AEAD (it's stateful thus
doesn't take an nonce) but forcing pre-AEAD cipher suites in the AEAD
interface is less painful than forcing AEADs into the EVP_CIPHER
interface. Over time, more and more cipher suites will be exposed as
TLS-specific AEADs and then ssl/ can drop support for EVP_CIPHER.
See original code from upstream:
https://github.com/openssl/openssl/blob/master/crypto/evp/e_rc4_hmac_md5.c
Change-Id: Ia9267b224747f02be6b934ea0b2b50e1f529fab9
Reviewed-on: https://boringssl-review.googlesource.com/1043
Reviewed-by: Adam Langley <agl@google.com>
Apart from the obvious little issues, this also works around a
(seeming) libtool/linker:
a.c defines a symbol:
int kFoo;
b.c uses it:
extern int kFoo;
int f() {
return kFoo;
}
compile them:
$ gcc -c a.c
$ gcc -c b.c
and create a dummy main in order to run it, main.c:
int f();
int main() {
return f();
}
this works as expected:
$ gcc main.c a.o b.o
but, if we make an archive:
$ ar q lib.a a.o b.o
and use that:
$ gcc main.c lib.a
Undefined symbols for architecture x86_64
"_kFoo", referenced from:
_f in lib.a(b.o)
(It doesn't matter what order the .o files are put into the .a)
Linux and Windows don't seem to have this problem.
nm on a.o shows that the symbol is of type "C", which is a "common symbol"[1].
Basically the linker will merge multiple common symbol definitions together.
If ones makes a.c read:
int kFoo = 0;
Then one gets a type "D" symbol - a "data section symbol" and everything works
just fine.
This might actually be a libtool bug instead of an ld bug: Looking at `xxd
lib.a | less`, the __.SYMDEF SORTED index at the beginning of the archive
doesn't contain an entry for kFoo unless initialised.
Change-Id: I4cdad9ba46e9919221c3cbd79637508959359427
Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta).
(This change contains substantial changes from the original and
effectively starts a new history.)
