boringssl/crypto/fipsmodule/bn/cmp.c

261 lines
7.5 KiB
C
Raw Normal View History

/* 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 <openssl/mem.h>
#include <openssl/type_check.h>
#include "internal.h"
#include "../../internal.h"
int BN_ucmp(const BIGNUM *a, const BIGNUM *b) {
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 a_width = bn_minimal_width(a);
int b_width = bn_minimal_width(b);
int i = a_width - b_width;
if (i != 0) {
return 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
const BN_ULONG *ap = a->d;
const BN_ULONG *bp = b->d;
for (i = a_width - 1; i >= 0; i--) {
BN_ULONG t1 = ap[i];
BN_ULONG t2 = bp[i];
if (t1 != t2) {
return (t1 > t2) ? 1 : -1;
}
}
return 0;
}
int BN_cmp(const BIGNUM *a, const BIGNUM *b) {
int i;
int gt, lt;
BN_ULONG t1, t2;
if ((a == NULL) || (b == NULL)) {
if (a != NULL) {
return -1;
} else if (b != NULL) {
return 1;
} else {
return 0;
}
}
if (a->neg != b->neg) {
if (a->neg) {
return -1;
}
return 1;
}
if (a->neg == 0) {
gt = 1;
lt = -1;
} else {
gt = -1;
lt = 1;
}
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 a_width = bn_minimal_width(a);
int b_width = bn_minimal_width(b);
if (a_width > b_width) {
return gt;
}
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 (a_width < b_width) {
return lt;
}
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
for (i = a_width - 1; i >= 0; i--) {
t1 = a->d[i];
t2 = b->d[i];
if (t1 > t2) {
return gt;
} if (t1 < t2) {
return lt;
}
}
return 0;
}
static int bn_less_than_words_impl(const BN_ULONG *a, size_t a_len,
const BN_ULONG *b, size_t b_len) {
OPENSSL_COMPILE_ASSERT(sizeof(BN_ULONG) <= sizeof(crypto_word_t),
crypto_word_t_too_small);
int ret = 0;
// Process the common words in little-endian order.
size_t min = a_len < b_len ? a_len : b_len;
for (size_t i = 0; i < min; i++) {
crypto_word_t eq = constant_time_eq_w(a[i], b[i]);
crypto_word_t lt = constant_time_lt_w(a[i], b[i]);
ret = constant_time_select_int(eq, ret, constant_time_select_int(lt, 1, 0));
}
// If |a| or |b| has non-zero words beyond |min|, they take precedence.
if (a_len < b_len) {
crypto_word_t mask = 0;
for (size_t i = a_len; i < b_len; i++) {
mask |= b[i];
}
ret = constant_time_select_int(constant_time_is_zero_w(mask), ret, 1);
} else if (b_len < a_len) {
crypto_word_t mask = 0;
for (size_t i = b_len; i < a_len; i++) {
mask |= a[i];
}
ret = constant_time_select_int(constant_time_is_zero_w(mask), ret, 0);
}
return ret;
}
int bn_less_than_words(const BN_ULONG *a, const BN_ULONG *b, size_t len) {
return bn_less_than_words_impl(a, len, b, len);
}
int BN_abs_is_word(const BIGNUM *bn, BN_ULONG w) {
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
switch (bn_minimal_width(bn)) {
case 1:
return bn->d[0] == w;
case 0:
return w == 0;
default:
return 0;
}
}
int BN_cmp_word(const BIGNUM *a, BN_ULONG b) {
BIGNUM b_bn;
BN_init(&b_bn);
b_bn.d = &b;
b_bn.width = b > 0;
b_bn.dmax = 1;
b_bn.flags = BN_FLG_STATIC_DATA;
return BN_cmp(a, &b_bn);
}
int BN_is_zero(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
return bn_minimal_width(bn) == 0;
}
int BN_is_one(const BIGNUM *bn) {
return bn->neg == 0 && BN_abs_is_word(bn, 1);
}
int BN_is_word(const BIGNUM *bn, BN_ULONG w) {
return BN_abs_is_word(bn, w) && (w == 0 || bn->neg == 0);
}
int BN_is_odd(const BIGNUM *bn) {
return bn->width > 0 && (bn->d[0] & 1) == 1;
}
int BN_is_pow2(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
int width = bn_minimal_width(bn);
if (width == 0 || bn->neg) {
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
for (int i = 0; i < width - 1; i++) {
if (bn->d[i] != 0) {
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 0 == (bn->d[width-1] & (bn->d[width-1] - 1));
}
int BN_equal_consttime(const BIGNUM *a, const BIGNUM *b) {
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
BN_ULONG mask = 0;
// If |a| or |b| has more words than the other, all those words must be zero.
for (int i = a->width; i < b->width; 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
mask |= b->d[i];
}
for (int i = b->width; i < a->width; 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
mask |= a->d[i];
}
// Common words must match.
int min = a->width < b->width ? a->width : b->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
for (int i = 0; i < min; i++) {
mask |= (a->d[i] ^ b->d[i]);
}
// The sign bit must match.
mask |= (a->neg ^ b->neg);
return mask == 0;
}
int BN_less_than_consttime(const BIGNUM *a, const BIGNUM *b) {
// We do not attempt to process the sign bit in constant time. Negative
// |BIGNUM|s should never occur in crypto, only calculators.
if (a->neg && !b->neg) {
return 1;
}
if (b->neg && !a->neg) {
return 0;
}
if (a->neg && b->neg) {
const BIGNUM *tmp = a;
a = b;
b = tmp;
}
return bn_less_than_words_impl(a->d, a->width, b->d, b->width);
}