The exponent here is one of d, dmp1, or dmq1 for RSA. This value and its
bit length are both secret. The only public upper bound is the bit width
of the corresponding modulus (RSA n, p, and q, respectively).
Although BN_num_bits is constant-time (sort of; see bn_correct_top notes
in preceding patch), this does not fix the root problem, which is that
the windows are based on the minimal bit width, not the upper bound. We
could use BN_num_bits(m), but BN_mod_exp_mont_consttime is public API
and may be called with larger exponents. Instead, use all top*BN_BITS2
bits in the BIGNUM. This is still sensitive to the long-standing
bn_correct_top leak, but we need to fix that regardless.
This may cause us to do a handful of extra multiplications for RSA keys
which are just above a whole number of words, but that is not a standard
RSA key size.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5154)
All exponentiation subroutines but BN_mod_exp_mont_consttime produce
non-negative result for negative input, which is confusing for fuzzer.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/4676)
Since return is inconsistent, I removed unnecessary parentheses and
unified them.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4541)
RSA_setup_blinding() calls BN_BLINDING_create_param() which later calls
BN_mod_exp() as follows:
BN_mod_exp(ret->A, ret->A, ret->e, ret->mod, ctx)
ret->mod will have BN_FLG_CONSTTIME set, but ret->e does not. In
BN_mod_exp() we only test the third param for the existence of this flag.
We should test all the inputs.
Thanks to Samuel Weiser (samuel.weiser@iaik.tugraz.at) for reporting this
issue.
This typically only happens once at key load, so this is unlikely to be
exploitable in any real scenario.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4477)
To make it consistent in the code base
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/3749)
Factorise multiple bn_get_top(group->field) calls
Add missing checks on some conditional BN_copy return value
Add missing checks on some BN_copy return value
Add missing checks on a few bn_wexpand return value
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1626)
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1264)
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 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>
This was done by the following
find . -name '*.[ch]' | /tmp/pl
where /tmp/pl is the following three-line script:
print unless $. == 1 && m@/\* .*\.[ch] \*/@;
close ARGV if eof; # Close file to reset $.
And then some hand-editing of other files.
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Some URLs in the source code ended up getting mangled by indent. This fixes
it. Based on a patch supplied by Arnaud Lacombe <al@aerilon.ca>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Commit 2b0180c37f attempted to do this but
only hit one of many BN_mod_exp codepaths. Fix remaining variants and add
a test for each method.
Thanks to Hanno Boeck for reporting this issue.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Dr. Stephen Henson <steve@openssl.org>
Don't dereference |d| when |top| is zero. Also test that various BIGNUM methods behave correctly on zero/even inputs.
Follow-up to b11980d79a
Reviewed-by: Rich Salz <rsalz@openssl.org>
A small rearrangement so the inclusion of rsaz_exp.h would be
unconditional, but what that header defines becomes conditional.
This solves the weirdness where rsaz_exp.h gets in and out of the
dependency list for bn_exp.c, depending on the present architecture.
Reviewed-by: Rich Salz <rsalz@openssl.org>
There are header files in crypto/ that are used by a number of crypto/
submodules. Move those to crypto/include/internal and adapt the
affected source code and Makefiles.
The header files that got moved are:
crypto/cryptolib.h
crypto/md32_common.h
Reviewed-by: Rich Salz <rsalz@openssl.org>
This gets BN_.*free:
BN_BLINDING_free BN_CTX_free BN_FLG_FREE BN_GENCB_free
BN_MONT_CTX_free BN_RECP_CTX_free BN_clear_free BN_free BUF_MEM_free
Also fix a call to DSA_SIG_free to ccgost engine and remove some #ifdef'd
dead code in engines/e_ubsec.
Reviewed-by: Richard Levitte <levitte@openssl.org>
In the event of an error |rr| could be NULL. Therefore don't assume you can
use |rr| in the error handling code.
Reviewed-by: Andy Polyakov <appro@openssl.org>
It's not clear whether this inconsistency could lead to an actual
computation error, but it involved a BIGNUM being passed around the
montgomery logic in an inconsistent state. This was found using flags
-DBN_DEBUG -DBN_DEBUG_RAND, and working backwards from this assertion
in 'ectest';
ectest: bn_mul.c:960: BN_mul: Assertion `(_bnum2->top == 0) ||
(_bnum2->d[_bnum2->top - 1] != 0)' failed
Signed-off-by: Geoff Thorpe <geoff@openssl.org>
Improve RSA sing performance by 20-30% by:
- switching from floating-point to integer conditional moves;
- daisy-chaining sqr-sqr-sqr-sqr-sqr-mul sequences;
- using MONTMUL even during powers table setup;
x86_64 platform. It targets specifically RSA1024 sign (using ideas
from http://eprint.iacr.org/2011/239) and adds more than 10% on most
platforms. Overall performance improvement relative to 1.0.0 is ~40%
in average, with best result of 54% on Westmere. Incidentally ~40%
is average improvement even for longer key lengths.
knock-on work than expected - they've been extracted into a patch
series that can be completed elsewhere, or in a different branch,
before merging back to HEAD.
