rsa_default_encrypt allowed an RSA modulus 8 times larger than the
intended maximum size due to bits vs. bytes confusion.
Further, as |rsa_default_encrypt| got this wrong while
|rsa_default_verify_raw| got it right, factor out the duplicated logic
so that such inconsistencies are less likely to occur.
BUG=576856
Change-Id: Ic842fadcbb3b140d2ba4295793457af2b62d9444
Reviewed-on: https://boringssl-review.googlesource.com/6900
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
Some build systems don't like two targets with the same base name and
the curve25519 code had x25519-x86_64.[Sc].
Change-Id: If8382eb84996d7e75b34b28def57829d93019cff
Reviewed-on: https://boringssl-review.googlesource.com/6878
Reviewed-by: Adam Langley <agl@google.com>
Commit 2b0180c37fa6ffc48ee40caa831ca398b828e680 attempted to do this but
only hit one of many BN_mod_exp codepaths. Fix remaining variants and
add a test for each method.
Thanks to Hanno Boeck for reporting this issue.
(Imported from upstream's 44e4f5b04b43054571e278381662cebd3f3555e6.)
Change-Id: Ic691b354101c3e9c3565300836fb6d55c6f253ba
Reviewed-on: https://boringssl-review.googlesource.com/6820
Reviewed-by: Adam Langley <agl@google.com>
EVP_MAX_MD_SIZE is large enough to fit a MD5/SHA1 concatenation, and
necessarily is because EVP_md5_sha1 exists. This shaves 128 bytes of
per-connection state.
Change-Id: I848a8563dfcbac14735bb7b302263a638528f98e
Reviewed-on: https://boringssl-review.googlesource.com/6804
Reviewed-by: Adam Langley <agl@google.com>
That we're half and half is really confusing.
Change-Id: I1c2632682e8a3e63d01dada8e0eb3b735ff709ce
Reviewed-on: https://boringssl-review.googlesource.com/6785
Reviewed-by: Adam Langley <agl@google.com>
This unifies the ClientKeyExchange code rather nicely. ServerKeyExchange
is still pretty specialized. For simplicity, I've extended the yaSSL bug
workaround for clients as well as servers rather than route in a
boolean.
Chrome's already banished DHE to a fallback with intention to remove
altogether later, and the spec doesn't say anything useful about
ClientDiffieHellmanPublic encoding, so this is unlikely to cause
problems.
Change-Id: I0355cd1fd0fab5729e8812e4427dd689124f53a2
Reviewed-on: https://boringssl-review.googlesource.com/6784
Reviewed-by: Adam Langley <agl@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>
The new curve is not enabled by default.
As EC_GROUP/EC_POINT is a bit too complex for X25519, this introduces an
SSL_ECDH_METHOD abstraction which wraps just the raw ECDH operation. It
also tidies up some of the curve code which kept converting back and
force between NIDs and curve IDs. Now everything transits as curve IDs
except for API entry points (SSL_set1_curves) which take NIDs. Those
convert immediately and act on curve IDs from then on.
Note that, like the Go implementation, this slightly tweaks the order of
operations. The client sees the server public key before sending its
own. To keep the abstraction simple, SSL_ECDH_METHOD expects to
generate a keypair before consuming the peer's public key. Instead, the
client handshake stashes the serialized peer public value and defers
parsing it until it comes time to send ClientKeyExchange. (This is
analogous to what it was doing before where it stashed the parsed peer
public value instead.)
It still uses TLS 1.2 terminology everywhere, but this abstraction should also
be compatible with TLS 1.3 which unifies (EC)DH-style key exchanges.
(Accordingly, this abstraction intentionally does not handle parsing the
ClientKeyExchange/ServerKeyExchange framing or attempt to handle asynchronous
plain RSA or the authentication bits.)
BUG=571231
Change-Id: Iba09dddee5bcdfeb2b70185308e8ab0632717932
Reviewed-on: https://boringssl-review.googlesource.com/6780
Reviewed-by: Adam Langley <agl@google.com>
clang-format keeps getting annoyed at it. Also remove some long-dead
constants.
Change-Id: I61e773f5be1e60ca28f1ea085e3afa7cb2c97b9e
Reviewed-on: https://boringssl-review.googlesource.com/6778
Reviewed-by: Adam Langley <agl@google.com>
This injects an interface to abstract between elliptic.Curve and a
byte-oriented curve25519. The C implementation will follow a similar
strategy.
Note that this slightly tweaks the order of operations. The client sees
the server public key before sending its own. To keep the abstraction
simple, ecdhCurve expects to generate a keypair before consuming the
peer's public key. Instead, the client handshake stashes the serialized
peer public value and defers parsing it until it comes time to send
ClientKeyExchange. (This is analogous to what it was doing before where
it stashed the parsed peer public value instead.)
BUG=571231
Change-Id: I771bb9aee0dd6903d395c84ec4f2dd7b3e366c75
Reviewed-on: https://boringssl-review.googlesource.com/6777
Reviewed-by: Adam Langley <agl@google.com>
Hopefully this can be replaced with a standard library version later.
BUG=571231
Change-Id: I61ae1d9d057c6d9e1b92128042109758beccc7ff
Reviewed-on: https://boringssl-review.googlesource.com/6776
Reviewed-by: Adam Langley <agl@google.com>
We don't live in a workspace, but relative import paths exist, so we
don't have to modify the modules we bundle to avoid naming collisions.
Change-Id: Ie7c70dbc4bb0485421814d40b6a6bd5f140e1d29
Reviewed-on: https://boringssl-review.googlesource.com/6781
Reviewed-by: Adam Langley <agl@google.com>
It already wasn't in the default list and no one enables it. Remove it
altogether. (It's also gone from the current TLS 1.3 draft.)
Change-Id: I143d07d390d186252204df6bdb8ffd22649f80e3
Reviewed-on: https://boringssl-review.googlesource.com/6775
Reviewed-by: Adam Langley <agl@google.com>
In doing so, make the asynchronous portion look more like
ssl3_send_server_key_exchange. This is a considerably simpler structure,
so the save/resume doesn't need any state.
Mostly this means writing out the signature algorithm can now go through
CBB rather than a uint8_t* without bounds check.
Change-Id: If99fcffd0d41a84514c3d23034062c582f1bccb2
Reviewed-on: https://boringssl-review.googlesource.com/6771
Reviewed-by: Adam Langley <agl@google.com>
The MSVC build is failing with:
ssl\s3_srvr.c(1363) : warning C4701: potentially uninitialized local variable 'digest_len' used
I don't believe that this warning is valid, but this change assigns a
value to |digest_len| to fix the build.
Change-Id: I20107a932bc16c880032cc1a57479b1a806aa8ea
Reviewed-on: https://boringssl-review.googlesource.com/6821
Reviewed-by: Adam Langley <agl@google.com>
There is some messiness around saving and restoring the CBB, but this is
still significantly clearer.
Note that the BUF_MEM_grow line is gone in favor of a fixed CBB like the
other functions ported thus far. This line was never necessary as
init_buf is initialized to 16k and none of our key exchanges get that
large. (The largest one can get is DHE_RSA. Even so, it'd take a roughly
30k-bit DH group with a 30k-bit RSA key.)
Having such limits and tight assumptions on init_buf's initial size is
poor (but on par for the old code which usually just blindly assumed the
message would not get too large) and the size of the certificate chain
is much less obviously bounded, so those BUF_MEM_grows can't easily go.
My current plan is convert everything but those which legitimately need
BUF_MEM_grow to CBB, then atomically convert the rest, remove init_buf,
and switch everything to non-fixed CBBs. This will hopefully also
simplify async resumption. In the meantime, having a story for
resumption means the future atomic change is smaller and, more
importantly, relieves some complexity budget in the ServerKeyExchange
code for adding Curve25519.
Change-Id: I1de6af9856caaed353453d92a502ba461a938fbd
Reviewed-on: https://boringssl-review.googlesource.com/6770
Reviewed-by: Adam Langley <agl@google.com>
Apple these days ships lldb without gdb. Teach runner how to launch it
too.
Change-Id: I25f845f84f1c87872a9e3bc4b7fe3e7344e8c1f7
Reviewed-on: https://boringssl-review.googlesource.com/6769
Reviewed-by: Adam Langley <agl@google.com>
Functions which take a BN_CTX also accept NULL. Allocating a BN_CTX is
only useful if doing multiple operations, which we aren't.
Change-Id: Ib31113f214707cce6283e090ded0bf93ae5e7c12
Reviewed-on: https://boringssl-review.googlesource.com/6768
Reviewed-by: Adam Langley <agl@google.com>
This relieves some complexity budget for adding Curve25519 to this
code.
This also adds a BN_bn2cbb_padded helper function since this seems to be a
fairly common need.
Change-Id: Ied0066fdaec9d02659abd6eb1a13f33502c9e198
Reviewed-on: https://boringssl-review.googlesource.com/6767
Reviewed-by: Adam Langley <agl@google.com>
This assembly is in gas syntax so is not built on Windows nor when
OPENSSL_SMALL is defined.
Change-Id: I1050cf1b16350fd4b758e4c463261b30a1b65390
Reviewed-on: https://boringssl-review.googlesource.com/6782
Reviewed-by: Adam Langley <agl@google.com>
This function may fail on malloc error.
Change-Id: I8631b1763dac5a3801fcaca81bdfcb8d24d3728c
Reviewed-on: https://boringssl-review.googlesource.com/6765
Reviewed-by: Adam Langley <agl@google.com>
These will be needed when we start writing variable-length things to a
CBB.
Change-Id: Ie7b9b140f5f875b43adedc8203ce9d3f4068dfea
Reviewed-on: https://boringssl-review.googlesource.com/6764
Reviewed-by: Adam Langley <agl@google.com>
A lot of commented-out code we haven't had to put them back, so these
can go now. Also remove the TODO about OAEP having a weird API. The API
is wrong, but upstream's shipped it with the wrong API, so that's what
it is now.
Change-Id: I7da607cf2d877cbede41ccdada31380f812f6dfa
Reviewed-on: https://boringssl-review.googlesource.com/6763
Reviewed-by: Adam Langley <agl@google.com>
There's a few that can't work since the types don't even exist.
Change-Id: Idf860b146439c95d33814d25bbc9b8f61774b569
Reviewed-on: https://boringssl-review.googlesource.com/6762
Reviewed-by: Adam Langley <agl@google.com>
There was a TODO to remove it once asn1_mac.h was trimmed. This has now
happened. Remove it and reset error codes for crypto/asn1.
Change-Id: Iaf2f3e75741914415372939471b135618910f95d
Reviewed-on: https://boringssl-review.googlesource.com/6761
Reviewed-by: Adam Langley <agl@google.com>
The function X509_verify_cert checks the value of |ctx->chain| at the
beginning, and if it is NULL then it initialises it, along with the value
of |ctx->untrusted|. The normal way to use X509_verify_cert() is to first
call X509_STORE_CTX_init(); then set up various parameters etc; then call
X509_verify_cert(); then check the results; and finally call
X509_STORE_CTX_cleanup(). The initial call to X509_STORE_CTX_init() sets
|ctx->chain| to NULL. The only place in the OpenSSL codebase where
|ctx->chain| is set to anything other than a non NULL value is in
X509_verify_cert itself. Therefore the only ways that |ctx->chain| could be
non NULL on entry to X509_verify_cert is if one of the following occurs:
1) An application calls X509_verify_cert() twice without re-initialising
in between.
2) An application reaches inside the X509_STORE_CTX structure and changes
the value of |ctx->chain| directly.
With regards to the second of these, we should discount this - it should
not be supported to allow this.
With regards to the first of these, the documentation is not exactly
crystal clear, but the implication is that you must call
X509_STORE_CTX_init() before each call to X509_verify_cert(). If you fail
to do this then, at best, the results would be undefined.
Calling X509_verify_cert() with |ctx->chain| set to a non NULL value is
likely to have unexpected results, and could be dangerous. This commit
changes the behaviour of X509_verify_cert() so that it causes an error if
|ctx->chain| is anything other than NULL (because this indicates that we
have not been initialised properly). It also clarifies the associated
documentation.
(Imported from upstream's 692f07c3e0c04180b56febc2feb57cd94395a7a2.)
Change-Id: I971f1a305f12bbf9f4ae955313d5557368f0d374
Reviewed-on: https://boringssl-review.googlesource.com/6760
Reviewed-by: Adam Langley <agl@google.com>
This check was fixed a while ago, but it could have been much simpler.
In the RSA key exchange, the expected size of the output is known, making the
padding check much simpler. There isn't any use in exporting the more general
RSA_message_index_PKCS1_type_2. (Without knowing the expected size, any
integrity check or swap to randomness or other mitigation is basically doomed
to fail.)
Verified with the valgrind uninitialized memory trick that we're still
constant-time.
Also update rsa.h to recommend against using the PKCS#1 v1.5 schemes.
Thanks to Ryan Sleevi for the suggestion.
Change-Id: I4328076b1d2e5e06617dd8907cdaa702635c2651
Reviewed-on: https://boringssl-review.googlesource.com/6613
Reviewed-by: Adam Langley <agl@google.com>
We should reject RSA public keys with exponents of less than 3.
This change also rejects even exponents, although the usefulness
of such a public key is somewhat questionable.
BUG=chromium:541257
Change-Id: I1499e9762ba40a7cf69155d21d55bc210cd6d273
Reviewed-on: https://boringssl-review.googlesource.com/6710
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>
This removes 16k from a release-mode build of the bssl tool. Now that we've
finished the AEAD refactor, there's no use in keeping this around as a
prototype for "stateful AEADs".
Before:
Did 2264000 RC4-MD5 (16 bytes) seal operations in 1000430us (2263026.9 ops/sec): 36.2 MB/s
Did 266000 RC4-MD5 (1350 bytes) seal operations in 1000984us (265738.5 ops/sec): 358.7 MB/s
Did 50000 RC4-MD5 (8192 bytes) seal operations in 1014209us (49299.5 ops/sec): 403.9 MB/s
After:
Did 1895000 RC4-MD5 (16 bytes) seal operations in 1000239us (1894547.2 ops/sec): 30.3 MB/s
Did 199000 RC4-MD5 (1350 bytes) seal operations in 1001361us (198729.5 ops/sec): 268.3 MB/s
Did 39000 RC4-MD5 (8192 bytes) seal operations in 1014832us (38430.0 ops/sec): 314.8 MB/s
There is a non-trivial performance hit, but this cipher doesn't matter much and
the stitched mode code reaches into MD5_CTX and RC4_KEY in somewhat unfortunate
ways.
Change-Id: I9ecd28d6afb54e90ce61baecc641742af2ae6269
Reviewed-on: https://boringssl-review.googlesource.com/6752
Reviewed-by: Adam Langley <agl@google.com>
We can reuse the HMAC_CTX that stores the key. The API is kind of unfortunate
as, in principle, it should be possible to do an allocation-averse HMAC with a
shared key on multiple threads at once (EVP_AEAD_CTX is normally logically
const). At some point it may be worth rethinking those APIs somewhat. But
these "stateful AEADs" are already stateful in their EVP_CIPHER_CTX, so this is
fine.
Each cipher was run individually to minimize the effect of other ciphers doing
their mallocs. (Although the cost of a malloc is presumably going to depend a
lot on the malloc implementation and what's happened before in the process, so
take these numbers with a bucket of salt. They vary widely even with the same
arguments.)
Taking malloc out of seal/open also helps with the malloc tests. DTLS currently
cannot distinguish a malloc failure (should be fatal) from a decryption failure
(not fatal), so the malloc tests get stuck. But this doesn't completely get us
there since tls_cbc.c mallocs. This also assumes EVP_CIPHER_CTX, EVP_MD_CTX,
and HMAC_CTX are all clever about reusing their allocations when reset (which
they are).
Before:
Did 1315000 AES-128-CBC-SHA1 (16 bytes) seal operations in 1000087us (1314885.6 ops/sec): 21.0 MB/s
Did 181000 AES-128-CBC-SHA1 (1350 bytes) seal operations in 1004918us (180114.2 ops/sec): 243.2 MB/s
Did 34000 AES-128-CBC-SHA1 (8192 bytes) seal operations in 1024250us (33195.0 ops/sec): 271.9 MB/s
After:
Did 1766000 AES-128-CBC-SHA1 (16 bytes) seal operations in 1000319us (1765436.8 ops/sec): 28.2 MB/s
Did 187000 AES-128-CBC-SHA1 (1350 bytes) seal operations in 1004002us (186254.6 ops/sec): 251.4 MB/s
Did 35000 AES-128-CBC-SHA1 (8192 bytes) seal operations in 1014885us (34486.7 ops/sec): 282.5 MB/s
Before:
Did 391000 DES-EDE3-CBC-SHA1 (16 bytes) seal operations in 1000038us (390985.1 ops/sec): 6.3 MB/s
Did 16000 DES-EDE3-CBC-SHA1 (1350 bytes) seal operations in 1060226us (15091.1 ops/sec): 20.4 MB/s
Did 2827 DES-EDE3-CBC-SHA1 (8192 bytes) seal operations in 1035971us (2728.8 ops/sec): 22.4 MB/s
After:
Did 444000 DES-EDE3-CBC-SHA1 (16 bytes) seal operations in 1001814us (443196.0 ops/sec): 7.1 MB/s
Did 17000 DES-EDE3-CBC-SHA1 (1350 bytes) seal operations in 1042535us (16306.4 ops/sec): 22.0 MB/s
Did 2590 DES-EDE3-CBC-SHA1 (8192 bytes) seal operations in 1012378us (2558.3 ops/sec): 21.0 MB/s
Before:
Did 1316000 AES-256-CBC-SHA1 (16 bytes) seal operations in 1000510us (1315329.2 ops/sec): 21.0 MB/s
Did 157000 AES-256-CBC-SHA1 (1350 bytes) seal operations in 1002944us (156539.1 ops/sec): 211.3 MB/s
Did 29000 AES-256-CBC-SHA1 (8192 bytes) seal operations in 1030284us (28147.6 ops/sec): 230.6 MB/s
After:
Did 1645000 AES-256-CBC-SHA1 (16 bytes) seal operations in 1000313us (1644485.3 ops/sec): 26.3 MB/s
Did 162000 AES-256-CBC-SHA1 (1350 bytes) seal operations in 1003060us (161505.8 ops/sec): 218.0 MB/s
Did 36000 AES-256-CBC-SHA1 (8192 bytes) seal operations in 1014819us (35474.3 ops/sec): 290.6 MB/s
Before:
Did 1435000 RC4-SHA1 (16 bytes) seal operations in 1000245us (1434648.5 ops/sec): 23.0 MB/s
Did 207000 RC4-SHA1 (1350 bytes) seal operations in 1004675us (206036.8 ops/sec): 278.1 MB/s
Did 38000 RC4-SHA1 (8192 bytes) seal operations in 1022712us (37156.1 ops/sec): 304.4 MB/s
After:
Did 1853000 RC4-SHA1 (16 bytes) seal operations in 1000433us (1852198.0 ops/sec): 29.6 MB/s
Did 206000 RC4-SHA1 (1350 bytes) seal operations in 1002370us (205512.9 ops/sec): 277.4 MB/s
Did 42000 RC4-SHA1 (8192 bytes) seal operations in 1024209us (41007.3 ops/sec): 335.9 MB/s
Change-Id: I0edb89bddf146cf91a8e7a99c56b2278c8f38094
Reviewed-on: https://boringssl-review.googlesource.com/6751
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>
Only ECDHE-based ciphers are implemented. To ease the transition, the
pre-standard cipher shares a name with the standard one. The cipher rule parser
is hacked up to match the name to both ciphers. From the perspective of the
cipher suite configuration language, there is only one cipher.
This does mean it is impossible to disable the old variant without a code
change, but this situation will be very short-lived, so this is fine.
Also take this opportunity to make the CK and TXT names align with convention.
Change-Id: Ie819819c55bce8ff58e533f1dbc8bef5af955c21
Reviewed-on: https://boringssl-review.googlesource.com/6686
Reviewed-by: Adam Langley <agl@google.com>
This will be used to test the C implementation against.
Change-Id: I2d396d27630937ea610144e381518eae76f78dab
Reviewed-on: https://boringssl-review.googlesource.com/6685
Reviewed-by: Adam Langley <agl@google.com>
In preparation for a Go implementation of the new TLS ciphers to test
against, implement the AEAD primitive.
Change-Id: I69b5b51257c3de16bdd36912ed2bc9d91ac853c8
Reviewed-on: https://boringssl-review.googlesource.com/6684
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>
There were a couple more asm lines to turn into __asm__ when the patches got
reordered slightly.
Change-Id: I44be5caee6d09bb3db5dea4791592b12d175822c
Reviewed-on: https://boringssl-review.googlesource.com/6741
Reviewed-by: Adam Langley <agl@google.com>
In preparation for implementing the RFC 7539 variant to test against.
Change-Id: I0ce5e856906e00925ad1d849017f9e7fda087a8e
Reviewed-on: https://boringssl-review.googlesource.com/6683
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>
https://boringssl-review.googlesource.com/6101 was mismerged from *ring* and
lost some tests. Also add the corresponding tag truncation tests for the new
construction. So long as we have that feature, we should have tests for it.
(Although, do we actually need to support it?)
Change-Id: I70784cbac345e0ad11b496102856c53932b7362e
Reviewed-on: https://boringssl-review.googlesource.com/6682
Reviewed-by: Adam Langley <agl@google.com>
dh_tmp can only contain parameters, now that DHE always generates keys fresh
for each connection.
Change-Id: I56dad4cbec7e21326360d79df211031fd9734004
Reviewed-on: https://boringssl-review.googlesource.com/6702
Reviewed-by: Adam Langley <agl@google.com>
clang scan-build is annoyed it's not obvious the sizeof line matches the
pointer type. This is easy to fix and makes it be quiet.
Change-Id: Iec80d2a087f81179c88cae300f56d3f76b32b347
Reviewed-on: https://boringssl-review.googlesource.com/6701
Reviewed-by: Adam Langley <agl@google.com>
