PVK files with abnormally large length or salt fields can cause an
integer overflow which can result in an OOB read and heap corruption.
However this is an rarely used format and private key files do not
normally come from untrusted sources the security implications not
significant.
Fix by limiting PVK length field to 100K and salt to 10K: these should be
more than enough to cover any files encountered in practice.
Issue reported by Guido Vranken.
Reviewed-by: Rich Salz <rsalz@openssl.org>
This patch implements the HMAC-based Extract-and-Expand Key Derivation
Function (HKDF) as defined in RFC 5869.
It is required to implement the QUIC and TLS 1.3 protocols (among others).
Signed-off-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Dr. Stephen Henson <steve@openssl.org>
- Remove OPENSSL_X25519_X86_64 which never worked, because we don't have
the assembly.
- Also remove OPENSSL_SMALL (which should have been
OPENSSL_SMALL_FOOTPRINT) which isn't a priority at the moment.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Handle KDF in ECDH_compute_key instead of requiring each implementation
support it. This modifies the compute_key method: now it allocates and
populates a buffer containing the shared secret.
Reviewed-by: Rich Salz <rsalz@openssl.org>
There are cases, for example when configuring no-asm, that the added
uplink source files got in the way of the cpuid ones. The best way to
solve this is to separate the two.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Formally only 32-bit AVX2 code path needs this, but I choose to
harmonize all vector code paths.
RT#4346
Reviewed-by: Richard Levitte <levitte@openssl.org>
Most of the assembly uses constants from arm_arch.h, but a few references to
ARMV7_NEON don't. Consistently use the macros everywhere.
Signed-off-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
Instead of overriding a default operation move default operation to a
separate function which is then explicitly included in any EC_METHOD
that uses it.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Specifies a callback that will, in the future, be used by the SSL code to
decide whether to abort a connection on Certificate Transparency grounds.
Reviewed-by: Ben Laurie <ben@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
The HOST_c2l() macro assigns the value to the specified variable, but also
evaluates to the same value. Which we ignore, triggering a warning.
To fix this, just cast it to void like we did in commit 08e553644
("Fix some clang warnings.") for a bunch of other instances.
Signed-off-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Andy Polyakov <appro@openssl.org>
and reorganize/harmonize post-conditions.
Additional hardening following on from CVE-2016-0702
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
At the same time remove miniscule bias in final subtraction.
Performance penalty varies from platform to platform, and even with
key length. For rsa2048 sign it was observed to be 4% for Sandy
Bridge and 7% on Broadwell.
CVE-2016-0702
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
Performance penalty is 2% on Linux and 5% on Windows.
CVE-2016-0702
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
Performance penalty varies from platform to platform, and even
key length. For rsa2048 sign it was observed to reach almost 10%.
CVE-2016-0702
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
In the BN_hex2bn function the number of hex digits is calculated using
an int value |i|. Later |bn_expand| is called with a value of |i * 4|.
For large values of |i| this can result in |bn_expand| not allocating any
memory because |i * 4| is negative. This leaves ret->d as NULL leading
to a subsequent NULL ptr deref. For very large values of |i|, the
calculation |i * 4| could be a positive value smaller than |i|. In this
case memory is allocated to ret->d, but it is insufficiently sized
leading to heap corruption. A similar issue exists in BN_dec2bn.
This could have security consequences if BN_hex2bn/BN_dec2bn is ever
called by user applications with very large untrusted hex/dec data. This is
anticipated to be a rare occurrence.
All OpenSSL internal usage of this function uses data that is not expected
to be untrusted, e.g. config file data or application command line
arguments. If user developed applications generate config file data based
on untrusted data then it is possible that this could also lead to security
consequences. This is also anticipated to be a rare.
Issue reported by Guido Vranken.
CVE-2016-0797
Reviewed-by: Andy Polyakov <appro@openssl.org>
Clarify that the "cleanup" routing does not get called if you invoke
ASYNC_WAIT_CTX_clear_fd() directly.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Implementation experience has shown that the original plan for async wait
fds was too simplistic. Originally the async logic created a pipe internally
and user/engine code could then get access to it via API calls. It is more
flexible if the engine is able to create its own fd and provide it to the
async code.
Another issue is that there can be a lot of churn in the fd value within
the context of (say) a single SSL connection leading to continually adding
and removing fds from (say) epoll. It is better if we can provide some
stability of the fd value across a whole SSL connection. This is
problematic because an engine has no concept of an SSL connection.
This commit refactors things to introduce an ASYNC_WAIT_CTX which acts as a
proxy for an SSL connection down at the engine layer.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Add X25519 to TLS supported curve list.
Reject attempts to configure keys which cannot be used
for signing.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Emilia Käsper <emilia@openssl.org>
Add a flag to EC_METHOD for curves which do not support signing.
New function EC_KEY_can_sign() returns 1 is key can be used for signing.
Return an explicit error is an attempt is made to sign with
no signing curves.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Emilia Käsper <emilia@openssl.org>
In some cases the EC_POINT and EC_KEY BIGNUM components are suboptimal
or inappropriate. Add an "custom_data" field which curves can populate with
a custom structure to suit their needs.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Emilia Käsper <emilia@openssl.org>
Extract compression form in EC_KEY_oct2key() instead of manually in the
ASN.1 code. For custom curves do not assume the initial octet is the
compression form: it isn't for X25519 et al.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Emilia Käsper <emilia@openssl.org>
