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>
Although we ignore all but the first identity, keep clients honest by
parsing the whole thing. Also explicitly check that the binder and
identity counts match.
Change-Id: Ib9c4caae18398360f3b80f8db1b22d4549bd5746
Reviewed-on: https://boringssl-review.googlesource.com/12469
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>
BUG=101
Change-Id: Ia1edbccee535b0bc3a0e18465286d5bcca240035
Reviewed-on: https://boringssl-review.googlesource.com/12470
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>
This change imports sha256-armv4.pl from upstream at rev 8d1ebff4. This
includes changes to remove the use of adrl, which is not supported by
Clang.
Change-Id: I429e7051d63b59acad21601e40883fc3bd8dd2f5
Reviewed-on: https://boringssl-review.googlesource.com/12480
Commit-Queue: Adam Langley <alangley@gmail.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>
This code wants something which can represent -128..127 or so, not
something about characters.
Change-Id: Icdbfec370317a5e03803939a3b8d1555f8efff1d
Reviewed-on: https://boringssl-review.googlesource.com/12468
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
clang-format mangled this a little.
Change-Id: Ic4d8de0e1f6e926efbe8d14e390fe874b4a7cdcb
Reviewed-on: https://boringssl-review.googlesource.com/12467
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
The compiler should be plenty smart enough to decide whether to inline a
static function called only once. We don't need to resort to so
unreadable a ternary chain.
Change-Id: Iacc8e0c4147fc69008806a0cc36d9e632169601a
Reviewed-on: https://boringssl-review.googlesource.com/12466
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Change-Id: I3350ff0e4ffe7495a83211b89c675a0125fb2f06
Reviewed-on: https://boringssl-review.googlesource.com/12465
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
EC_R_INVALID_COMPRESSED_POINT makes more sense than
EC_R_INVALID_COMPRESSION_BIT here.
Change-Id: I0dbdc91bab59843d5c04f2d0e97600fe7644753e
Reviewed-on: https://boringssl-review.googlesource.com/12464
Reviewed-by: Adam Langley <agl@google.com>
If y is zero, there is no point with odd y, so the odd bit may not be
set, hence EC_R_INVALID_COMPRESSION_BIT. This code instead computed the
Kronecker symbol of x and changed the error code to
EC_R_INVALID_COMPRESSED_POINT if not a square.
As the comment says, this was (intended to be) unreachable. But it
seems x was a typo for tmp1. It dates to before upstream's
6fb60a84dd1ec81953917e0444dab50186617432, when BN_mod_sqrt gave
garbage if its input was not square. Now it emits BN_R_NOT_A_SQUARE.
Upstream's 48fe4d6233ac2d60745742a27f820dd88bc6689d then mapped
BN_R_NOT_A_SQUARE to EC_R_INVALID_COMPRESSED_POINT.
Change-Id: Id9e02fa1c154b61cc0c3a768c9cfe6bd9674c378
Reviewed-on: https://boringssl-review.googlesource.com/12463
Reviewed-by: Adam Langley <agl@google.com>
Zero only has one allowed square root, not two.
Change-Id: I1dbd2137a7011d2f327b271b267099771e5499c3
Reviewed-on: https://boringssl-review.googlesource.com/12461
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This change causes SSL_CTX_set_signed_cert_timestamp_list to check the
SCT list for shallow validity before allowing it to be set.
Change-Id: Ib8a1fe185224ff02ed4ce53a0109e60d934e96b3
Reviewed-on: https://boringssl-review.googlesource.com/12401
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: David Benjamin <davidben@google.com>
This prevents a compiler warning from breaking ppc64le build.
Change-Id: I6752109bd02c6d078e656f89327093f8fb13a125
Reviewed-on: https://boringssl-review.googlesource.com/12363
Reviewed-by: Adam Langley <agl@google.com>
This change contains a C implementation of SHA-1 for POWER using
AltiVec. It is almost as fast as the scalar-only assembly implementation
for POWER/POWERPC family in OpenSSL but it is easier to maintain and it
allows error checking with tools like ASAN.
This is tested only for ppc64le. It may nor may not work for other
platforms in the POWER/POWERPC familiy.
Before:
SHA-1 @ 16 bytes: ~30 MB/s
SHA-1 @ 8K: ~140 MB/s
After:
SHA-1 @ 16 bytes: ~70 MB/s
SHA-1 @ 8K: ~480 MB/s
Change-Id: I790352e86d9c0cc4e1e57d11c5a0aa5b0780ca6b
Reviewed-on: https://boringssl-review.googlesource.com/12203
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>
Otherwise the run_tests target sometimes gets confused.
Change-Id: If49e945bf5137c68db4927ab0f9845d25be63bac
Reviewed-on: https://boringssl-review.googlesource.com/12315
Reviewed-by: Steven Valdez <svaldez@chromium.org>
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 BN_ULONG[P256_LIMBS] can't represent a negative number and
bn_set_words won't produce one. We only need to compare against P.
Change-Id: I7bd1c9e8c162751637459f23f3cfc56884d85864
Reviewed-on: https://boringssl-review.googlesource.com/12304
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
RT#4625
(Imported from upstream's e3057a57caf4274ea1fb074518e4714059dfcabf.)
Add a test in ec_test to cover the ecp_nistz256_points_mul change. Also
revise the low-level infinity tests to cover the changes in
ecp_nistz256_point_add. Upstream's 'infty' logic was also cleaned up to
be simpler and take advantage of the only cases where |p| is infinity.
Change-Id: Ie22de834bf79ecb6191e824ad9fc1bd6f9681b8b
Reviewed-on: https://boringssl-review.googlesource.com/12225
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
As a client, we must tolerate this to avoid interoperability failures
with allowed server behaviors.
BUG=117
Change-Id: I9c40a2a048282e2e63ab5ee1d40773fc2eda110a
Reviewed-on: https://boringssl-review.googlesource.com/12311
Reviewed-by: David Benjamin <davidben@google.com>
We were using a fully-qualified name for nearly everything anyway.
Change-Id: Ia32c68975ed4126feeab7b420f12b726ad6b89b3
Reviewed-on: https://boringssl-review.googlesource.com/12226
Reviewed-by: Adam Langley <agl@google.com>
The other field operations have an explicit _mont suffix to denote their
inputs and outputs are in the Montgomery domain, aside from
ecp_nistz256_neg which works either way. Do the same here.
Change-Id: I63741adaeba8140e29fb0b45dff72273e231add7
Reviewed-on: https://boringssl-review.googlesource.com/12224
Reviewed-by: Adam Langley <agl@google.com>
The file is util-64.c in BoringSSL.
Change-Id: I51891103254ae1541ea4c30f92c41d5d47c2ba55
Reviewed-on: https://boringssl-review.googlesource.com/12223
Reviewed-by: Adam Langley <agl@google.com>
For the most part, this is with random test data which isn't
particularly good. But we'll be able to add more interesting test
vectors as they come up.
Change-Id: I9c50db7ac2c4bf978d4901000ab32e3642aea82b
Reviewed-on: https://boringssl-review.googlesource.com/12222
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>
Addition was not preserving inputs' property of being fully reduced.
Thanks to Brian Smith for reporting this.
(Imported from upstream's b62b2454fadfccaf5e055a1810d72174c2633b8f and
d3034d31e7c04b334dd245504dd4f56e513ca115.)
See also this thread.
https://mta.openssl.org/pipermail/openssl-dev/2016-August/008179.html
Change-Id: I3731f949e2e2ef539dec656c58f1820cc09a56a6
Reviewed-on: https://boringssl-review.googlesource.com/11409
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Change-Id: I0e1d79e85a2d20ab4105b81d39cdbbd692ba67da
Reviewed-on: https://boringssl-review.googlesource.com/12221
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 don't support big-endian so this could only slow down whatever
platforms weren't listed in the #if.
Change-Id: Ie36f862663d947f591dd4896e6a2ab19122bbc0d
Reviewed-on: https://boringssl-review.googlesource.com/12202
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 Poly1305 state defined in the header file is just a 512-byte buffer.
The vector code aligns to 64 bytes but the non-vector code did not.
Since we have lots of space to spare, this change causes the non-vector
code to also align to 64 bytes.
Change-Id: I77e26616a709e770d6eb23df47d9e292742625d7
Reviewed-on: https://boringssl-review.googlesource.com/12201
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Some old assemblers can't cope with r0 in address. It's actually
sensible thing to do, because r0 is shunted to 0 in address arithmetic
and by refusing r0 assembler effectively makes you understand that.
(Imported from upstream's a54aba531327285f64cf13a909bc129e9f9d5970.)
This also pulls in a trailing whitespace fix from upstream's
609b0852e4d50251857dbbac3141ba042e35a9ae.
Change-Id: Ieec0bc8d24b98f86ce4fc9ee6ce5126d127cf452
Reviewed-on: https://boringssl-review.googlesource.com/12188
Reviewed-by: Adam Langley <agl@google.com>
The ASN1_GENERALIZEDTIME_adj() function leaks an ASN1_GENERALIZEDTIME
object on an error path.
(Imported from upstream's fe71bb3ad97ed01ccf92812891cc2bc3ef3dce76.)
Thanks to Jinguang Dong for pointing out the bug.
Change-Id: I2c14662bb03b0cf957bd277bda487f05f07e89e7
Reviewed-on: https://boringssl-review.googlesource.com/12185
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
(Imported from upstream's 2a7dd548a6f5d6f7f84a89c98323b70a2822406e and
9ebcbbba81eba52282df9ad8902f047e2d501f51.)
This is only in the ADX assembly codepath which we do not enable. See
$addx = 0 at the top of the file. Nonetheless, import the test vector
and fix since we still have the code in there.
Upstream's test vector only compares a*b against b*a. The expected
answer was computed using Python.
Change-Id: I3a21093978c5946d83f2d6f4f8399f69d78202cf
Reviewed-on: https://boringssl-review.googlesource.com/12186
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Fuzzer mode explores the handshake, but at the cost of losing coverage
on the record layer. Add a separate build flag and client/server
corpora for this mode.
Note this requires tweaks in consumers' fuzzer build definitions.
BUG=111
Change-Id: I1026dc7301645e165a761068a1daad6eedc9271e
Reviewed-on: https://boringssl-review.googlesource.com/12108
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
In https://boringssl-review.googlesource.com/#/c/11920/2, I addressed a
number of comments but then forgot to upload the change before
submitting it. This change contains the changes that should have been
included in that commit.
Change-Id: Ib70548e791f80abf07a734e071428de8ebedb907
Reviewed-on: https://boringssl-review.googlesource.com/12160
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>
This function allows callers to unpack an Ed25519 “seed” value, which is
a 32 byte value that contains sufficient information to build a public
and private key from.
Change-Id: Ie5d8212a73e5710306314b4f8a93b707665870fd
Reviewed-on: https://boringssl-review.googlesource.com/12040
Reviewed-by: David Benjamin <davidben@google.com>
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>
The naming breaks layering, but it seems we're stuck with it. We don't
seem to have bothered making first-party code call it BIO_print_errors
(I found no callers of BIO_print_errors), so let's just leave it at
ERR_print_errors.
Change-Id: Iddc22a6afc2c61d4b94ac555be95079e0f477171
Reviewed-on: https://boringssl-review.googlesource.com/11960
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Change-Id: I87cbc12aeb399646c6426b7a099dbf13aafc2532
Reviewed-on: https://boringssl-review.googlesource.com/11983
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
d2i_X509_from_buffer parses an |X509| from a |CRYPTO_BUFFER| but ensures
that the |X509_CINF.enc| doesn't make a copy of the encoded
TBSCertificate. Rather the |X509| holds a reference to the given
|CRYPTO_BUFFER|.
Change-Id: I38a4e3d0ca69fc0fd0ef3e15b53181844080fcad
Reviewed-on: https://boringssl-review.googlesource.com/11920
Reviewed-by: David Benjamin <davidben@google.com>
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>
