The goal is to minimize maintenance burden by eliminating somewhat
obscure platform-specific tweaks that are not viewed as critical for
contemporary applications. This affects Camellia and digest
implementations that rely on md32_common.h, MD4, MD5, SHA1, SHA256.
SHA256 is the only one that can be viewed as critical, but given
the assembly coverage, the omission is considered appropriate.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6508)
This extends the recently added ECDSA signature blinding to blind DSA too.
This is based on side channel attacks demonstrated by Keegan Ryan (NCC
Group) for ECDSA which are likely to be able to be applied to DSA.
Normally, as in ECDSA, during signing the signer calculates:
s:= k^-1 * (m + r * priv_key) mod order
In ECDSA, 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.
This commit also tweaks the previous ECDSA blinding so that blinding is
only removed at the last possible step.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6522)
This commit implements coordinate blinding, i.e., it randomizes the
representative of an elliptic curve point in its equivalence class, for
prime curves implemented through EC_GFp_simple_method,
EC_GFp_mont_method, and EC_GFp_nist_method.
This commit is derived from the patch
https://marc.info/?l=openssl-dev&m=131194808413635 by Billy Brumley.
Coordinate blinding is a generally useful side-channel countermeasure
and is (mostly) free. The function itself takes a few field
multiplicationss, but is usually only necessary at the beginning of a
scalar multiplication (as implemented in the patch). When used this way,
it makes the values that variables take (i.e., field elements in an
algorithm state) unpredictable.
For instance, this mitigates chosen EC point side-channel attacks for
settings such as ECDH and EC private key decryption, for the
aforementioned curves.
For EC_METHODs using different coordinate representations this commit
does nothing, but the corresponding coordinate blinding function can be
easily added in the future to extend these changes to such curves.
Co-authored-by: Nicola Tuveri <nic.tuv@gmail.com>
Co-authored-by: Billy Brumley <bbrumley@gmail.com>
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6501)
Use EVP_PKEY_set_alias_type to access
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6443)
... 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
