- Jul 29, 2018
-
-
Bryan Donlan authored
FIPS 186-4 does not specify a hard requirement on DSA digest lengths, and in any case the current check rejects the FIPS recommended digest lengths for key sizes != 1024 bits. Fixes: #6748 Reviewed-by:
Rich Salz <rsalz@openssl.org> Reviewed-by:
Andy Polyakov <appro@openssl.org> (Merged from https://github.com/openssl/openssl/pull/6749)
-
- Jul 28, 2018
-
-
Beat Bolli authored
This here page only documents the callback values 0 to 2, but the callers of BN_generate_prime_ex() call it with the value 3. The list of manual pages in the SEE ALSO section was extended with the output from git grep BN_GENCB_call.*[3-9] while in the doc/man3 directory. Signed-off-by:Beat Bolli <dev@drbeat.li> Reviewed-by:
Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> Reviewed-by:
-
- Jul 26, 2018
-
-
Benjamin Kaduk authored
Commit 1c4aa31d changed how we process and store SNI information during the handshake, so that a hostname is only saved in the SSL_SESSION structure if that SNI value has actually been negotiated. SSL_get_servername() was adjusted to match, with a new conditional being added to handle the case when the handshake processing is ongoing, and a different location should be consulted for the offered SNI value. This was done in an attempt to preserve the historical behavior of SSL_get_servername(), a function whose behavior only mostly matches its documentation, and whose documentation is both lacking and does not necessarily reflect the actual desired behavior for such an API. Unfortunately, sweeping changes that would bring more sanity to this space are not possible until OpenSSL 1.2.0, for ABI compatibility reasons, so we must attempt to maintain the existing behavior to the extent possible. The above-mentioned commit did not take into account the behavior of SSL_get_servername() during resumption handshakes for TLS 1.2 and prior, where no SNI negotiation is performed. In that case we would not properly parse the incoming SNI and erroneously return NULL as the servername, when instead the logical session is associated with the SNI value cached in the SSL_SESSION. (Note that in some cases an SNI callback may not need to do anything in a TLS 1.2 or prior resumption flow, but we are calling the callbacks and did not provide any guidance that they should no-op if the connection is being resumed, so we must handle this case in a usable fashion.) Update our behavior accordingly to return the session's cached value during the handshake, when resuming. This fixes the boringssl tests. [extended tests] Reviewed-by:
Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/6792)
-
Benjamin Kaduk authored
To start with, actually set an SNI callback (copied from bssl_shim); we weren't actually testing much otherwise (and just happened to have been passing due to buggy libssl behavior prior to commit 1c4aa31d ). Also use proper C++ code for handling C strings -- when a C API (SSL_get_servername()) returns NULL instead of a string, special-case that instead of blindly trying to compare NULL against a std::string, and perform the comparsion using the std::string operators instead of falling back to pointer comparison. Reviewed-by:
-
Billy Brumley authored
This commit leverages the Montgomery ladder scaffold introduced in #6690 (alongside a specialized Lopez-Dahab ladder for binary curves) to provide a specialized differential addition-and-double implementation to speedup prime curves, while keeping all the features of `ec_scalar_mul_ladder` against SCA attacks. The arithmetic in ladder_pre, ladder_step and ladder_post is auto generated with tooling, from the following formulae: - `ladder_pre`: Formula 3 for doubling from Izu-Takagi "A fast parallel elliptic curve multiplication resistant against side channel attacks", as described at https://hyperelliptic.org/EFD/g1p/auto-shortw-xz.html#doubling-dbl-2002-it-2 - `ladder_step`: differential addition-and-doubling Eq. (8) and (10) from Izu-Takagi "A fast parallel elliptic curve multiplication resistant against side channel attacks", as described at https://hyperelliptic.org/EFD/g1p/auto-shortw-xz.html#ladder-ladd-2002-it-3 - `ladder_post`: y-coordinate recovery using Eq. (8) from Brier-Joye "Weierstrass Elliptic Curves and Side-Channel Attacks", modified to work in projective coordinates. Co-authored-by:
Nicola Tuveri <nic.tuv@gmail.com> Reviewed-by:
-
Andy Polyakov authored
Reviewed-by:
-
Andy Polyakov authored
Reviewed-by:
-
Andy Polyakov authored
New implementation failed to correctly reset r->neg flag. Spotted by OSSFuzz. Reviewed-by:
-
Andy Polyakov authored
Reviewed-by: -
Kurt Roeckx authored
Reviewed-by:Tim Hudson <tjh@openssl.org> GH: #6794
-
Paul Yang authored
Reviewed-by:
Kurt Roeckx <kurt@roeckx.be> Reviewed-by:
-
Kurt Roeckx authored
The old numbers where all generated for an 80 bit security level. But the number should depend on security level you want to reach. For bigger primes we want a higher security level and so need to do more tests. Reviewed-by:
Paul Dale <paul.dale@oracle.com> GH: #6075 Fixes: #6012
-
Kurt Roeckx authored
This changes the security level from 100 to 128 bit. We only have 1 define, this sets it to the highest level supported for DSA, and needed for keys larger than 3072 bit. Reviewed-by:
-
- Jul 25, 2018
-
-
Shane Lontis authored
Reviewed-by:
-
Rich Salz authored
Thanks to Jiecheng Wu, Zuxing Gu for the report. Reviewed-by:
-
Andy Polyakov authored
Problem was that Windows threads that were terminating before libcrypto was initialized were referencing uninitialized or possibly even unrelated thread local storage index. Reviewed-by:
-
Andy Polyakov authored
Reviewed-by:
-
Andy Polyakov authored
Reviewed-by:
-
Andy Polyakov authored
Reviewed-by:
-
Andy Polyakov authored
Reviewed-by:
-
Andy Polyakov authored
|ctx| recently became unconditionally non-NULL and is already dereferenced earlier. Reviewed-by: -
Andy Polyakov authored
Reviewed-by:
-
- Jul 24, 2018
-
-
Richard Levitte authored
This is done by calling die again, just make sure to reset the __DIE__ handler first. Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
David Benjamin authored
A number intended to treat the base as secret should not be branching on whether it is zero. Test-wise, this is covered by existing tests in bnmod.txt. Reviewed-by:
-
Richard Levitte authored
On the same note, change the 'NASM not found' message to give specific advice on how to handle the failure. Fixes #6765 Reviewed-by:
-
neighbads authored
asn1_encode : x, y => 0 | x，0 | y (because of DER encoding rules when x and y have high bit set) CLA: Trivial Reviewed-by:
-
Richard Levitte authored
If there's anything in the |biosk| stack, the first element is always the input BIO. It should never be freed in this function, so we must take careful steps not to do so inadvertently when freeing the stack. Reviewed-by:
-
- Jul 23, 2018
-
-
Andy Polyakov authored
Build jobs keep timing out initializing... Reviewed-by: -
Richard Levitte authored
The result is that we don't have to produce different names on different platforms, and we won't have confusion on Windows depending on if the script was built with mingw or with MSVC. Partial fix for #3254 Reviewed-by:
Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/6764)
-
Matt Caswell authored
In some circumstances it is possible for a client to have a session reporting a max early data value that is greater than the server will support. In such cases the client could encounter an aborted connection. Fixes #6735 Reviewed-by:
-
- Jul 22, 2018
-
-
Andy Polyakov authored
ecp_nistz256_set_from_affine is called when application attempts to use custom generator, i.e. rarely. Even though it was wrong, it didn't affect point operations, they were just not as fast as expected. Reviewed-by:
-
Andy Polyakov authored
The ecp_nistz256_scatter_w7 function is called when application attempts to use custom generator, i.e. rarely. Even though non-x86_64 versions were wrong, it didn't affect point operations, they were just not as fast as expected. Reviewed-by:
-
Andy Polyakov authored
Reviewed-by:
-
Andy Polyakov authored
Reviewed-by:
-
Richard Levitte authored
Fixes #6755 Reviewed-by:
-
Richard Levitte authored
As per RFC 7292. Fixes #6665 Reviewed-by:
-
- Jul 20, 2018
-
-
Benjamin Kaduk authored
The API used to set what SNI value to send in the ClientHello can also be used on server SSL objects, with undocumented and un-useful behavior. Unfortunately, when generic SSL_METHODs are used, s->server is still set, prior to the start of the handshake, so we cannot prevent this nonsensical usage at the present time. Leave a note to revisit this when ABI-breaking changes are permitted. Reviewed-by:
-
Benjamin Kaduk authored
In particular, adhere to the rule that we must not modify any property of an SSL_SESSION object once it is (or might be) in a session cache. Such modifications are thread-unsafe and have been observed to cause crashes at runtime. To effect this change, standardize on the property that SSL_SESSION->ext.hostname is set only when that SNI value has been negotiated by both parties for use with that session. For session resumption this is trivially the case, so only new handshakes are affected. On the client, the new semantics are that the SSL->ext.hostname is for storing the value configured by the caller, and this value is used when constructing the ClientHello. On the server, SSL->ext.hostname is used to hold the value received from the client. Only if the SNI negotiation is successful will the hostname be stored into the session object; the server can do this after it sends the ServerHello, and the client after it has received and processed the ServerHello. This obviates the need to remove the hostname from the session object in case of failed negotiation (a change that was introduced in commit 9fb6cb81 in order to allow TLS 1.3 early data when SNI was present in the ClientHello but not the session being resumed), which was modifying cached sessions in certain cases. (In TLS 1.3 we always produce a new SSL_SESSION object for new connections, even in the case of resumption, so no TLS 1.3 handshakes were affected.) Reviewed-by:
-
