- 14 Jun, 2018 2 commits
-
-
Andy Polyakov authored
Reviewed-by:
Rich Salz <rsalz@openssl.org> Reviewed-by:
Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/6477)
-
Andy Polyakov authored
Reviewed-by:
-
- 13 Jun, 2018 7 commits
-
-
Eric S. Raymond authored
CLA: trivial Reviewed-by:
Kurt Roeckx <kurt@roeckx.be> Reviewed-by:
-
Matt Caswell authored
Keegan Ryan (NCC Group) has demonstrated a side channel attack on an ECDSA signature operation. During signing the signer calculates: s:= k^-1 * (m + r * priv_key) mod order The addition operation above provides a sufficient signal for a flush+reload attack to derive the private key given sufficient signature operations. As a mitigation (based on a suggestion from Keegan) we add blinding to the operation so that: s := k^-1 * blind^-1 (blind * m + blind * r * priv_key) mod order Since this attack is a localhost side channel only no CVE is assigned. Reviewed-by: -
Andy Polyakov authored
[omit even -b:SRE, as it's implied by -G flag.] Reviewed-by:
-
Andy Polyakov authored
Add aix-common template that covers even aix-shared from shared-info.pl, add -bsymbolic to shared_ldflags. Reviewed-by:
-
Andy Polyakov authored
This allows to specify flags specific to shared build, e.g. 'bin_lflags => shared("-Wl,-bsvr4")'. Reviewed-by: -
Andy Polyakov authored
The flag was apparently omitted in switch from Makefile.shared to shared-info.pl. Do put it back! And in the process move all solaris-shared flags from shared-info.pl to solaris-common. Reviewed-by:
-
Richard Levitte authored
The man name didn't match the file name, and some places had 'password' instead of 'pass phrase'. Fixes #6474 Reviewed-by:
-
- 12 Jun, 2018 7 commits
-
-
Viktor Dukhovni authored
and also X509_delete_ext() Reviewed-by:Matt Caswell <matt@openssl.org>
-
Nicola Tuveri authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
Tim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/6461)
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
There was no option to give other config files than the default crypto/err/openssl.ec, and yet it tried to check the errors generated in engines (and failing, of course). Also added the same '-internal' option as util/mkerr.pl. Reviewed-by:
-
Guido Vranken authored
CVE-2018-0732 Signed-off-by:
Guido Vranken <guidovranken@gmail.com> Reviewed-by:
Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> Reviewed-by:
Viktor Dukhovni <viktor@openssl.org> Reviewed-by:
-
- 11 Jun, 2018 7 commits
-
-
Richard Levitte authored
The list of known libs are readily available in crypto/err/openssl.ec, so lets use it to figure out if all error function codes belong to known libs. Reviewed-by:
-
David von Oheimb authored
Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
Andy Polyakov <appro@openssl.org> (Merged from https://github.com/openssl/openssl/pull/6370)
-
Matt Caswell authored
TLSv1.3 ignores the alert level, so we should suppress sending of warning only alerts. Fixes #6211 Reviewed-by:
-
Matt Caswell authored
In TLSv1.3 we should ignore the severity level of an alert according to the spec. Reviewed-by:
-
Richard Levitte authored
Fixes #6449 Reviewed-by:
-
Todd Short authored
Reviewed-by:
Paul Dale <paul.dale@oracle.com> Reviewed-by:
-
- 09 Jun, 2018 3 commits
-
-
Andy Polyakov authored
This module is used only with odd input lengths, i.e. not used in normal PKI cases, on contemporary processors. The problem was "illuminated" by fuzzing tests. Reviewed-by:
-
Andy Polyakov authored
If built with no-dso, syscall_random remains "blind" to getentropy. Since it's possible to detect symbol availability on ELF-based systems without involving DSO module, bypass it. Reviewed-by:
-
Andy Polyakov authored
If built with no-dso, DSO_global_lookup leaves "unsupported" message in error queue. Since there is a fall-back code, it's unnecessary distraction. Reviewed-by:
-
- 08 Jun, 2018 10 commits
-
-
Dmitry Belyavskiy authored
Reviewed-by:
-
Dmitry Belyavskiy authored
Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Andy Polyakov authored
Move ios targets to 15-ios.conf and modernize by deploying xcrun. This excuses user from looking for paths and setting environment variables. [Thanks to @0neday for hint.] Reviewed-by:
-
Mingtao Yang authored
Upon a call to CRYPTO_ocb128_setiv, either directly on an OCB_CTX or indirectly with EVP_CTRL_AEAD_SET_IVLEN, reset the nonce-dependent variables in the OCB_CTX. Reviewed-by:
-
Andy Polyakov authored
It's kind of a "brown-bag" bug, as I did recognize the problem and verified an ad-hoc solution, but failed to follow up with cross-checks prior filing previous merge request. Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
EVP_PKEY_asn1_set_get_priv_key() and EVP_PKEY_asn1_set_get_pub_key() Reviewed-by:
-
Matt Caswell authored
EVP_PKEY_get_raw_private_key() and EVP_PKEY_get_raw_public_key() Reviewed-by:
-
Matt Caswell authored
Only applies to algorithms that support it. Both raw private and public keys can be obtained for X25519, Ed25519, X448, Ed448. Raw private keys only can be obtained for HMAC, Poly1305 and SipHash Fixes #6259 Reviewed-by:
-
- 07 Jun, 2018 4 commits
-
-
Marcus Huewe authored
If the remove_session_cb accesses the session's data (for instance, via SSL_SESSION_get_protocol_version), a potential use after free can occur. For this, consider the following scenario when adding a new session via SSL_CTX_add_session: - The session cache is full (SSL_CTX_sess_number(ctx) > SSL_CTX_sess_get_cache_size(ctx)) - Only the session cache has a reference to ctx->session_cache_tail (that is, ctx->session_cache_tail->references == 1) Since the cache is full, remove_session_lock is called to remove ctx->session_cache_tail from the cache. That is, it SSL_SESSION_free()s the session, which free()s the data. Afterwards, the free()d session is passed to the remove_session_cb. If the callback accesses the session's data, we have a use after free. The free before calling the callback behavior was introduced in commit e4612d02 ("Remove sessions from external cache, even if internal cache not used."). CLA: trivial Reviewed-by:
-
Richard Levitte authored
After some discussion, it was concluded that the better idea is to stipulate that the pass phrases passed to the OSSL_STORE API are expected to be UTF-8 encoded, and that all objects made accessible through OSSL_STORE URIs should adhere to this expectation (at the discretion of the loaders). Email ref: https://mta.openssl.org/pipermail/openssl-project/2018-June/000771.html Reviewed-by:
-
Matt Caswell authored
Improves readability Reviewed-by:
-
Matt Caswell authored
We generate the secrets based on the nonce immediately so there is no need to keep the nonce. Reviewed-by:
-
