... to the check OPENSSL_API_COMPAT < 0x10100000L, to correspond with
how it's declared.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6470)
Calling the functions rand_pool_add_{additional,nonce}_data()
in crypto/rand/rand_lib.c with no implementation for djgpp/MSDOS
causees unresolved symbols when linking with djgpp.
Reported and fixed by Gisle Vanem
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6421)
848113a30b added mitigation for a
side-channel attack. This commit extends approach to all code
paths for consistency.
[It also removes redundant white spaces introduced in last commit.]
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6480)
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: Rich Salz <rsalz@openssl.org>
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: Rich Salz <rsalz@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6457)
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: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6440)
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: Rich Salz <rsalz@openssl.org>
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/6436)
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: Rich Salz <rsalz@openssl.org>
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/6436)
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 <appro@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/6420)
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: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6435)
EVP_PKEY_asn1_set_get_priv_key() and EVP_PKEY_asn1_set_get_pub_key()
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6394)
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: Rich Salz <rsalz@openssl.org>
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6394)
There were a large number of error codes that were unused (probably a
copy&paste from somewhere else). Since these have never been made public
we should remove then and rebuild the error codes.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6386)
Biggest part, ~7%, of improvement resulted from omitting constants'
table index increment in each round. And minor part from rescheduling
instructions. Apparently POWER9 (and POWER8) manage to dispatch
instructions more efficiently if they are laid down as if they have
no latency...
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6406)
This comes at cost of minor 2.5% regression on G4, which is reasonable
trade-off. [Further improve compliance with ABI requirements.]
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6406)
As it turns out originally published results were skewed by "turbo"
mode. VM apparently remains oblivious to dynamic frequency scaling,
and reports that processor operates at "base" frequency at all times.
While actual frequency gets increased under load.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6406)
OPENSSL_memcmp is a must in GCM decrypt and general-purpose loop takes
quite a portion of execution time for short inputs, more than GHASH for
few-byte inputs according to profiler. Special 16-byte case takes it off
top five list in profiler output.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6312)
On contemporary platforms assembly GHASH processes multiple blocks
faster than one by one. For TLS payloads shorter than 16 bytes, e.g.
alerts, it's possible to reduce hashing operation to single call.
And for block lengths not divisible by 16 - fold two final calls to
one. Improvement is most noticeable with "reptoline", because call to
assembly GHASH is indirect.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6312)
Even though calls can be viewed as styling improvement, they do come
with cost. It's not big cost and shows only on short inputs, but it is
measurable, 2-3% on some platforms.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6312)
Only Linux and FreeBSD provide getrandom(), but they both also provide
getentropy() since the same version and we already tried to call that.
Reviewed-by: Andy Polyakov <appro@openssl.org>
GH: #6405
This will actually support most OSs, and at least adds support for
Solaris and OSX
Fixes: #6403
Reviewed-by: Andy Polyakov <appro@openssl.org>
GH: #6405
Just because an engine implements algorithm methods, that doesn't mean
it also implements the ASN1 method. Therefore, be careful when looking
for an ASN1 method among all engines, don't try to use one that doesn't
exist.
Fixes#6381
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6383)
(cherry picked from commit 1ac3cd6277)
(cherry picked from commit 13b578ada3)
Found by coverity. This is an artifact left over from the original
decaf import which generated the source code for different curves. For
curve 448 this is dead.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6373)
In `aes_wrap_cipher()`, the minimal out buff length is `(inlen - 8)`.
Since it calls `CRYPTO_128_unwrap_pad()` underneath, it makes sense to
reduce the minimal out length in `CRYPTO_128_unwrap_pad()` to align to
its caller.
Signed-off-by: Yihong Wang <yh.wang@ibm.com>
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6266)
The One&Done attack, which is described in a paper to appear in the
USENIX Security'18 conference, uses EM emanations to recover the values
of the bits that are obtained using BN_is_bit_set while constructing
the value of the window in BN_mod_exp_consttime. The EM signal changes
slightly depending on the value of the bit, and since the lookup of a
bit is surrounded by highly regular execution (constant-time Montgomery
multiplications) the attack is able to isolate the (very brief) part of
the signal that changes depending on the bit. Although the change is
slight, the attack recovers it successfully >90% of the time on several
phones and IoT devices (all with ARM processors with clock rates around
1GHz), so after only one RSA decryption more than 90% of the bits in
d_p and d_q are recovered correctly, which enables rapid recovery of
the full RSA key using an algorithm (also described in the paper) that
modifies the branch-and-prune approach for a situation in which the
exponents' bits are recovered with errors, i.e. where we do not know
a priori which bits are correctly recovered.
The mitigation for the attack is relatively simple - all the bits of
the window are obtained at once, along with other bits so that an
entire integer's worth of bits are obtained together using masking and
shifts, without unnecessarily considering each bit in isolation. This
improves performance somewhat (one call to bn_get_bits is faster than
several calls to BN_is_bit_set), so the attacker now gets one signal
snippet per window (rather than one per bit) in which the signal is
affected by all bits in the integer (rather than just the one bit).
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6276)
