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>
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>
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>
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
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>
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 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>
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>
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>
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>
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 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
