2014-06-20 20:00:00 +01:00
|
|
|
/* Copyright (C) 1995-1998 Eric Young (eay@cryptsoft.com)
|
|
|
|
* All rights reserved.
|
|
|
|
*
|
|
|
|
* This package is an SSL implementation written
|
|
|
|
* by Eric Young (eay@cryptsoft.com).
|
|
|
|
* The implementation was written so as to conform with Netscapes SSL.
|
|
|
|
*
|
|
|
|
* This library is free for commercial and non-commercial use as long as
|
|
|
|
* the following conditions are aheared to. The following conditions
|
|
|
|
* apply to all code found in this distribution, be it the RC4, RSA,
|
|
|
|
* lhash, DES, etc., code; not just the SSL code. The SSL documentation
|
|
|
|
* included with this distribution is covered by the same copyright terms
|
|
|
|
* except that the holder is Tim Hudson (tjh@cryptsoft.com).
|
|
|
|
*
|
|
|
|
* Copyright remains Eric Young's, and as such any Copyright notices in
|
|
|
|
* the code are not to be removed.
|
|
|
|
* If this package is used in a product, Eric Young should be given attribution
|
|
|
|
* as the author of the parts of the library used.
|
|
|
|
* This can be in the form of a textual message at program startup or
|
|
|
|
* in documentation (online or textual) provided with the package.
|
|
|
|
*
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
* modification, are permitted provided that the following conditions
|
|
|
|
* are met:
|
|
|
|
* 1. Redistributions of source code must retain the copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer.
|
|
|
|
* 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer in the
|
|
|
|
* documentation and/or other materials provided with the distribution.
|
|
|
|
* 3. All advertising materials mentioning features or use of this software
|
|
|
|
* must display the following acknowledgement:
|
|
|
|
* "This product includes cryptographic software written by
|
|
|
|
* Eric Young (eay@cryptsoft.com)"
|
|
|
|
* The word 'cryptographic' can be left out if the rouines from the library
|
|
|
|
* being used are not cryptographic related :-).
|
|
|
|
* 4. If you include any Windows specific code (or a derivative thereof) from
|
|
|
|
* the apps directory (application code) you must include an acknowledgement:
|
|
|
|
* "This product includes software written by Tim Hudson (tjh@cryptsoft.com)"
|
|
|
|
*
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY ERIC YOUNG ``AS IS'' AND
|
|
|
|
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
|
|
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
|
|
|
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
|
|
|
|
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
|
|
|
|
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
|
|
|
|
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
|
|
|
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
|
|
|
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
|
|
|
|
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
|
|
|
|
* SUCH DAMAGE.
|
|
|
|
*
|
|
|
|
* The licence and distribution terms for any publically available version or
|
|
|
|
* derivative of this code cannot be changed. i.e. this code cannot simply be
|
|
|
|
* copied and put under another distribution licence
|
|
|
|
* [including the GNU Public Licence.] */
|
|
|
|
|
|
|
|
#include <openssl/bn.h>
|
|
|
|
|
|
|
|
#include <limits.h>
|
2015-01-31 01:08:37 +00:00
|
|
|
#include <string.h>
|
|
|
|
|
2014-06-20 20:00:00 +01:00
|
|
|
#include <openssl/err.h>
|
|
|
|
#include <openssl/mem.h>
|
|
|
|
|
|
|
|
#include "internal.h"
|
2017-04-28 22:47:06 +01:00
|
|
|
#include "../delocate.h"
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
BIGNUM *BN_new(void) {
|
|
|
|
BIGNUM *bn = OPENSSL_malloc(sizeof(BIGNUM));
|
|
|
|
|
|
|
|
if (bn == NULL) {
|
2015-06-29 05:28:17 +01:00
|
|
|
OPENSSL_PUT_ERROR(BN, ERR_R_MALLOC_FAILURE);
|
2014-06-20 20:00:00 +01:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2016-12-13 06:07:13 +00:00
|
|
|
OPENSSL_memset(bn, 0, sizeof(BIGNUM));
|
2014-06-20 20:00:00 +01:00
|
|
|
bn->flags = BN_FLG_MALLOCED;
|
|
|
|
|
|
|
|
return bn;
|
|
|
|
}
|
|
|
|
|
|
|
|
void BN_init(BIGNUM *bn) {
|
2016-12-13 06:07:13 +00:00
|
|
|
OPENSSL_memset(bn, 0, sizeof(BIGNUM));
|
2014-06-20 20:00:00 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
void BN_free(BIGNUM *bn) {
|
|
|
|
if (bn == NULL) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2015-04-22 18:50:28 +01:00
|
|
|
if ((bn->flags & BN_FLG_STATIC_DATA) == 0) {
|
2014-06-20 20:00:00 +01:00
|
|
|
OPENSSL_free(bn->d);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (bn->flags & BN_FLG_MALLOCED) {
|
|
|
|
OPENSSL_free(bn);
|
|
|
|
} else {
|
|
|
|
bn->d = NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void BN_clear_free(BIGNUM *bn) {
|
|
|
|
char should_free;
|
|
|
|
|
|
|
|
if (bn == NULL) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (bn->d != NULL) {
|
|
|
|
if ((bn->flags & BN_FLG_STATIC_DATA) == 0) {
|
|
|
|
OPENSSL_free(bn->d);
|
2017-08-30 18:49:05 +01:00
|
|
|
} else {
|
|
|
|
OPENSSL_cleanse(bn->d, bn->dmax * sizeof(bn->d[0]));
|
2014-06-20 20:00:00 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
should_free = (bn->flags & BN_FLG_MALLOCED) != 0;
|
|
|
|
if (should_free) {
|
|
|
|
OPENSSL_free(bn);
|
2017-08-30 18:49:05 +01:00
|
|
|
} else {
|
|
|
|
OPENSSL_cleanse(bn, sizeof(BIGNUM));
|
2014-06-20 20:00:00 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
BIGNUM *BN_dup(const BIGNUM *src) {
|
|
|
|
BIGNUM *copy;
|
|
|
|
|
|
|
|
if (src == NULL) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
copy = BN_new();
|
|
|
|
if (copy == NULL) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!BN_copy(copy, src)) {
|
|
|
|
BN_free(copy);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return copy;
|
|
|
|
}
|
|
|
|
|
|
|
|
BIGNUM *BN_copy(BIGNUM *dest, const BIGNUM *src) {
|
|
|
|
if (src == dest) {
|
|
|
|
return dest;
|
|
|
|
}
|
|
|
|
|
2018-01-15 10:23:24 +00:00
|
|
|
if (!bn_wexpand(dest, src->width)) {
|
2014-06-20 20:00:00 +01:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2018-01-15 10:23:24 +00:00
|
|
|
OPENSSL_memcpy(dest->d, src->d, sizeof(src->d[0]) * src->width);
|
2014-06-20 20:00:00 +01:00
|
|
|
|
2018-01-15 10:23:24 +00:00
|
|
|
dest->width = src->width;
|
2014-06-20 20:00:00 +01:00
|
|
|
dest->neg = src->neg;
|
|
|
|
return dest;
|
|
|
|
}
|
|
|
|
|
|
|
|
void BN_clear(BIGNUM *bn) {
|
|
|
|
if (bn->d != NULL) {
|
2016-12-13 06:07:13 +00:00
|
|
|
OPENSSL_memset(bn->d, 0, bn->dmax * sizeof(bn->d[0]));
|
2014-06-20 20:00:00 +01:00
|
|
|
}
|
|
|
|
|
2018-01-15 10:23:24 +00:00
|
|
|
bn->width = 0;
|
2014-06-20 20:00:00 +01:00
|
|
|
bn->neg = 0;
|
|
|
|
}
|
|
|
|
|
2017-04-28 22:47:06 +01:00
|
|
|
DEFINE_METHOD_FUNCTION(BIGNUM, BN_value_one) {
|
2015-11-18 08:00:09 +00:00
|
|
|
static const BN_ULONG kOneLimbs[1] = { 1 };
|
2017-04-28 22:47:06 +01:00
|
|
|
out->d = (BN_ULONG*) kOneLimbs;
|
2018-01-15 10:23:24 +00:00
|
|
|
out->width = 1;
|
2017-04-28 22:47:06 +01:00
|
|
|
out->dmax = 1;
|
|
|
|
out->neg = 0;
|
|
|
|
out->flags = BN_FLG_STATIC_DATA;
|
2014-06-20 20:00:00 +01:00
|
|
|
}
|
|
|
|
|
2017-08-18 19:06:02 +01:00
|
|
|
// BN_num_bits_word returns the minimum number of bits needed to represent the
|
|
|
|
// value in |l|.
|
2014-06-20 20:00:00 +01:00
|
|
|
unsigned BN_num_bits_word(BN_ULONG l) {
|
Make BN_num_bits_word constant-time.
(The BN_num_bits_word implementation was originally written by Andy
Polyakov for OpenSSL. See also
https://github.com/openssl/openssl/pull/5154.)
BN_num_bits, by way of BN_num_bits_word, currently leaks the
most-significant word of its argument via branching and memory access
pattern.
BN_num_bits is called on RSA prime factors in various places. These have
public bit lengths, but all bits beyond the high bit are secret. This
fully resolves those cases.
There are a few places where BN_num_bits is called on an input where
the bit length is also secret. The two left in BoringSSL are:
- BN_mod_exp_mont_consttime calls it on the RSA private exponent.
- The timing "fix" to add the order to k in DSA.
This does *not* fully resolve those cases as we still only look at the
top word. Today, that is guaranteed to be non-zero, but only because of
the long-standing bn_correct_top timing leak. Once that is fixed (I hope
to have patches soon), a constant-time BN_num_bits on such inputs must
count bits on each word.
Instead, those cases should not call BN_num_bits at all. The former uses
the bit width to pick windows, but it should be using the maximum bit
width. The next patch will fix this. The latter is the same "fix" we
excised from ECDSA in a838f9dc7e6cc091237f0acbbe4953104104e815. That
should be excised from DSA after the bn_correct_top bug is fixed.
Thanks to Dinghao Wu, Danfeng Zhang, Shuai Wang, Pei Wang, and Xiao Liu
for reporting this issue.
Change-Id: Idc3da518cc5ec18bd8688b95f959b15300a57c14
Reviewed-on: https://boringssl-review.googlesource.com/25184
Reviewed-by: Adam Langley <agl@google.com>
2018-01-22 15:44:50 +00:00
|
|
|
// |BN_num_bits| is often called on RSA prime factors. These have public bit
|
|
|
|
// lengths, but all bits beyond the high bit are secret, so count bits in
|
|
|
|
// constant time.
|
|
|
|
BN_ULONG x, mask;
|
|
|
|
int bits = (l != 0);
|
|
|
|
|
|
|
|
#if BN_BITS2 > 32
|
|
|
|
x = l >> 32;
|
|
|
|
mask = 0u - x;
|
|
|
|
mask = (0u - (mask >> (BN_BITS2 - 1)));
|
|
|
|
bits += 32 & mask;
|
|
|
|
l ^= (x ^ l) & mask;
|
2014-06-20 20:00:00 +01:00
|
|
|
#endif
|
Make BN_num_bits_word constant-time.
(The BN_num_bits_word implementation was originally written by Andy
Polyakov for OpenSSL. See also
https://github.com/openssl/openssl/pull/5154.)
BN_num_bits, by way of BN_num_bits_word, currently leaks the
most-significant word of its argument via branching and memory access
pattern.
BN_num_bits is called on RSA prime factors in various places. These have
public bit lengths, but all bits beyond the high bit are secret. This
fully resolves those cases.
There are a few places where BN_num_bits is called on an input where
the bit length is also secret. The two left in BoringSSL are:
- BN_mod_exp_mont_consttime calls it on the RSA private exponent.
- The timing "fix" to add the order to k in DSA.
This does *not* fully resolve those cases as we still only look at the
top word. Today, that is guaranteed to be non-zero, but only because of
the long-standing bn_correct_top timing leak. Once that is fixed (I hope
to have patches soon), a constant-time BN_num_bits on such inputs must
count bits on each word.
Instead, those cases should not call BN_num_bits at all. The former uses
the bit width to pick windows, but it should be using the maximum bit
width. The next patch will fix this. The latter is the same "fix" we
excised from ECDSA in a838f9dc7e6cc091237f0acbbe4953104104e815. That
should be excised from DSA after the bn_correct_top bug is fixed.
Thanks to Dinghao Wu, Danfeng Zhang, Shuai Wang, Pei Wang, and Xiao Liu
for reporting this issue.
Change-Id: Idc3da518cc5ec18bd8688b95f959b15300a57c14
Reviewed-on: https://boringssl-review.googlesource.com/25184
Reviewed-by: Adam Langley <agl@google.com>
2018-01-22 15:44:50 +00:00
|
|
|
|
|
|
|
x = l >> 16;
|
|
|
|
mask = 0u - x;
|
|
|
|
mask = (0u - (mask >> (BN_BITS2 - 1)));
|
|
|
|
bits += 16 & mask;
|
|
|
|
l ^= (x ^ l) & mask;
|
|
|
|
|
|
|
|
x = l >> 8;
|
|
|
|
mask = 0u - x;
|
|
|
|
mask = (0u - (mask >> (BN_BITS2 - 1)));
|
|
|
|
bits += 8 & mask;
|
|
|
|
l ^= (x ^ l) & mask;
|
|
|
|
|
|
|
|
x = l >> 4;
|
|
|
|
mask = 0u - x;
|
|
|
|
mask = (0u - (mask >> (BN_BITS2 - 1)));
|
|
|
|
bits += 4 & mask;
|
|
|
|
l ^= (x ^ l) & mask;
|
|
|
|
|
|
|
|
x = l >> 2;
|
|
|
|
mask = 0u - x;
|
|
|
|
mask = (0u - (mask >> (BN_BITS2 - 1)));
|
|
|
|
bits += 2 & mask;
|
|
|
|
l ^= (x ^ l) & mask;
|
|
|
|
|
|
|
|
x = l >> 1;
|
|
|
|
mask = 0u - x;
|
|
|
|
mask = (0u - (mask >> (BN_BITS2 - 1)));
|
|
|
|
bits += 1 & mask;
|
|
|
|
|
|
|
|
return bits;
|
2014-06-20 20:00:00 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
unsigned BN_num_bits(const BIGNUM *bn) {
|
Add initial support for non-minimal BIGNUMs.
Thanks to Andres Erbsen for extremely helpful suggestions on how finally
plug this long-standing hole!
OpenSSL BIGNUMs are currently minimal-width, which means they cannot be
constant-time. We'll need to either excise BIGNUM from RSA and EC or
somehow fix BIGNUM. EC_SCALAR and later EC_FELEM work will excise it
from EC, but RSA's BIGNUMs are more transparent. Teaching BIGNUM to
handle non-minimal word widths is probably simpler.
The main constraint is BIGNUM's large "calculator" API surface. One
could, in theory, do arbitrary math on RSA components, which means all
public functions must tolerate non-minimal inputs. This is also useful
for EC; https://boringssl-review.googlesource.com/c/boringssl/+/24445 is
silly.
As a first step, fix comparison-type functions that were assuming
minimal BIGNUMs. I've also added bn_resize_words, but it is testing-only
until the rest of the library is fixed.
bn->top is now a loose upper bound we carry around. It does not affect
numerical results, only performance and secrecy. This is a departure
from the original meaning, and compiler help in auditing everything is
nice, so the final change in this series will rename bn->top to
bn->width. Thus these new functions are named per "width", not "top".
Looking further ahead, how are output BIGNUM widths determined? There's
three notions of correctness here:
1. Do I compute the right answer for all widths?
2. Do I handle secret data in constant time?
3. Does my memory usage not balloon absurdly?
For (1), a BIGNUM function must give the same answer for all input
widths. BN_mod_add_quick may assume |a| < |m|, but |a| may still be
wider than |m| by way of leading zeres. The simplest approach is to
write code in a width-agnostic way and rely on functions to accept all
widths. Where functions need to look at bn->d, we'll a few helper
functions to smooth over funny widths.
For (2), (1) is little cumbersome. Consider constant-time modular
addition. A sane type system would guarantee input widths match. But C
is weak here, and bifurcating the internals is a lot of work. Thus, at
least for now, I do not propose we move RSA's internal computation out
of BIGNUM. (EC_SCALAR/EC_FELEM are valuable for EC because we get to
stack-allocate, curves were already specialized, and EC only has two
types with many operations on those types. None of these apply to RSA.
We've got numbers mod n, mod p, mod q, and their corresponding
exponents, each of which is used for basically one operation.)
Instead, constant-time BIGNUM functions will output non-minimal widths.
This is trivial for BN_bin2bn or modular arithmetic. But for BN_mul,
constant-time[*] would dictate r->top = a->top + b->top. A calculator
repeatedly multiplying by one would then run out of memory. Those we'll
split into a private BN_mul_fixed for crypto, leaving BN_mul for
calculators. BN_mul is just BN_mul_fixed followed by bn_correct_top.
[*] BN_mul is not constant-time for other reasons, but that will be
fixed separately.
Bug: 232
Change-Id: Ide2258ae8c09a9a41bb71d6777908d1c27917069
Reviewed-on: https://boringssl-review.googlesource.com/25244
Reviewed-by: Adam Langley <agl@google.com>
2018-01-20 20:56:53 +00:00
|
|
|
const int width = bn_minimal_width(bn);
|
|
|
|
if (width == 0) {
|
2014-06-20 20:00:00 +01:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
Add initial support for non-minimal BIGNUMs.
Thanks to Andres Erbsen for extremely helpful suggestions on how finally
plug this long-standing hole!
OpenSSL BIGNUMs are currently minimal-width, which means they cannot be
constant-time. We'll need to either excise BIGNUM from RSA and EC or
somehow fix BIGNUM. EC_SCALAR and later EC_FELEM work will excise it
from EC, but RSA's BIGNUMs are more transparent. Teaching BIGNUM to
handle non-minimal word widths is probably simpler.
The main constraint is BIGNUM's large "calculator" API surface. One
could, in theory, do arbitrary math on RSA components, which means all
public functions must tolerate non-minimal inputs. This is also useful
for EC; https://boringssl-review.googlesource.com/c/boringssl/+/24445 is
silly.
As a first step, fix comparison-type functions that were assuming
minimal BIGNUMs. I've also added bn_resize_words, but it is testing-only
until the rest of the library is fixed.
bn->top is now a loose upper bound we carry around. It does not affect
numerical results, only performance and secrecy. This is a departure
from the original meaning, and compiler help in auditing everything is
nice, so the final change in this series will rename bn->top to
bn->width. Thus these new functions are named per "width", not "top".
Looking further ahead, how are output BIGNUM widths determined? There's
three notions of correctness here:
1. Do I compute the right answer for all widths?
2. Do I handle secret data in constant time?
3. Does my memory usage not balloon absurdly?
For (1), a BIGNUM function must give the same answer for all input
widths. BN_mod_add_quick may assume |a| < |m|, but |a| may still be
wider than |m| by way of leading zeres. The simplest approach is to
write code in a width-agnostic way and rely on functions to accept all
widths. Where functions need to look at bn->d, we'll a few helper
functions to smooth over funny widths.
For (2), (1) is little cumbersome. Consider constant-time modular
addition. A sane type system would guarantee input widths match. But C
is weak here, and bifurcating the internals is a lot of work. Thus, at
least for now, I do not propose we move RSA's internal computation out
of BIGNUM. (EC_SCALAR/EC_FELEM are valuable for EC because we get to
stack-allocate, curves were already specialized, and EC only has two
types with many operations on those types. None of these apply to RSA.
We've got numbers mod n, mod p, mod q, and their corresponding
exponents, each of which is used for basically one operation.)
Instead, constant-time BIGNUM functions will output non-minimal widths.
This is trivial for BN_bin2bn or modular arithmetic. But for BN_mul,
constant-time[*] would dictate r->top = a->top + b->top. A calculator
repeatedly multiplying by one would then run out of memory. Those we'll
split into a private BN_mul_fixed for crypto, leaving BN_mul for
calculators. BN_mul is just BN_mul_fixed followed by bn_correct_top.
[*] BN_mul is not constant-time for other reasons, but that will be
fixed separately.
Bug: 232
Change-Id: Ide2258ae8c09a9a41bb71d6777908d1c27917069
Reviewed-on: https://boringssl-review.googlesource.com/25244
Reviewed-by: Adam Langley <agl@google.com>
2018-01-20 20:56:53 +00:00
|
|
|
return (width - 1) * BN_BITS2 + BN_num_bits_word(bn->d[width - 1]);
|
2014-06-20 20:00:00 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
unsigned BN_num_bytes(const BIGNUM *bn) {
|
|
|
|
return (BN_num_bits(bn) + 7) / 8;
|
|
|
|
}
|
|
|
|
|
|
|
|
void BN_zero(BIGNUM *bn) {
|
2018-01-15 10:23:24 +00:00
|
|
|
bn->width = bn->neg = 0;
|
2014-06-20 20:00:00 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
int BN_one(BIGNUM *bn) {
|
|
|
|
return BN_set_word(bn, 1);
|
|
|
|
}
|
|
|
|
|
|
|
|
int BN_set_word(BIGNUM *bn, BN_ULONG value) {
|
|
|
|
if (value == 0) {
|
|
|
|
BN_zero(bn);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2017-04-21 16:26:30 +01:00
|
|
|
if (!bn_wexpand(bn, 1)) {
|
2014-06-20 20:00:00 +01:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
bn->neg = 0;
|
|
|
|
bn->d[0] = value;
|
2018-01-15 10:23:24 +00:00
|
|
|
bn->width = 1;
|
2014-06-20 20:00:00 +01:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2016-08-24 04:53:12 +01:00
|
|
|
int BN_set_u64(BIGNUM *bn, uint64_t value) {
|
|
|
|
#if BN_BITS2 == 64
|
|
|
|
return BN_set_word(bn, value);
|
|
|
|
#elif BN_BITS2 == 32
|
|
|
|
if (value <= BN_MASK2) {
|
|
|
|
return BN_set_word(bn, (BN_ULONG)value);
|
|
|
|
}
|
|
|
|
|
2017-04-21 16:26:30 +01:00
|
|
|
if (!bn_wexpand(bn, 2)) {
|
2016-08-24 04:53:12 +01:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
bn->neg = 0;
|
|
|
|
bn->d[0] = (BN_ULONG)value;
|
|
|
|
bn->d[1] = (BN_ULONG)(value >> 32);
|
2018-01-15 10:23:24 +00:00
|
|
|
bn->width = 2;
|
2016-08-24 04:53:12 +01:00
|
|
|
return 1;
|
|
|
|
#else
|
|
|
|
#error "BN_BITS2 must be 32 or 64."
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2016-03-09 03:09:40 +00:00
|
|
|
int bn_set_words(BIGNUM *bn, const BN_ULONG *words, size_t num) {
|
2017-04-21 16:26:30 +01:00
|
|
|
if (!bn_wexpand(bn, num)) {
|
2016-03-09 03:09:40 +00:00
|
|
|
return 0;
|
|
|
|
}
|
2016-12-13 06:07:13 +00:00
|
|
|
OPENSSL_memmove(bn->d, words, num * sizeof(BN_ULONG));
|
2017-08-18 19:06:02 +01:00
|
|
|
// |bn_wexpand| verified that |num| isn't too large.
|
2018-01-15 10:23:24 +00:00
|
|
|
bn->width = (int)num;
|
2016-03-11 03:16:02 +00:00
|
|
|
bn->neg = 0;
|
2016-03-09 03:09:40 +00:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2018-01-23 21:17:55 +00:00
|
|
|
int bn_fits_in_words(const BIGNUM *bn, size_t num) {
|
2018-01-20 21:51:54 +00:00
|
|
|
// All words beyond |num| must be zero.
|
|
|
|
BN_ULONG mask = 0;
|
2018-01-15 10:23:24 +00:00
|
|
|
for (size_t i = num; i < (size_t)bn->width; i++) {
|
2018-01-20 21:51:54 +00:00
|
|
|
mask |= bn->d[i];
|
|
|
|
}
|
|
|
|
return mask == 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
int bn_copy_words(BN_ULONG *out, size_t num, const BIGNUM *bn) {
|
|
|
|
if (bn->neg) {
|
|
|
|
OPENSSL_PUT_ERROR(BN, BN_R_NEGATIVE_NUMBER);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-01-15 10:23:24 +00:00
|
|
|
size_t width = (size_t)bn->width;
|
2018-01-20 21:51:54 +00:00
|
|
|
if (width > num) {
|
|
|
|
if (!bn_fits_in_words(bn, num)) {
|
|
|
|
OPENSSL_PUT_ERROR(BN, BN_R_BIGNUM_TOO_LONG);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
width = num;
|
|
|
|
}
|
|
|
|
|
|
|
|
OPENSSL_memset(out, 0, sizeof(BN_ULONG) * num);
|
|
|
|
OPENSSL_memcpy(out, bn->d, sizeof(BN_ULONG) * width);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2014-06-20 20:00:00 +01:00
|
|
|
int BN_is_negative(const BIGNUM *bn) {
|
|
|
|
return bn->neg != 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
void BN_set_negative(BIGNUM *bn, int sign) {
|
|
|
|
if (sign && !BN_is_zero(bn)) {
|
|
|
|
bn->neg = 1;
|
|
|
|
} else {
|
|
|
|
bn->neg = 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-04-21 16:26:30 +01:00
|
|
|
int bn_wexpand(BIGNUM *bn, size_t words) {
|
2014-06-20 20:00:00 +01:00
|
|
|
BN_ULONG *a;
|
|
|
|
|
2015-08-11 17:05:02 +01:00
|
|
|
if (words <= (size_t)bn->dmax) {
|
2017-04-21 16:26:30 +01:00
|
|
|
return 1;
|
2014-06-20 20:00:00 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
if (words > (INT_MAX / (4 * BN_BITS2))) {
|
2015-06-29 05:28:17 +01:00
|
|
|
OPENSSL_PUT_ERROR(BN, BN_R_BIGNUM_TOO_LONG);
|
2017-04-21 16:26:30 +01:00
|
|
|
return 0;
|
2014-06-20 20:00:00 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
if (bn->flags & BN_FLG_STATIC_DATA) {
|
2015-06-29 05:28:17 +01:00
|
|
|
OPENSSL_PUT_ERROR(BN, BN_R_EXPAND_ON_STATIC_BIGNUM_DATA);
|
2017-04-21 16:26:30 +01:00
|
|
|
return 0;
|
2014-06-20 20:00:00 +01:00
|
|
|
}
|
|
|
|
|
2016-02-07 19:36:04 +00:00
|
|
|
a = OPENSSL_malloc(sizeof(BN_ULONG) * words);
|
2014-06-20 20:00:00 +01:00
|
|
|
if (a == NULL) {
|
2015-06-29 05:28:17 +01:00
|
|
|
OPENSSL_PUT_ERROR(BN, ERR_R_MALLOC_FAILURE);
|
2017-04-21 16:26:30 +01:00
|
|
|
return 0;
|
2014-06-20 20:00:00 +01:00
|
|
|
}
|
|
|
|
|
2018-01-15 10:23:24 +00:00
|
|
|
OPENSSL_memcpy(a, bn->d, sizeof(BN_ULONG) * bn->width);
|
2014-06-20 20:00:00 +01:00
|
|
|
|
2015-04-22 18:50:28 +01:00
|
|
|
OPENSSL_free(bn->d);
|
2014-06-20 20:00:00 +01:00
|
|
|
bn->d = a;
|
2015-08-11 17:05:02 +01:00
|
|
|
bn->dmax = (int)words;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
2017-04-21 16:26:30 +01:00
|
|
|
return 1;
|
2014-06-20 20:00:00 +01:00
|
|
|
}
|
|
|
|
|
2017-04-21 16:26:30 +01:00
|
|
|
int bn_expand(BIGNUM *bn, size_t bits) {
|
2015-08-11 17:05:02 +01:00
|
|
|
if (bits + BN_BITS2 - 1 < bits) {
|
|
|
|
OPENSSL_PUT_ERROR(BN, BN_R_BIGNUM_TOO_LONG);
|
2017-04-21 16:26:30 +01:00
|
|
|
return 0;
|
2015-08-11 17:05:02 +01:00
|
|
|
}
|
2014-06-20 20:00:00 +01:00
|
|
|
return bn_wexpand(bn, (bits+BN_BITS2-1)/BN_BITS2);
|
|
|
|
}
|
|
|
|
|
Add initial support for non-minimal BIGNUMs.
Thanks to Andres Erbsen for extremely helpful suggestions on how finally
plug this long-standing hole!
OpenSSL BIGNUMs are currently minimal-width, which means they cannot be
constant-time. We'll need to either excise BIGNUM from RSA and EC or
somehow fix BIGNUM. EC_SCALAR and later EC_FELEM work will excise it
from EC, but RSA's BIGNUMs are more transparent. Teaching BIGNUM to
handle non-minimal word widths is probably simpler.
The main constraint is BIGNUM's large "calculator" API surface. One
could, in theory, do arbitrary math on RSA components, which means all
public functions must tolerate non-minimal inputs. This is also useful
for EC; https://boringssl-review.googlesource.com/c/boringssl/+/24445 is
silly.
As a first step, fix comparison-type functions that were assuming
minimal BIGNUMs. I've also added bn_resize_words, but it is testing-only
until the rest of the library is fixed.
bn->top is now a loose upper bound we carry around. It does not affect
numerical results, only performance and secrecy. This is a departure
from the original meaning, and compiler help in auditing everything is
nice, so the final change in this series will rename bn->top to
bn->width. Thus these new functions are named per "width", not "top".
Looking further ahead, how are output BIGNUM widths determined? There's
three notions of correctness here:
1. Do I compute the right answer for all widths?
2. Do I handle secret data in constant time?
3. Does my memory usage not balloon absurdly?
For (1), a BIGNUM function must give the same answer for all input
widths. BN_mod_add_quick may assume |a| < |m|, but |a| may still be
wider than |m| by way of leading zeres. The simplest approach is to
write code in a width-agnostic way and rely on functions to accept all
widths. Where functions need to look at bn->d, we'll a few helper
functions to smooth over funny widths.
For (2), (1) is little cumbersome. Consider constant-time modular
addition. A sane type system would guarantee input widths match. But C
is weak here, and bifurcating the internals is a lot of work. Thus, at
least for now, I do not propose we move RSA's internal computation out
of BIGNUM. (EC_SCALAR/EC_FELEM are valuable for EC because we get to
stack-allocate, curves were already specialized, and EC only has two
types with many operations on those types. None of these apply to RSA.
We've got numbers mod n, mod p, mod q, and their corresponding
exponents, each of which is used for basically one operation.)
Instead, constant-time BIGNUM functions will output non-minimal widths.
This is trivial for BN_bin2bn or modular arithmetic. But for BN_mul,
constant-time[*] would dictate r->top = a->top + b->top. A calculator
repeatedly multiplying by one would then run out of memory. Those we'll
split into a private BN_mul_fixed for crypto, leaving BN_mul for
calculators. BN_mul is just BN_mul_fixed followed by bn_correct_top.
[*] BN_mul is not constant-time for other reasons, but that will be
fixed separately.
Bug: 232
Change-Id: Ide2258ae8c09a9a41bb71d6777908d1c27917069
Reviewed-on: https://boringssl-review.googlesource.com/25244
Reviewed-by: Adam Langley <agl@google.com>
2018-01-20 20:56:53 +00:00
|
|
|
int bn_resize_words(BIGNUM *bn, size_t words) {
|
2018-01-15 10:23:24 +00:00
|
|
|
if ((size_t)bn->width <= words) {
|
Add initial support for non-minimal BIGNUMs.
Thanks to Andres Erbsen for extremely helpful suggestions on how finally
plug this long-standing hole!
OpenSSL BIGNUMs are currently minimal-width, which means they cannot be
constant-time. We'll need to either excise BIGNUM from RSA and EC or
somehow fix BIGNUM. EC_SCALAR and later EC_FELEM work will excise it
from EC, but RSA's BIGNUMs are more transparent. Teaching BIGNUM to
handle non-minimal word widths is probably simpler.
The main constraint is BIGNUM's large "calculator" API surface. One
could, in theory, do arbitrary math on RSA components, which means all
public functions must tolerate non-minimal inputs. This is also useful
for EC; https://boringssl-review.googlesource.com/c/boringssl/+/24445 is
silly.
As a first step, fix comparison-type functions that were assuming
minimal BIGNUMs. I've also added bn_resize_words, but it is testing-only
until the rest of the library is fixed.
bn->top is now a loose upper bound we carry around. It does not affect
numerical results, only performance and secrecy. This is a departure
from the original meaning, and compiler help in auditing everything is
nice, so the final change in this series will rename bn->top to
bn->width. Thus these new functions are named per "width", not "top".
Looking further ahead, how are output BIGNUM widths determined? There's
three notions of correctness here:
1. Do I compute the right answer for all widths?
2. Do I handle secret data in constant time?
3. Does my memory usage not balloon absurdly?
For (1), a BIGNUM function must give the same answer for all input
widths. BN_mod_add_quick may assume |a| < |m|, but |a| may still be
wider than |m| by way of leading zeres. The simplest approach is to
write code in a width-agnostic way and rely on functions to accept all
widths. Where functions need to look at bn->d, we'll a few helper
functions to smooth over funny widths.
For (2), (1) is little cumbersome. Consider constant-time modular
addition. A sane type system would guarantee input widths match. But C
is weak here, and bifurcating the internals is a lot of work. Thus, at
least for now, I do not propose we move RSA's internal computation out
of BIGNUM. (EC_SCALAR/EC_FELEM are valuable for EC because we get to
stack-allocate, curves were already specialized, and EC only has two
types with many operations on those types. None of these apply to RSA.
We've got numbers mod n, mod p, mod q, and their corresponding
exponents, each of which is used for basically one operation.)
Instead, constant-time BIGNUM functions will output non-minimal widths.
This is trivial for BN_bin2bn or modular arithmetic. But for BN_mul,
constant-time[*] would dictate r->top = a->top + b->top. A calculator
repeatedly multiplying by one would then run out of memory. Those we'll
split into a private BN_mul_fixed for crypto, leaving BN_mul for
calculators. BN_mul is just BN_mul_fixed followed by bn_correct_top.
[*] BN_mul is not constant-time for other reasons, but that will be
fixed separately.
Bug: 232
Change-Id: Ide2258ae8c09a9a41bb71d6777908d1c27917069
Reviewed-on: https://boringssl-review.googlesource.com/25244
Reviewed-by: Adam Langley <agl@google.com>
2018-01-20 20:56:53 +00:00
|
|
|
if (!bn_wexpand(bn, words)) {
|
|
|
|
return 0;
|
2014-06-20 20:00:00 +01:00
|
|
|
}
|
2018-01-15 10:23:24 +00:00
|
|
|
OPENSSL_memset(bn->d + bn->width, 0,
|
|
|
|
(words - bn->width) * sizeof(BN_ULONG));
|
|
|
|
bn->width = words;
|
Add initial support for non-minimal BIGNUMs.
Thanks to Andres Erbsen for extremely helpful suggestions on how finally
plug this long-standing hole!
OpenSSL BIGNUMs are currently minimal-width, which means they cannot be
constant-time. We'll need to either excise BIGNUM from RSA and EC or
somehow fix BIGNUM. EC_SCALAR and later EC_FELEM work will excise it
from EC, but RSA's BIGNUMs are more transparent. Teaching BIGNUM to
handle non-minimal word widths is probably simpler.
The main constraint is BIGNUM's large "calculator" API surface. One
could, in theory, do arbitrary math on RSA components, which means all
public functions must tolerate non-minimal inputs. This is also useful
for EC; https://boringssl-review.googlesource.com/c/boringssl/+/24445 is
silly.
As a first step, fix comparison-type functions that were assuming
minimal BIGNUMs. I've also added bn_resize_words, but it is testing-only
until the rest of the library is fixed.
bn->top is now a loose upper bound we carry around. It does not affect
numerical results, only performance and secrecy. This is a departure
from the original meaning, and compiler help in auditing everything is
nice, so the final change in this series will rename bn->top to
bn->width. Thus these new functions are named per "width", not "top".
Looking further ahead, how are output BIGNUM widths determined? There's
three notions of correctness here:
1. Do I compute the right answer for all widths?
2. Do I handle secret data in constant time?
3. Does my memory usage not balloon absurdly?
For (1), a BIGNUM function must give the same answer for all input
widths. BN_mod_add_quick may assume |a| < |m|, but |a| may still be
wider than |m| by way of leading zeres. The simplest approach is to
write code in a width-agnostic way and rely on functions to accept all
widths. Where functions need to look at bn->d, we'll a few helper
functions to smooth over funny widths.
For (2), (1) is little cumbersome. Consider constant-time modular
addition. A sane type system would guarantee input widths match. But C
is weak here, and bifurcating the internals is a lot of work. Thus, at
least for now, I do not propose we move RSA's internal computation out
of BIGNUM. (EC_SCALAR/EC_FELEM are valuable for EC because we get to
stack-allocate, curves were already specialized, and EC only has two
types with many operations on those types. None of these apply to RSA.
We've got numbers mod n, mod p, mod q, and their corresponding
exponents, each of which is used for basically one operation.)
Instead, constant-time BIGNUM functions will output non-minimal widths.
This is trivial for BN_bin2bn or modular arithmetic. But for BN_mul,
constant-time[*] would dictate r->top = a->top + b->top. A calculator
repeatedly multiplying by one would then run out of memory. Those we'll
split into a private BN_mul_fixed for crypto, leaving BN_mul for
calculators. BN_mul is just BN_mul_fixed followed by bn_correct_top.
[*] BN_mul is not constant-time for other reasons, but that will be
fixed separately.
Bug: 232
Change-Id: Ide2258ae8c09a9a41bb71d6777908d1c27917069
Reviewed-on: https://boringssl-review.googlesource.com/25244
Reviewed-by: Adam Langley <agl@google.com>
2018-01-20 20:56:53 +00:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
// All words beyond the new width must be zero.
|
2018-01-20 21:51:54 +00:00
|
|
|
if (!bn_fits_in_words(bn, words)) {
|
Add initial support for non-minimal BIGNUMs.
Thanks to Andres Erbsen for extremely helpful suggestions on how finally
plug this long-standing hole!
OpenSSL BIGNUMs are currently minimal-width, which means they cannot be
constant-time. We'll need to either excise BIGNUM from RSA and EC or
somehow fix BIGNUM. EC_SCALAR and later EC_FELEM work will excise it
from EC, but RSA's BIGNUMs are more transparent. Teaching BIGNUM to
handle non-minimal word widths is probably simpler.
The main constraint is BIGNUM's large "calculator" API surface. One
could, in theory, do arbitrary math on RSA components, which means all
public functions must tolerate non-minimal inputs. This is also useful
for EC; https://boringssl-review.googlesource.com/c/boringssl/+/24445 is
silly.
As a first step, fix comparison-type functions that were assuming
minimal BIGNUMs. I've also added bn_resize_words, but it is testing-only
until the rest of the library is fixed.
bn->top is now a loose upper bound we carry around. It does not affect
numerical results, only performance and secrecy. This is a departure
from the original meaning, and compiler help in auditing everything is
nice, so the final change in this series will rename bn->top to
bn->width. Thus these new functions are named per "width", not "top".
Looking further ahead, how are output BIGNUM widths determined? There's
three notions of correctness here:
1. Do I compute the right answer for all widths?
2. Do I handle secret data in constant time?
3. Does my memory usage not balloon absurdly?
For (1), a BIGNUM function must give the same answer for all input
widths. BN_mod_add_quick may assume |a| < |m|, but |a| may still be
wider than |m| by way of leading zeres. The simplest approach is to
write code in a width-agnostic way and rely on functions to accept all
widths. Where functions need to look at bn->d, we'll a few helper
functions to smooth over funny widths.
For (2), (1) is little cumbersome. Consider constant-time modular
addition. A sane type system would guarantee input widths match. But C
is weak here, and bifurcating the internals is a lot of work. Thus, at
least for now, I do not propose we move RSA's internal computation out
of BIGNUM. (EC_SCALAR/EC_FELEM are valuable for EC because we get to
stack-allocate, curves were already specialized, and EC only has two
types with many operations on those types. None of these apply to RSA.
We've got numbers mod n, mod p, mod q, and their corresponding
exponents, each of which is used for basically one operation.)
Instead, constant-time BIGNUM functions will output non-minimal widths.
This is trivial for BN_bin2bn or modular arithmetic. But for BN_mul,
constant-time[*] would dictate r->top = a->top + b->top. A calculator
repeatedly multiplying by one would then run out of memory. Those we'll
split into a private BN_mul_fixed for crypto, leaving BN_mul for
calculators. BN_mul is just BN_mul_fixed followed by bn_correct_top.
[*] BN_mul is not constant-time for other reasons, but that will be
fixed separately.
Bug: 232
Change-Id: Ide2258ae8c09a9a41bb71d6777908d1c27917069
Reviewed-on: https://boringssl-review.googlesource.com/25244
Reviewed-by: Adam Langley <agl@google.com>
2018-01-20 20:56:53 +00:00
|
|
|
OPENSSL_PUT_ERROR(BN, BN_R_BIGNUM_TOO_LONG);
|
|
|
|
return 0;
|
2014-06-20 20:00:00 +01:00
|
|
|
}
|
2018-01-15 10:23:24 +00:00
|
|
|
bn->width = words;
|
Add initial support for non-minimal BIGNUMs.
Thanks to Andres Erbsen for extremely helpful suggestions on how finally
plug this long-standing hole!
OpenSSL BIGNUMs are currently minimal-width, which means they cannot be
constant-time. We'll need to either excise BIGNUM from RSA and EC or
somehow fix BIGNUM. EC_SCALAR and later EC_FELEM work will excise it
from EC, but RSA's BIGNUMs are more transparent. Teaching BIGNUM to
handle non-minimal word widths is probably simpler.
The main constraint is BIGNUM's large "calculator" API surface. One
could, in theory, do arbitrary math on RSA components, which means all
public functions must tolerate non-minimal inputs. This is also useful
for EC; https://boringssl-review.googlesource.com/c/boringssl/+/24445 is
silly.
As a first step, fix comparison-type functions that were assuming
minimal BIGNUMs. I've also added bn_resize_words, but it is testing-only
until the rest of the library is fixed.
bn->top is now a loose upper bound we carry around. It does not affect
numerical results, only performance and secrecy. This is a departure
from the original meaning, and compiler help in auditing everything is
nice, so the final change in this series will rename bn->top to
bn->width. Thus these new functions are named per "width", not "top".
Looking further ahead, how are output BIGNUM widths determined? There's
three notions of correctness here:
1. Do I compute the right answer for all widths?
2. Do I handle secret data in constant time?
3. Does my memory usage not balloon absurdly?
For (1), a BIGNUM function must give the same answer for all input
widths. BN_mod_add_quick may assume |a| < |m|, but |a| may still be
wider than |m| by way of leading zeres. The simplest approach is to
write code in a width-agnostic way and rely on functions to accept all
widths. Where functions need to look at bn->d, we'll a few helper
functions to smooth over funny widths.
For (2), (1) is little cumbersome. Consider constant-time modular
addition. A sane type system would guarantee input widths match. But C
is weak here, and bifurcating the internals is a lot of work. Thus, at
least for now, I do not propose we move RSA's internal computation out
of BIGNUM. (EC_SCALAR/EC_FELEM are valuable for EC because we get to
stack-allocate, curves were already specialized, and EC only has two
types with many operations on those types. None of these apply to RSA.
We've got numbers mod n, mod p, mod q, and their corresponding
exponents, each of which is used for basically one operation.)
Instead, constant-time BIGNUM functions will output non-minimal widths.
This is trivial for BN_bin2bn or modular arithmetic. But for BN_mul,
constant-time[*] would dictate r->top = a->top + b->top. A calculator
repeatedly multiplying by one would then run out of memory. Those we'll
split into a private BN_mul_fixed for crypto, leaving BN_mul for
calculators. BN_mul is just BN_mul_fixed followed by bn_correct_top.
[*] BN_mul is not constant-time for other reasons, but that will be
fixed separately.
Bug: 232
Change-Id: Ide2258ae8c09a9a41bb71d6777908d1c27917069
Reviewed-on: https://boringssl-review.googlesource.com/25244
Reviewed-by: Adam Langley <agl@google.com>
2018-01-20 20:56:53 +00:00
|
|
|
return 1;
|
|
|
|
}
|
2016-08-02 18:09:19 +01:00
|
|
|
|
2018-01-26 04:56:35 +00:00
|
|
|
void bn_select_words(BN_ULONG *r, BN_ULONG mask, const BN_ULONG *a,
|
|
|
|
const BN_ULONG *b, size_t num) {
|
|
|
|
for (size_t i = 0; i < num; i++) {
|
|
|
|
OPENSSL_COMPILE_ASSERT(sizeof(BN_ULONG) <= sizeof(crypto_word_t),
|
|
|
|
crypto_word_t_too_small);
|
|
|
|
r[i] = constant_time_select_w(mask, a[i], b[i]);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Add initial support for non-minimal BIGNUMs.
Thanks to Andres Erbsen for extremely helpful suggestions on how finally
plug this long-standing hole!
OpenSSL BIGNUMs are currently minimal-width, which means they cannot be
constant-time. We'll need to either excise BIGNUM from RSA and EC or
somehow fix BIGNUM. EC_SCALAR and later EC_FELEM work will excise it
from EC, but RSA's BIGNUMs are more transparent. Teaching BIGNUM to
handle non-minimal word widths is probably simpler.
The main constraint is BIGNUM's large "calculator" API surface. One
could, in theory, do arbitrary math on RSA components, which means all
public functions must tolerate non-minimal inputs. This is also useful
for EC; https://boringssl-review.googlesource.com/c/boringssl/+/24445 is
silly.
As a first step, fix comparison-type functions that were assuming
minimal BIGNUMs. I've also added bn_resize_words, but it is testing-only
until the rest of the library is fixed.
bn->top is now a loose upper bound we carry around. It does not affect
numerical results, only performance and secrecy. This is a departure
from the original meaning, and compiler help in auditing everything is
nice, so the final change in this series will rename bn->top to
bn->width. Thus these new functions are named per "width", not "top".
Looking further ahead, how are output BIGNUM widths determined? There's
three notions of correctness here:
1. Do I compute the right answer for all widths?
2. Do I handle secret data in constant time?
3. Does my memory usage not balloon absurdly?
For (1), a BIGNUM function must give the same answer for all input
widths. BN_mod_add_quick may assume |a| < |m|, but |a| may still be
wider than |m| by way of leading zeres. The simplest approach is to
write code in a width-agnostic way and rely on functions to accept all
widths. Where functions need to look at bn->d, we'll a few helper
functions to smooth over funny widths.
For (2), (1) is little cumbersome. Consider constant-time modular
addition. A sane type system would guarantee input widths match. But C
is weak here, and bifurcating the internals is a lot of work. Thus, at
least for now, I do not propose we move RSA's internal computation out
of BIGNUM. (EC_SCALAR/EC_FELEM are valuable for EC because we get to
stack-allocate, curves were already specialized, and EC only has two
types with many operations on those types. None of these apply to RSA.
We've got numbers mod n, mod p, mod q, and their corresponding
exponents, each of which is used for basically one operation.)
Instead, constant-time BIGNUM functions will output non-minimal widths.
This is trivial for BN_bin2bn or modular arithmetic. But for BN_mul,
constant-time[*] would dictate r->top = a->top + b->top. A calculator
repeatedly multiplying by one would then run out of memory. Those we'll
split into a private BN_mul_fixed for crypto, leaving BN_mul for
calculators. BN_mul is just BN_mul_fixed followed by bn_correct_top.
[*] BN_mul is not constant-time for other reasons, but that will be
fixed separately.
Bug: 232
Change-Id: Ide2258ae8c09a9a41bb71d6777908d1c27917069
Reviewed-on: https://boringssl-review.googlesource.com/25244
Reviewed-by: Adam Langley <agl@google.com>
2018-01-20 20:56:53 +00:00
|
|
|
int bn_minimal_width(const BIGNUM *bn) {
|
2018-01-15 10:23:24 +00:00
|
|
|
int ret = bn->width;
|
Add initial support for non-minimal BIGNUMs.
Thanks to Andres Erbsen for extremely helpful suggestions on how finally
plug this long-standing hole!
OpenSSL BIGNUMs are currently minimal-width, which means they cannot be
constant-time. We'll need to either excise BIGNUM from RSA and EC or
somehow fix BIGNUM. EC_SCALAR and later EC_FELEM work will excise it
from EC, but RSA's BIGNUMs are more transparent. Teaching BIGNUM to
handle non-minimal word widths is probably simpler.
The main constraint is BIGNUM's large "calculator" API surface. One
could, in theory, do arbitrary math on RSA components, which means all
public functions must tolerate non-minimal inputs. This is also useful
for EC; https://boringssl-review.googlesource.com/c/boringssl/+/24445 is
silly.
As a first step, fix comparison-type functions that were assuming
minimal BIGNUMs. I've also added bn_resize_words, but it is testing-only
until the rest of the library is fixed.
bn->top is now a loose upper bound we carry around. It does not affect
numerical results, only performance and secrecy. This is a departure
from the original meaning, and compiler help in auditing everything is
nice, so the final change in this series will rename bn->top to
bn->width. Thus these new functions are named per "width", not "top".
Looking further ahead, how are output BIGNUM widths determined? There's
three notions of correctness here:
1. Do I compute the right answer for all widths?
2. Do I handle secret data in constant time?
3. Does my memory usage not balloon absurdly?
For (1), a BIGNUM function must give the same answer for all input
widths. BN_mod_add_quick may assume |a| < |m|, but |a| may still be
wider than |m| by way of leading zeres. The simplest approach is to
write code in a width-agnostic way and rely on functions to accept all
widths. Where functions need to look at bn->d, we'll a few helper
functions to smooth over funny widths.
For (2), (1) is little cumbersome. Consider constant-time modular
addition. A sane type system would guarantee input widths match. But C
is weak here, and bifurcating the internals is a lot of work. Thus, at
least for now, I do not propose we move RSA's internal computation out
of BIGNUM. (EC_SCALAR/EC_FELEM are valuable for EC because we get to
stack-allocate, curves were already specialized, and EC only has two
types with many operations on those types. None of these apply to RSA.
We've got numbers mod n, mod p, mod q, and their corresponding
exponents, each of which is used for basically one operation.)
Instead, constant-time BIGNUM functions will output non-minimal widths.
This is trivial for BN_bin2bn or modular arithmetic. But for BN_mul,
constant-time[*] would dictate r->top = a->top + b->top. A calculator
repeatedly multiplying by one would then run out of memory. Those we'll
split into a private BN_mul_fixed for crypto, leaving BN_mul for
calculators. BN_mul is just BN_mul_fixed followed by bn_correct_top.
[*] BN_mul is not constant-time for other reasons, but that will be
fixed separately.
Bug: 232
Change-Id: Ide2258ae8c09a9a41bb71d6777908d1c27917069
Reviewed-on: https://boringssl-review.googlesource.com/25244
Reviewed-by: Adam Langley <agl@google.com>
2018-01-20 20:56:53 +00:00
|
|
|
while (ret > 0 && bn->d[ret - 1] == 0) {
|
|
|
|
ret--;
|
|
|
|
}
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2018-01-15 10:23:24 +00:00
|
|
|
void bn_set_minimal_width(BIGNUM *bn) {
|
|
|
|
bn->width = bn_minimal_width(bn);
|
|
|
|
if (bn->width == 0) {
|
2016-08-02 18:09:19 +01:00
|
|
|
bn->neg = 0;
|
|
|
|
}
|
2014-06-20 20:00:00 +01:00
|
|
|
}
|