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/rsa.h>
|
|
|
|
|
|
2016-03-14 18:19:41 +00:00
|
|
|
|
#include <assert.h>
|
2017-04-10 23:35:22 +01:00
|
|
|
|
#include <limits.h>
|
2015-01-31 01:08:37 +00:00
|
|
|
|
#include <string.h>
|
|
|
|
|
|
2014-06-20 20:00:00 +01:00
|
|
|
|
#include <openssl/bn.h>
|
|
|
|
|
#include <openssl/err.h>
|
|
|
|
|
#include <openssl/mem.h>
|
2015-03-28 07:12:01 +00:00
|
|
|
|
#include <openssl/thread.h>
|
2017-04-10 23:35:22 +01:00
|
|
|
|
#include <openssl/type_check.h>
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
|
|
|
|
#include "internal.h"
|
2017-05-03 19:50:51 +01:00
|
|
|
|
#include "../bn/internal.h"
|
|
|
|
|
#include "../../internal.h"
|
|
|
|
|
#include "../delocate.h"
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
|
|
|
|
|
2016-01-12 20:47:25 +00:00
|
|
|
|
static int check_modulus_and_exponent_sizes(const RSA *rsa) {
|
|
|
|
|
unsigned rsa_bits = BN_num_bits(rsa->n);
|
2016-03-14 18:19:41 +00:00
|
|
|
|
|
2016-01-12 20:47:25 +00:00
|
|
|
|
if (rsa_bits > 16 * 1024) {
|
|
|
|
|
OPENSSL_PUT_ERROR(RSA, RSA_R_MODULUS_TOO_LARGE);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
2017-08-18 19:06:02 +01:00
|
|
|
|
// Mitigate DoS attacks by limiting the exponent size. 33 bits was chosen as
|
|
|
|
|
// the limit based on the recommendations in [1] and [2]. Windows CryptoAPI
|
|
|
|
|
// doesn't support values larger than 32 bits [3], so it is unlikely that
|
|
|
|
|
// exponents larger than 32 bits are being used for anything Windows commonly
|
|
|
|
|
// does.
|
|
|
|
|
//
|
|
|
|
|
// [1] https://www.imperialviolet.org/2012/03/16/rsae.html
|
|
|
|
|
// [2] https://www.imperialviolet.org/2012/03/17/rsados.html
|
|
|
|
|
// [3] https://msdn.microsoft.com/en-us/library/aa387685(VS.85).aspx
|
2016-03-14 18:19:41 +00:00
|
|
|
|
static const unsigned kMaxExponentBits = 33;
|
|
|
|
|
|
|
|
|
|
if (BN_num_bits(rsa->e) > kMaxExponentBits) {
|
2016-01-12 20:47:25 +00:00
|
|
|
|
OPENSSL_PUT_ERROR(RSA, RSA_R_BAD_E_VALUE);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2017-08-18 19:06:02 +01:00
|
|
|
|
// Verify |n > e|. Comparing |rsa_bits| to |kMaxExponentBits| is a small
|
|
|
|
|
// shortcut to comparing |n| and |e| directly. In reality, |kMaxExponentBits|
|
|
|
|
|
// is much smaller than the minimum RSA key size that any application should
|
|
|
|
|
// accept.
|
2016-03-14 18:19:41 +00:00
|
|
|
|
if (rsa_bits <= kMaxExponentBits) {
|
|
|
|
|
OPENSSL_PUT_ERROR(RSA, RSA_R_KEY_SIZE_TOO_SMALL);
|
2016-01-12 20:47:25 +00:00
|
|
|
|
return 0;
|
|
|
|
|
}
|
2016-03-14 18:19:41 +00:00
|
|
|
|
assert(BN_ucmp(rsa->n, rsa->e) > 0);
|
2016-01-12 20:47:25 +00:00
|
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
Fix threading issues with RSA freeze_private_key.
OpenSSL's RSA API is poorly designed and does not have a single place to
properly initialize the key. See
https://github.com/openssl/openssl/issues/5158.
To workaround this flaw, we must lazily instantiate pre-computed
Montgomery bits with locking. This is a ton of complexity. More
importantly, it makes it very difficult to implement RSA without side
channels. The correct in-memory representation of d, dmp1, and dmq1
depend on n, p, and q, respectively. (Those values have private
magnitudes and must be sized relative to the respective moduli.)
08805fe27910e09d05e87d61bc5411a4e3b2d999 attempted to fix up the various
widths under lock, when we set up BN_MONT_CTX. However, this introduces
threading issues because other threads may access those exposed
components (RSA_get0_* also count as exposed for these purposes because
they are get0 functions), while a private key operation is in progress.
Instead, we do the following:
- There is no actual need to minimize n, p, and q, but we have minimized
copies in the BN_MONT_CTXs, so use those.
- Store additional copies of d, dmp1, and dmq1, at the cost of more
memory used. These copies have the correct width and are private,
unlike d, dmp1, and dmq1 which are sadly exposed. Fix private key
operations to use them.
- Move the frozen bit out of rsa->flags, as that too was historically
accessible without locking.
(Serialization still uses the original BIGNUMs, but the RSAPrivateKey
serialization format already inherently leaks the magnitude, so this
doesn't matter.)
Change-Id: Ia3a9b0629f8efef23abb30bfed110d247d1db42f
Reviewed-on: https://boringssl-review.googlesource.com/25824
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
2018-02-09 20:52:58 +00:00
|
|
|
|
static int ensure_fixed_copy(BIGNUM **out, const BIGNUM *in, int width) {
|
|
|
|
|
if (*out != NULL) {
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
BIGNUM *copy = BN_dup(in);
|
|
|
|
|
if (copy == NULL ||
|
|
|
|
|
!bn_resize_words(copy, width)) {
|
|
|
|
|
BN_free(copy);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
*out = copy;
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
|
2018-01-23 21:48:53 +00:00
|
|
|
|
// freeze_private_key finishes initializing |rsa|'s private key components.
|
|
|
|
|
// After this function has returned, |rsa| may not be changed. This is needed
|
|
|
|
|
// because |RSA| is a public struct and, additionally, OpenSSL 1.1.0 opaquified
|
|
|
|
|
// it wrong (see https://github.com/openssl/openssl/issues/5158).
|
|
|
|
|
static int freeze_private_key(RSA *rsa, BN_CTX *ctx) {
|
|
|
|
|
CRYPTO_MUTEX_lock_read(&rsa->lock);
|
Fix threading issues with RSA freeze_private_key.
OpenSSL's RSA API is poorly designed and does not have a single place to
properly initialize the key. See
https://github.com/openssl/openssl/issues/5158.
To workaround this flaw, we must lazily instantiate pre-computed
Montgomery bits with locking. This is a ton of complexity. More
importantly, it makes it very difficult to implement RSA without side
channels. The correct in-memory representation of d, dmp1, and dmq1
depend on n, p, and q, respectively. (Those values have private
magnitudes and must be sized relative to the respective moduli.)
08805fe27910e09d05e87d61bc5411a4e3b2d999 attempted to fix up the various
widths under lock, when we set up BN_MONT_CTX. However, this introduces
threading issues because other threads may access those exposed
components (RSA_get0_* also count as exposed for these purposes because
they are get0 functions), while a private key operation is in progress.
Instead, we do the following:
- There is no actual need to minimize n, p, and q, but we have minimized
copies in the BN_MONT_CTXs, so use those.
- Store additional copies of d, dmp1, and dmq1, at the cost of more
memory used. These copies have the correct width and are private,
unlike d, dmp1, and dmq1 which are sadly exposed. Fix private key
operations to use them.
- Move the frozen bit out of rsa->flags, as that too was historically
accessible without locking.
(Serialization still uses the original BIGNUMs, but the RSAPrivateKey
serialization format already inherently leaks the magnitude, so this
doesn't matter.)
Change-Id: Ia3a9b0629f8efef23abb30bfed110d247d1db42f
Reviewed-on: https://boringssl-review.googlesource.com/25824
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
2018-02-09 20:52:58 +00:00
|
|
|
|
int frozen = rsa->private_key_frozen;
|
2018-01-23 21:48:53 +00:00
|
|
|
|
CRYPTO_MUTEX_unlock_read(&rsa->lock);
|
Fix threading issues with RSA freeze_private_key.
OpenSSL's RSA API is poorly designed and does not have a single place to
properly initialize the key. See
https://github.com/openssl/openssl/issues/5158.
To workaround this flaw, we must lazily instantiate pre-computed
Montgomery bits with locking. This is a ton of complexity. More
importantly, it makes it very difficult to implement RSA without side
channels. The correct in-memory representation of d, dmp1, and dmq1
depend on n, p, and q, respectively. (Those values have private
magnitudes and must be sized relative to the respective moduli.)
08805fe27910e09d05e87d61bc5411a4e3b2d999 attempted to fix up the various
widths under lock, when we set up BN_MONT_CTX. However, this introduces
threading issues because other threads may access those exposed
components (RSA_get0_* also count as exposed for these purposes because
they are get0 functions), while a private key operation is in progress.
Instead, we do the following:
- There is no actual need to minimize n, p, and q, but we have minimized
copies in the BN_MONT_CTXs, so use those.
- Store additional copies of d, dmp1, and dmq1, at the cost of more
memory used. These copies have the correct width and are private,
unlike d, dmp1, and dmq1 which are sadly exposed. Fix private key
operations to use them.
- Move the frozen bit out of rsa->flags, as that too was historically
accessible without locking.
(Serialization still uses the original BIGNUMs, but the RSAPrivateKey
serialization format already inherently leaks the magnitude, so this
doesn't matter.)
Change-Id: Ia3a9b0629f8efef23abb30bfed110d247d1db42f
Reviewed-on: https://boringssl-review.googlesource.com/25824
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
2018-02-09 20:52:58 +00:00
|
|
|
|
if (frozen) {
|
2018-01-23 21:48:53 +00:00
|
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int ret = 0;
|
|
|
|
|
CRYPTO_MUTEX_lock_write(&rsa->lock);
|
Fix threading issues with RSA freeze_private_key.
OpenSSL's RSA API is poorly designed and does not have a single place to
properly initialize the key. See
https://github.com/openssl/openssl/issues/5158.
To workaround this flaw, we must lazily instantiate pre-computed
Montgomery bits with locking. This is a ton of complexity. More
importantly, it makes it very difficult to implement RSA without side
channels. The correct in-memory representation of d, dmp1, and dmq1
depend on n, p, and q, respectively. (Those values have private
magnitudes and must be sized relative to the respective moduli.)
08805fe27910e09d05e87d61bc5411a4e3b2d999 attempted to fix up the various
widths under lock, when we set up BN_MONT_CTX. However, this introduces
threading issues because other threads may access those exposed
components (RSA_get0_* also count as exposed for these purposes because
they are get0 functions), while a private key operation is in progress.
Instead, we do the following:
- There is no actual need to minimize n, p, and q, but we have minimized
copies in the BN_MONT_CTXs, so use those.
- Store additional copies of d, dmp1, and dmq1, at the cost of more
memory used. These copies have the correct width and are private,
unlike d, dmp1, and dmq1 which are sadly exposed. Fix private key
operations to use them.
- Move the frozen bit out of rsa->flags, as that too was historically
accessible without locking.
(Serialization still uses the original BIGNUMs, but the RSAPrivateKey
serialization format already inherently leaks the magnitude, so this
doesn't matter.)
Change-Id: Ia3a9b0629f8efef23abb30bfed110d247d1db42f
Reviewed-on: https://boringssl-review.googlesource.com/25824
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
2018-02-09 20:52:58 +00:00
|
|
|
|
if (rsa->private_key_frozen) {
|
2018-01-23 21:48:53 +00:00
|
|
|
|
ret = 1;
|
|
|
|
|
goto err;
|
|
|
|
|
}
|
|
|
|
|
|
Fix threading issues with RSA freeze_private_key.
OpenSSL's RSA API is poorly designed and does not have a single place to
properly initialize the key. See
https://github.com/openssl/openssl/issues/5158.
To workaround this flaw, we must lazily instantiate pre-computed
Montgomery bits with locking. This is a ton of complexity. More
importantly, it makes it very difficult to implement RSA without side
channels. The correct in-memory representation of d, dmp1, and dmq1
depend on n, p, and q, respectively. (Those values have private
magnitudes and must be sized relative to the respective moduli.)
08805fe27910e09d05e87d61bc5411a4e3b2d999 attempted to fix up the various
widths under lock, when we set up BN_MONT_CTX. However, this introduces
threading issues because other threads may access those exposed
components (RSA_get0_* also count as exposed for these purposes because
they are get0 functions), while a private key operation is in progress.
Instead, we do the following:
- There is no actual need to minimize n, p, and q, but we have minimized
copies in the BN_MONT_CTXs, so use those.
- Store additional copies of d, dmp1, and dmq1, at the cost of more
memory used. These copies have the correct width and are private,
unlike d, dmp1, and dmq1 which are sadly exposed. Fix private key
operations to use them.
- Move the frozen bit out of rsa->flags, as that too was historically
accessible without locking.
(Serialization still uses the original BIGNUMs, but the RSAPrivateKey
serialization format already inherently leaks the magnitude, so this
doesn't matter.)
Change-Id: Ia3a9b0629f8efef23abb30bfed110d247d1db42f
Reviewed-on: https://boringssl-review.googlesource.com/25824
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
2018-02-09 20:52:58 +00:00
|
|
|
|
// Pre-compute various intermediate values, as well as copies of private
|
|
|
|
|
// exponents with correct widths. Note that other threads may concurrently
|
|
|
|
|
// read from |rsa->n|, |rsa->e|, etc., so any fixes must be in separate
|
|
|
|
|
// copies. We use |mont_n->N|, |mont_p->N|, and |mont_q->N| as copies of |n|,
|
|
|
|
|
// |p|, and |q| with the correct minimal widths.
|
|
|
|
|
|
2018-01-23 21:48:53 +00:00
|
|
|
|
if (rsa->mont_n == NULL) {
|
|
|
|
|
rsa->mont_n = BN_MONT_CTX_new_for_modulus(rsa->n, ctx);
|
|
|
|
|
if (rsa->mont_n == NULL) {
|
|
|
|
|
goto err;
|
|
|
|
|
}
|
|
|
|
|
}
|
Fix threading issues with RSA freeze_private_key.
OpenSSL's RSA API is poorly designed and does not have a single place to
properly initialize the key. See
https://github.com/openssl/openssl/issues/5158.
To workaround this flaw, we must lazily instantiate pre-computed
Montgomery bits with locking. This is a ton of complexity. More
importantly, it makes it very difficult to implement RSA without side
channels. The correct in-memory representation of d, dmp1, and dmq1
depend on n, p, and q, respectively. (Those values have private
magnitudes and must be sized relative to the respective moduli.)
08805fe27910e09d05e87d61bc5411a4e3b2d999 attempted to fix up the various
widths under lock, when we set up BN_MONT_CTX. However, this introduces
threading issues because other threads may access those exposed
components (RSA_get0_* also count as exposed for these purposes because
they are get0 functions), while a private key operation is in progress.
Instead, we do the following:
- There is no actual need to minimize n, p, and q, but we have minimized
copies in the BN_MONT_CTXs, so use those.
- Store additional copies of d, dmp1, and dmq1, at the cost of more
memory used. These copies have the correct width and are private,
unlike d, dmp1, and dmq1 which are sadly exposed. Fix private key
operations to use them.
- Move the frozen bit out of rsa->flags, as that too was historically
accessible without locking.
(Serialization still uses the original BIGNUMs, but the RSAPrivateKey
serialization format already inherently leaks the magnitude, so this
doesn't matter.)
Change-Id: Ia3a9b0629f8efef23abb30bfed110d247d1db42f
Reviewed-on: https://boringssl-review.googlesource.com/25824
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
2018-02-09 20:52:58 +00:00
|
|
|
|
const BIGNUM *n_fixed = &rsa->mont_n->N;
|
2018-01-23 21:48:53 +00:00
|
|
|
|
|
|
|
|
|
// The only public upper-bound of |rsa->d| is the bit length of |rsa->n|. The
|
|
|
|
|
// ASN.1 serialization of RSA private keys unfortunately leaks the byte length
|
|
|
|
|
// of |rsa->d|, but normalize it so we only leak it once, rather than per
|
|
|
|
|
// operation.
|
|
|
|
|
if (rsa->d != NULL &&
|
Fix threading issues with RSA freeze_private_key.
OpenSSL's RSA API is poorly designed and does not have a single place to
properly initialize the key. See
https://github.com/openssl/openssl/issues/5158.
To workaround this flaw, we must lazily instantiate pre-computed
Montgomery bits with locking. This is a ton of complexity. More
importantly, it makes it very difficult to implement RSA without side
channels. The correct in-memory representation of d, dmp1, and dmq1
depend on n, p, and q, respectively. (Those values have private
magnitudes and must be sized relative to the respective moduli.)
08805fe27910e09d05e87d61bc5411a4e3b2d999 attempted to fix up the various
widths under lock, when we set up BN_MONT_CTX. However, this introduces
threading issues because other threads may access those exposed
components (RSA_get0_* also count as exposed for these purposes because
they are get0 functions), while a private key operation is in progress.
Instead, we do the following:
- There is no actual need to minimize n, p, and q, but we have minimized
copies in the BN_MONT_CTXs, so use those.
- Store additional copies of d, dmp1, and dmq1, at the cost of more
memory used. These copies have the correct width and are private,
unlike d, dmp1, and dmq1 which are sadly exposed. Fix private key
operations to use them.
- Move the frozen bit out of rsa->flags, as that too was historically
accessible without locking.
(Serialization still uses the original BIGNUMs, but the RSAPrivateKey
serialization format already inherently leaks the magnitude, so this
doesn't matter.)
Change-Id: Ia3a9b0629f8efef23abb30bfed110d247d1db42f
Reviewed-on: https://boringssl-review.googlesource.com/25824
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
2018-02-09 20:52:58 +00:00
|
|
|
|
!ensure_fixed_copy(&rsa->d_fixed, rsa->d, n_fixed->width)) {
|
2018-01-23 21:48:53 +00:00
|
|
|
|
goto err;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (rsa->p != NULL && rsa->q != NULL) {
|
|
|
|
|
if (rsa->mont_p == NULL) {
|
Restore the BN_mod codepath for public Montgomery moduli.
https://boringssl-review.googlesource.com/10520 and then later
https://boringssl-review.googlesource.com/25285 made BN_MONT_CTX_set
constant-time, which is necessary for RSA's mont_p and mont_q. However,
due to a typo in the benchmark, they did not correctly measure.
Split BN_MONT_CTX creation into a constant-time and variable-time one.
The constant-time one uses our current algorithm and the latter restores
the original BN_mod codepath.
Should we wish to avoid BN_mod, I have an alternate version lying
around:
First, BN_set_bit + bn_mod_lshift1_consttime as now to count up to 2*R.
Next, observe that 2*R = BN_to_montgomery(2) and R*R =
BN_to_montgomery(R) = BN_to_montgomery(2^r_bits) Also observe that
BN_mod_mul_montgomery only needs n0, not RR. Split the core of
BN_mod_exp_mont into its own function so the caller handles conversion.
Raise 2*R to the r_bits power to get 2^r_bits*R = R*R.
The advantage of that algorithm is that it is still constant-time, so we
only need one BN_MONT_CTX_new. Additionally, it avoids BN_mod which is
otherwise (almost, but the remaining links should be easy to cut) out of
the critical path for correctness. One less operation to worry about.
The disadvantage is that it is gives a 25% (RSA-2048) or 32% (RSA-4096)
slower RSA verification speed. I went with the BN_mod one for the time
being.
Before:
Did 9204 RSA 2048 signing operations in 10052053us (915.6 ops/sec)
Did 326000 RSA 2048 verify (same key) operations in 10028823us (32506.3 ops/sec)
Did 50830 RSA 2048 verify (fresh key) operations in 10033794us (5065.9 ops/sec)
Did 1269 RSA 4096 signing operations in 10019204us (126.7 ops/sec)
Did 88435 RSA 4096 verify (same key) operations in 10031129us (8816.1 ops/sec)
Did 14552 RSA 4096 verify (fresh key) operations in 10053411us (1447.5 ops/sec)
After:
Did 9150 RSA 2048 signing operations in 10022831us (912.9 ops/sec)
Did 322000 RSA 2048 verify (same key) operations in 10028604us (32108.2 ops/sec)
Did 289000 RSA 2048 verify (fresh key) operations in 10017205us (28850.4 ops/sec)
Did 1270 RSA 4096 signing operations in 10072950us (126.1 ops/sec)
Did 87480 RSA 4096 verify (same key) operations in 10036328us (8716.3 ops/sec)
Did 80730 RSA 4096 verify (fresh key) operations in 10073614us (8014.0 ops/sec)
Change-Id: Ie8916d1634ccf8513ceda458fa302f09f3e93c07
Reviewed-on: https://boringssl-review.googlesource.com/27287
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
2018-04-10 21:46:33 +01:00
|
|
|
|
rsa->mont_p = BN_MONT_CTX_new_consttime(rsa->p, ctx);
|
2018-01-23 21:48:53 +00:00
|
|
|
|
if (rsa->mont_p == NULL) {
|
|
|
|
|
goto err;
|
|
|
|
|
}
|
|
|
|
|
}
|
Fix threading issues with RSA freeze_private_key.
OpenSSL's RSA API is poorly designed and does not have a single place to
properly initialize the key. See
https://github.com/openssl/openssl/issues/5158.
To workaround this flaw, we must lazily instantiate pre-computed
Montgomery bits with locking. This is a ton of complexity. More
importantly, it makes it very difficult to implement RSA without side
channels. The correct in-memory representation of d, dmp1, and dmq1
depend on n, p, and q, respectively. (Those values have private
magnitudes and must be sized relative to the respective moduli.)
08805fe27910e09d05e87d61bc5411a4e3b2d999 attempted to fix up the various
widths under lock, when we set up BN_MONT_CTX. However, this introduces
threading issues because other threads may access those exposed
components (RSA_get0_* also count as exposed for these purposes because
they are get0 functions), while a private key operation is in progress.
Instead, we do the following:
- There is no actual need to minimize n, p, and q, but we have minimized
copies in the BN_MONT_CTXs, so use those.
- Store additional copies of d, dmp1, and dmq1, at the cost of more
memory used. These copies have the correct width and are private,
unlike d, dmp1, and dmq1 which are sadly exposed. Fix private key
operations to use them.
- Move the frozen bit out of rsa->flags, as that too was historically
accessible without locking.
(Serialization still uses the original BIGNUMs, but the RSAPrivateKey
serialization format already inherently leaks the magnitude, so this
doesn't matter.)
Change-Id: Ia3a9b0629f8efef23abb30bfed110d247d1db42f
Reviewed-on: https://boringssl-review.googlesource.com/25824
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
2018-02-09 20:52:58 +00:00
|
|
|
|
const BIGNUM *p_fixed = &rsa->mont_p->N;
|
2018-01-23 21:48:53 +00:00
|
|
|
|
|
|
|
|
|
if (rsa->mont_q == NULL) {
|
Restore the BN_mod codepath for public Montgomery moduli.
https://boringssl-review.googlesource.com/10520 and then later
https://boringssl-review.googlesource.com/25285 made BN_MONT_CTX_set
constant-time, which is necessary for RSA's mont_p and mont_q. However,
due to a typo in the benchmark, they did not correctly measure.
Split BN_MONT_CTX creation into a constant-time and variable-time one.
The constant-time one uses our current algorithm and the latter restores
the original BN_mod codepath.
Should we wish to avoid BN_mod, I have an alternate version lying
around:
First, BN_set_bit + bn_mod_lshift1_consttime as now to count up to 2*R.
Next, observe that 2*R = BN_to_montgomery(2) and R*R =
BN_to_montgomery(R) = BN_to_montgomery(2^r_bits) Also observe that
BN_mod_mul_montgomery only needs n0, not RR. Split the core of
BN_mod_exp_mont into its own function so the caller handles conversion.
Raise 2*R to the r_bits power to get 2^r_bits*R = R*R.
The advantage of that algorithm is that it is still constant-time, so we
only need one BN_MONT_CTX_new. Additionally, it avoids BN_mod which is
otherwise (almost, but the remaining links should be easy to cut) out of
the critical path for correctness. One less operation to worry about.
The disadvantage is that it is gives a 25% (RSA-2048) or 32% (RSA-4096)
slower RSA verification speed. I went with the BN_mod one for the time
being.
Before:
Did 9204 RSA 2048 signing operations in 10052053us (915.6 ops/sec)
Did 326000 RSA 2048 verify (same key) operations in 10028823us (32506.3 ops/sec)
Did 50830 RSA 2048 verify (fresh key) operations in 10033794us (5065.9 ops/sec)
Did 1269 RSA 4096 signing operations in 10019204us (126.7 ops/sec)
Did 88435 RSA 4096 verify (same key) operations in 10031129us (8816.1 ops/sec)
Did 14552 RSA 4096 verify (fresh key) operations in 10053411us (1447.5 ops/sec)
After:
Did 9150 RSA 2048 signing operations in 10022831us (912.9 ops/sec)
Did 322000 RSA 2048 verify (same key) operations in 10028604us (32108.2 ops/sec)
Did 289000 RSA 2048 verify (fresh key) operations in 10017205us (28850.4 ops/sec)
Did 1270 RSA 4096 signing operations in 10072950us (126.1 ops/sec)
Did 87480 RSA 4096 verify (same key) operations in 10036328us (8716.3 ops/sec)
Did 80730 RSA 4096 verify (fresh key) operations in 10073614us (8014.0 ops/sec)
Change-Id: Ie8916d1634ccf8513ceda458fa302f09f3e93c07
Reviewed-on: https://boringssl-review.googlesource.com/27287
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
2018-04-10 21:46:33 +01:00
|
|
|
|
rsa->mont_q = BN_MONT_CTX_new_consttime(rsa->q, ctx);
|
2018-01-23 21:48:53 +00:00
|
|
|
|
if (rsa->mont_q == NULL) {
|
|
|
|
|
goto err;
|
|
|
|
|
}
|
|
|
|
|
}
|
Fix threading issues with RSA freeze_private_key.
OpenSSL's RSA API is poorly designed and does not have a single place to
properly initialize the key. See
https://github.com/openssl/openssl/issues/5158.
To workaround this flaw, we must lazily instantiate pre-computed
Montgomery bits with locking. This is a ton of complexity. More
importantly, it makes it very difficult to implement RSA without side
channels. The correct in-memory representation of d, dmp1, and dmq1
depend on n, p, and q, respectively. (Those values have private
magnitudes and must be sized relative to the respective moduli.)
08805fe27910e09d05e87d61bc5411a4e3b2d999 attempted to fix up the various
widths under lock, when we set up BN_MONT_CTX. However, this introduces
threading issues because other threads may access those exposed
components (RSA_get0_* also count as exposed for these purposes because
they are get0 functions), while a private key operation is in progress.
Instead, we do the following:
- There is no actual need to minimize n, p, and q, but we have minimized
copies in the BN_MONT_CTXs, so use those.
- Store additional copies of d, dmp1, and dmq1, at the cost of more
memory used. These copies have the correct width and are private,
unlike d, dmp1, and dmq1 which are sadly exposed. Fix private key
operations to use them.
- Move the frozen bit out of rsa->flags, as that too was historically
accessible without locking.
(Serialization still uses the original BIGNUMs, but the RSAPrivateKey
serialization format already inherently leaks the magnitude, so this
doesn't matter.)
Change-Id: Ia3a9b0629f8efef23abb30bfed110d247d1db42f
Reviewed-on: https://boringssl-review.googlesource.com/25824
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
2018-02-09 20:52:58 +00:00
|
|
|
|
const BIGNUM *q_fixed = &rsa->mont_q->N;
|
2018-01-23 21:48:53 +00:00
|
|
|
|
|
Make the rest of RSA CRT constant-time.
Alas, the existence of RSA keys with q > p is obnoxious, but we can
canonicalize it away. To my knowledge, the remaining leaks in RSA are:
- Key generation. This is kind of hopelessly non-constant-time but
perhaps deserves a more careful ponder. Though hopefully it does not
come in at a measurable point for practical purposes.
- Private key serialization. RSAPrivateKey inherently leaks the
magnitudes of d, dmp1, dmq1, and iqmp. This is unavoidable but
hopefully does not come in at a measurable point for practical
purposes.
- If p and q have different word widths, we currently fall back to the
variable-time BN_mod rather than Montgomery reduction at the start of
CRT. I can think of ways to apply Montgomery reduction, but it's
probably better to deny CRT to such keys, if not reject them outright.
- bn_mul_fixed and bn_sqr_fixed which affect the Montgomery
multiplication bn_mul_mont-less configurations, as well as the final
CRT multiplication. We should fix this.
Bug: 233
Change-Id: I8c2ecf8f8ec104e9f26299b66ac8cbb0cad04616
Reviewed-on: https://boringssl-review.googlesource.com/25263
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
2018-01-24 22:22:17 +00:00
|
|
|
|
if (rsa->dmp1 != NULL && rsa->dmq1 != NULL) {
|
|
|
|
|
// Key generation relies on this function to compute |iqmp|.
|
|
|
|
|
if (rsa->iqmp == NULL) {
|
|
|
|
|
BIGNUM *iqmp = BN_new();
|
|
|
|
|
if (iqmp == NULL ||
|
|
|
|
|
!bn_mod_inverse_secret_prime(iqmp, rsa->q, rsa->p, ctx,
|
|
|
|
|
rsa->mont_p)) {
|
|
|
|
|
BN_free(iqmp);
|
|
|
|
|
goto err;
|
|
|
|
|
}
|
|
|
|
|
rsa->iqmp = iqmp;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// CRT components are only publicly bounded by their corresponding
|
Fix threading issues with RSA freeze_private_key.
OpenSSL's RSA API is poorly designed and does not have a single place to
properly initialize the key. See
https://github.com/openssl/openssl/issues/5158.
To workaround this flaw, we must lazily instantiate pre-computed
Montgomery bits with locking. This is a ton of complexity. More
importantly, it makes it very difficult to implement RSA without side
channels. The correct in-memory representation of d, dmp1, and dmq1
depend on n, p, and q, respectively. (Those values have private
magnitudes and must be sized relative to the respective moduli.)
08805fe27910e09d05e87d61bc5411a4e3b2d999 attempted to fix up the various
widths under lock, when we set up BN_MONT_CTX. However, this introduces
threading issues because other threads may access those exposed
components (RSA_get0_* also count as exposed for these purposes because
they are get0 functions), while a private key operation is in progress.
Instead, we do the following:
- There is no actual need to minimize n, p, and q, but we have minimized
copies in the BN_MONT_CTXs, so use those.
- Store additional copies of d, dmp1, and dmq1, at the cost of more
memory used. These copies have the correct width and are private,
unlike d, dmp1, and dmq1 which are sadly exposed. Fix private key
operations to use them.
- Move the frozen bit out of rsa->flags, as that too was historically
accessible without locking.
(Serialization still uses the original BIGNUMs, but the RSAPrivateKey
serialization format already inherently leaks the magnitude, so this
doesn't matter.)
Change-Id: Ia3a9b0629f8efef23abb30bfed110d247d1db42f
Reviewed-on: https://boringssl-review.googlesource.com/25824
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
2018-02-09 20:52:58 +00:00
|
|
|
|
// moduli's bit lengths. |rsa->iqmp| is unused outside of this one-time
|
|
|
|
|
// setup, so we do not compute a fixed-width version of it.
|
|
|
|
|
if (!ensure_fixed_copy(&rsa->dmp1_fixed, rsa->dmp1, p_fixed->width) ||
|
|
|
|
|
!ensure_fixed_copy(&rsa->dmq1_fixed, rsa->dmq1, q_fixed->width)) {
|
Make the rest of RSA CRT constant-time.
Alas, the existence of RSA keys with q > p is obnoxious, but we can
canonicalize it away. To my knowledge, the remaining leaks in RSA are:
- Key generation. This is kind of hopelessly non-constant-time but
perhaps deserves a more careful ponder. Though hopefully it does not
come in at a measurable point for practical purposes.
- Private key serialization. RSAPrivateKey inherently leaks the
magnitudes of d, dmp1, dmq1, and iqmp. This is unavoidable but
hopefully does not come in at a measurable point for practical
purposes.
- If p and q have different word widths, we currently fall back to the
variable-time BN_mod rather than Montgomery reduction at the start of
CRT. I can think of ways to apply Montgomery reduction, but it's
probably better to deny CRT to such keys, if not reject them outright.
- bn_mul_fixed and bn_sqr_fixed which affect the Montgomery
multiplication bn_mul_mont-less configurations, as well as the final
CRT multiplication. We should fix this.
Bug: 233
Change-Id: I8c2ecf8f8ec104e9f26299b66ac8cbb0cad04616
Reviewed-on: https://boringssl-review.googlesource.com/25263
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
2018-01-24 22:22:17 +00:00
|
|
|
|
goto err;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Compute |inv_small_mod_large_mont|. Note that it is always modulo the
|
|
|
|
|
// larger prime, independent of what is stored in |rsa->iqmp|.
|
|
|
|
|
if (rsa->inv_small_mod_large_mont == NULL) {
|
|
|
|
|
BIGNUM *inv_small_mod_large_mont = BN_new();
|
|
|
|
|
int ok;
|
2018-01-27 23:54:28 +00:00
|
|
|
|
if (BN_cmp(rsa->p, rsa->q) < 0) {
|
Make the rest of RSA CRT constant-time.
Alas, the existence of RSA keys with q > p is obnoxious, but we can
canonicalize it away. To my knowledge, the remaining leaks in RSA are:
- Key generation. This is kind of hopelessly non-constant-time but
perhaps deserves a more careful ponder. Though hopefully it does not
come in at a measurable point for practical purposes.
- Private key serialization. RSAPrivateKey inherently leaks the
magnitudes of d, dmp1, dmq1, and iqmp. This is unavoidable but
hopefully does not come in at a measurable point for practical
purposes.
- If p and q have different word widths, we currently fall back to the
variable-time BN_mod rather than Montgomery reduction at the start of
CRT. I can think of ways to apply Montgomery reduction, but it's
probably better to deny CRT to such keys, if not reject them outright.
- bn_mul_fixed and bn_sqr_fixed which affect the Montgomery
multiplication bn_mul_mont-less configurations, as well as the final
CRT multiplication. We should fix this.
Bug: 233
Change-Id: I8c2ecf8f8ec104e9f26299b66ac8cbb0cad04616
Reviewed-on: https://boringssl-review.googlesource.com/25263
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
2018-01-24 22:22:17 +00:00
|
|
|
|
ok = inv_small_mod_large_mont != NULL &&
|
|
|
|
|
bn_mod_inverse_secret_prime(inv_small_mod_large_mont, rsa->p,
|
|
|
|
|
rsa->q, ctx, rsa->mont_q) &&
|
|
|
|
|
BN_to_montgomery(inv_small_mod_large_mont,
|
|
|
|
|
inv_small_mod_large_mont, rsa->mont_q, ctx);
|
|
|
|
|
} else {
|
|
|
|
|
ok = inv_small_mod_large_mont != NULL &&
|
|
|
|
|
BN_to_montgomery(inv_small_mod_large_mont, rsa->iqmp,
|
|
|
|
|
rsa->mont_p, ctx);
|
|
|
|
|
}
|
|
|
|
|
if (!ok) {
|
|
|
|
|
BN_free(inv_small_mod_large_mont);
|
|
|
|
|
goto err;
|
|
|
|
|
}
|
|
|
|
|
rsa->inv_small_mod_large_mont = inv_small_mod_large_mont;
|
|
|
|
|
}
|
2018-01-23 21:48:53 +00:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
Fix threading issues with RSA freeze_private_key.
OpenSSL's RSA API is poorly designed and does not have a single place to
properly initialize the key. See
https://github.com/openssl/openssl/issues/5158.
To workaround this flaw, we must lazily instantiate pre-computed
Montgomery bits with locking. This is a ton of complexity. More
importantly, it makes it very difficult to implement RSA without side
channels. The correct in-memory representation of d, dmp1, and dmq1
depend on n, p, and q, respectively. (Those values have private
magnitudes and must be sized relative to the respective moduli.)
08805fe27910e09d05e87d61bc5411a4e3b2d999 attempted to fix up the various
widths under lock, when we set up BN_MONT_CTX. However, this introduces
threading issues because other threads may access those exposed
components (RSA_get0_* also count as exposed for these purposes because
they are get0 functions), while a private key operation is in progress.
Instead, we do the following:
- There is no actual need to minimize n, p, and q, but we have minimized
copies in the BN_MONT_CTXs, so use those.
- Store additional copies of d, dmp1, and dmq1, at the cost of more
memory used. These copies have the correct width and are private,
unlike d, dmp1, and dmq1 which are sadly exposed. Fix private key
operations to use them.
- Move the frozen bit out of rsa->flags, as that too was historically
accessible without locking.
(Serialization still uses the original BIGNUMs, but the RSAPrivateKey
serialization format already inherently leaks the magnitude, so this
doesn't matter.)
Change-Id: Ia3a9b0629f8efef23abb30bfed110d247d1db42f
Reviewed-on: https://boringssl-review.googlesource.com/25824
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
2018-02-09 20:52:58 +00:00
|
|
|
|
rsa->private_key_frozen = 1;
|
2018-01-23 21:48:53 +00:00
|
|
|
|
ret = 1;
|
|
|
|
|
|
|
|
|
|
err:
|
|
|
|
|
CRYPTO_MUTEX_unlock_write(&rsa->lock);
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
2015-10-29 17:19:12 +00:00
|
|
|
|
size_t rsa_default_size(const RSA *rsa) {
|
2014-07-11 19:14:08 +01:00
|
|
|
|
return BN_num_bytes(rsa->n);
|
|
|
|
|
}
|
|
|
|
|
|
2017-05-03 20:03:35 +01:00
|
|
|
|
int RSA_encrypt(RSA *rsa, size_t *out_len, uint8_t *out, size_t max_out,
|
|
|
|
|
const uint8_t *in, size_t in_len, int padding) {
|
|
|
|
|
if (rsa->n == NULL || rsa->e == NULL) {
|
|
|
|
|
OPENSSL_PUT_ERROR(RSA, RSA_R_VALUE_MISSING);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2014-06-20 20:00:00 +01:00
|
|
|
|
const unsigned rsa_size = RSA_size(rsa);
|
|
|
|
|
BIGNUM *f, *result;
|
|
|
|
|
uint8_t *buf = NULL;
|
|
|
|
|
BN_CTX *ctx = NULL;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
int i, ret = 0;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
|
|
|
|
if (max_out < rsa_size) {
|
2015-06-29 05:28:17 +01:00
|
|
|
|
OPENSSL_PUT_ERROR(RSA, RSA_R_OUTPUT_BUFFER_TOO_SMALL);
|
2014-06-20 20:00:00 +01:00
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2016-01-12 20:47:25 +00:00
|
|
|
|
if (!check_modulus_and_exponent_sizes(rsa)) {
|
2014-06-20 20:00:00 +01:00
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ctx = BN_CTX_new();
|
|
|
|
|
if (ctx == NULL) {
|
|
|
|
|
goto err;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
BN_CTX_start(ctx);
|
|
|
|
|
f = BN_CTX_get(ctx);
|
|
|
|
|
result = BN_CTX_get(ctx);
|
|
|
|
|
buf = OPENSSL_malloc(rsa_size);
|
|
|
|
|
if (!f || !result || !buf) {
|
2015-06-29 05:28:17 +01:00
|
|
|
|
OPENSSL_PUT_ERROR(RSA, ERR_R_MALLOC_FAILURE);
|
2014-06-20 20:00:00 +01:00
|
|
|
|
goto err;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
switch (padding) {
|
|
|
|
|
case RSA_PKCS1_PADDING:
|
|
|
|
|
i = RSA_padding_add_PKCS1_type_2(buf, rsa_size, in, in_len);
|
|
|
|
|
break;
|
|
|
|
|
case RSA_PKCS1_OAEP_PADDING:
|
2017-08-18 19:06:02 +01:00
|
|
|
|
// Use the default parameters: SHA-1 for both hashes and no label.
|
2014-06-20 20:00:00 +01:00
|
|
|
|
i = RSA_padding_add_PKCS1_OAEP_mgf1(buf, rsa_size, in, in_len,
|
|
|
|
|
NULL, 0, NULL, NULL);
|
2014-06-20 20:00:00 +01:00
|
|
|
|
break;
|
|
|
|
|
case RSA_NO_PADDING:
|
|
|
|
|
i = RSA_padding_add_none(buf, rsa_size, in, in_len);
|
|
|
|
|
break;
|
|
|
|
|
default:
|
2015-06-29 05:28:17 +01:00
|
|
|
|
OPENSSL_PUT_ERROR(RSA, RSA_R_UNKNOWN_PADDING_TYPE);
|
2014-06-20 20:00:00 +01:00
|
|
|
|
goto err;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (i <= 0) {
|
|
|
|
|
goto err;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (BN_bin2bn(buf, rsa_size, f) == NULL) {
|
|
|
|
|
goto err;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (BN_ucmp(f, rsa->n) >= 0) {
|
2017-08-18 19:06:02 +01:00
|
|
|
|
// usually the padding functions would catch this
|
Tweak RSA errors for compatibility.
cryptography.io wants RSA_R_BLOCK_TYPE_IS_NOT_02, only used by the
ancient RSA_padding_check_SSLv23 function. Define it but never emit it.
Additionally, it's rather finicky about RSA_R_TOO_LARGE* errors. We
merged them in BoringSSL because having RSA_R_TOO_LARGE,
RSA_R_TOO_LARGE_FOR_MODULUS, and RSA_R_TOO_LARGE_FOR_KEY_SIZE is a
little silly. But since we don't expect well-behaved code to condition
on error codes anyway, perhaps that wasn't worth it. Split them back
up.
Looking through OpenSSL, there is a vague semantic difference:
RSA_R_DIGEST_TOO_BIG_FOR_RSA_KEY - Specifically emitted if a digest is
too big for PKCS#1 signing with this key.
RSA_R_DATA_TOO_LARGE_FOR_KEY_SIZE - You asked me to sign or encrypt a
digest/plaintext, but it's too big for this key.
RSA_R_DATA_TOO_LARGE_FOR_MODULUS - You gave me an RSA ciphertext or
signature and it is not fully reduced modulo N.
-OR-
The padding functions produced something that isn't reduced, but I
believe this is unreachable outside of RSA_NO_PADDING.
RSA_R_DATA_TOO_LARGE - Some low-level padding function was told to copy
a digest/plaintext into some buffer, but the buffer was too small. I
think this is basically unreachable.
-OR-
You asked me to verify a PSS signature, but I didn't need to bother
because the digest/salt parameters you picked were too big.
Update-Note: This depends on cl/196566462.
Change-Id: I2e539e075eff8bfcd52ccde365e975ebcee72567
Reviewed-on: https://boringssl-review.googlesource.com/28547
Reviewed-by: Adam Langley <agl@google.com>
2018-05-14 23:10:14 +01:00
|
|
|
|
OPENSSL_PUT_ERROR(RSA, RSA_R_DATA_TOO_LARGE_FOR_MODULUS);
|
2014-06-20 20:00:00 +01:00
|
|
|
|
goto err;
|
|
|
|
|
}
|
|
|
|
|
|
2016-03-25 20:11:04 +00:00
|
|
|
|
if (!BN_MONT_CTX_set_locked(&rsa->mont_n, &rsa->lock, rsa->n, ctx) ||
|
Fix threading issues with RSA freeze_private_key.
OpenSSL's RSA API is poorly designed and does not have a single place to
properly initialize the key. See
https://github.com/openssl/openssl/issues/5158.
To workaround this flaw, we must lazily instantiate pre-computed
Montgomery bits with locking. This is a ton of complexity. More
importantly, it makes it very difficult to implement RSA without side
channels. The correct in-memory representation of d, dmp1, and dmq1
depend on n, p, and q, respectively. (Those values have private
magnitudes and must be sized relative to the respective moduli.)
08805fe27910e09d05e87d61bc5411a4e3b2d999 attempted to fix up the various
widths under lock, when we set up BN_MONT_CTX. However, this introduces
threading issues because other threads may access those exposed
components (RSA_get0_* also count as exposed for these purposes because
they are get0 functions), while a private key operation is in progress.
Instead, we do the following:
- There is no actual need to minimize n, p, and q, but we have minimized
copies in the BN_MONT_CTXs, so use those.
- Store additional copies of d, dmp1, and dmq1, at the cost of more
memory used. These copies have the correct width and are private,
unlike d, dmp1, and dmq1 which are sadly exposed. Fix private key
operations to use them.
- Move the frozen bit out of rsa->flags, as that too was historically
accessible without locking.
(Serialization still uses the original BIGNUMs, but the RSAPrivateKey
serialization format already inherently leaks the magnitude, so this
doesn't matter.)
Change-Id: Ia3a9b0629f8efef23abb30bfed110d247d1db42f
Reviewed-on: https://boringssl-review.googlesource.com/25824
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
2018-02-09 20:52:58 +00:00
|
|
|
|
!BN_mod_exp_mont(result, f, rsa->e, &rsa->mont_n->N, ctx, rsa->mont_n)) {
|
2014-06-20 20:00:00 +01:00
|
|
|
|
goto err;
|
|
|
|
|
}
|
|
|
|
|
|
2017-08-18 19:06:02 +01:00
|
|
|
|
// put in leading 0 bytes if the number is less than the length of the
|
|
|
|
|
// modulus
|
2014-06-20 20:00:00 +01:00
|
|
|
|
if (!BN_bn2bin_padded(out, rsa_size, result)) {
|
2015-06-29 05:28:17 +01:00
|
|
|
|
OPENSSL_PUT_ERROR(RSA, ERR_R_INTERNAL_ERROR);
|
2014-06-20 20:00:00 +01:00
|
|
|
|
goto err;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
*out_len = rsa_size;
|
|
|
|
|
ret = 1;
|
|
|
|
|
|
|
|
|
|
err:
|
|
|
|
|
if (ctx != NULL) {
|
|
|
|
|
BN_CTX_end(ctx);
|
|
|
|
|
BN_CTX_free(ctx);
|
|
|
|
|
}
|
2017-08-30 18:49:05 +01:00
|
|
|
|
OPENSSL_free(buf);
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
2017-08-18 19:06:02 +01:00
|
|
|
|
// MAX_BLINDINGS_PER_RSA defines the maximum number of cached BN_BLINDINGs per
|
|
|
|
|
// RSA*. Then this limit is exceeded, BN_BLINDING objects will be created and
|
|
|
|
|
// destroyed as needed.
|
2014-06-20 20:00:00 +01:00
|
|
|
|
#define MAX_BLINDINGS_PER_RSA 1024
|
|
|
|
|
|
2017-08-18 19:06:02 +01:00
|
|
|
|
// rsa_blinding_get returns a BN_BLINDING to use with |rsa|. It does this by
|
|
|
|
|
// allocating one of the cached BN_BLINDING objects in |rsa->blindings|. If
|
|
|
|
|
// none are free, the cache will be extended by a extra element and the new
|
|
|
|
|
// BN_BLINDING is returned.
|
|
|
|
|
//
|
|
|
|
|
// On success, the index of the assigned BN_BLINDING is written to
|
|
|
|
|
// |*index_used| and must be passed to |rsa_blinding_release| when finished.
|
2014-06-20 20:00:00 +01:00
|
|
|
|
static BN_BLINDING *rsa_blinding_get(RSA *rsa, unsigned *index_used,
|
|
|
|
|
BN_CTX *ctx) {
|
2016-03-18 02:10:04 +00:00
|
|
|
|
assert(ctx != NULL);
|
2016-03-21 21:25:39 +00:00
|
|
|
|
assert(rsa->mont_n != NULL);
|
|
|
|
|
|
2014-06-20 20:00:00 +01:00
|
|
|
|
BN_BLINDING *ret = NULL;
|
|
|
|
|
BN_BLINDING **new_blindings;
|
|
|
|
|
uint8_t *new_blindings_inuse;
|
|
|
|
|
char overflow = 0;
|
|
|
|
|
|
2015-04-13 19:04:14 +01:00
|
|
|
|
CRYPTO_MUTEX_lock_write(&rsa->lock);
|
2015-04-01 02:55:53 +01:00
|
|
|
|
|
|
|
|
|
unsigned i;
|
|
|
|
|
for (i = 0; i < rsa->num_blindings; i++) {
|
|
|
|
|
if (rsa->blindings_inuse[i] == 0) {
|
|
|
|
|
rsa->blindings_inuse[i] = 1;
|
|
|
|
|
ret = rsa->blindings[i];
|
|
|
|
|
*index_used = i;
|
|
|
|
|
break;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (ret != NULL) {
|
2016-05-24 16:28:36 +01:00
|
|
|
|
CRYPTO_MUTEX_unlock_write(&rsa->lock);
|
2014-06-20 20:00:00 +01:00
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
overflow = rsa->num_blindings >= MAX_BLINDINGS_PER_RSA;
|
|
|
|
|
|
2017-08-18 19:06:02 +01:00
|
|
|
|
// We didn't find a free BN_BLINDING to use so increase the length of
|
|
|
|
|
// the arrays by one and use the newly created element.
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
2016-05-24 16:28:36 +01:00
|
|
|
|
CRYPTO_MUTEX_unlock_write(&rsa->lock);
|
Require the public exponent to be available in RSA blinding.
Require the public exponent to be available unless
|RSA_FLAG_NO_BLINDING| is set on the key. Also, document this.
If the public exponent |e| is not available, then we could compute it
from |p|, |q|, and |d|. However, there's no reasonable situation in
which we'd have |p| or |q| but not |e|; either we have all the CRT
parameters, or we have (e, d, n), or we have only (d, n). The
calculation to compute |e| exposes the private key to risk of side
channel attacks.
Also, it was particularly wasteful to compute |e| for each
|BN_BLINDING| created, instead of just once before the first
|BN_BLINDING| was created.
|BN_BLINDING| now no longer needs to contain a duplicate copy of |e|,
so it is now more space-efficient.
Note that the condition |b->e != NULL| in |bn_blinding_update| was
always true since commit cbf56a5683ddda831ff91c46ea48d1fba545db66.
Change-Id: Ic2fd6980e0d359dcd53772a7c31bdd0267e316b4
Reviewed-on: https://boringssl-review.googlesource.com/7594
Reviewed-by: David Benjamin <davidben@google.com>
2016-03-27 06:42:31 +01:00
|
|
|
|
ret = BN_BLINDING_new();
|
2014-06-20 20:00:00 +01:00
|
|
|
|
if (ret == NULL) {
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (overflow) {
|
2017-08-18 19:06:02 +01:00
|
|
|
|
// We cannot add any more cached BN_BLINDINGs so we use |ret|
|
|
|
|
|
// and mark it for destruction in |rsa_blinding_release|.
|
2014-06-20 20:00:00 +01:00
|
|
|
|
*index_used = MAX_BLINDINGS_PER_RSA;
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
2015-04-13 19:04:14 +01:00
|
|
|
|
CRYPTO_MUTEX_lock_write(&rsa->lock);
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
|
|
|
|
new_blindings =
|
|
|
|
|
OPENSSL_malloc(sizeof(BN_BLINDING *) * (rsa->num_blindings + 1));
|
|
|
|
|
if (new_blindings == NULL) {
|
|
|
|
|
goto err1;
|
|
|
|
|
}
|
2016-12-13 06:07:13 +00:00
|
|
|
|
OPENSSL_memcpy(new_blindings, rsa->blindings,
|
2014-06-20 20:00:00 +01:00
|
|
|
|
sizeof(BN_BLINDING *) * rsa->num_blindings);
|
|
|
|
|
new_blindings[rsa->num_blindings] = ret;
|
|
|
|
|
|
|
|
|
|
new_blindings_inuse = OPENSSL_malloc(rsa->num_blindings + 1);
|
|
|
|
|
if (new_blindings_inuse == NULL) {
|
|
|
|
|
goto err2;
|
|
|
|
|
}
|
2016-12-13 06:07:13 +00:00
|
|
|
|
OPENSSL_memcpy(new_blindings_inuse, rsa->blindings_inuse, rsa->num_blindings);
|
2014-06-20 20:00:00 +01:00
|
|
|
|
new_blindings_inuse[rsa->num_blindings] = 1;
|
|
|
|
|
*index_used = rsa->num_blindings;
|
|
|
|
|
|
2015-04-22 21:09:09 +01:00
|
|
|
|
OPENSSL_free(rsa->blindings);
|
2014-06-20 20:00:00 +01:00
|
|
|
|
rsa->blindings = new_blindings;
|
2015-04-22 21:09:09 +01:00
|
|
|
|
OPENSSL_free(rsa->blindings_inuse);
|
2014-06-20 20:00:00 +01:00
|
|
|
|
rsa->blindings_inuse = new_blindings_inuse;
|
|
|
|
|
rsa->num_blindings++;
|
|
|
|
|
|
2016-05-24 16:28:36 +01:00
|
|
|
|
CRYPTO_MUTEX_unlock_write(&rsa->lock);
|
2014-06-20 20:00:00 +01:00
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
|
|
err2:
|
|
|
|
|
OPENSSL_free(new_blindings);
|
|
|
|
|
|
|
|
|
|
err1:
|
2016-05-24 16:28:36 +01:00
|
|
|
|
CRYPTO_MUTEX_unlock_write(&rsa->lock);
|
2014-06-20 20:00:00 +01:00
|
|
|
|
BN_BLINDING_free(ret);
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2017-08-18 19:06:02 +01:00
|
|
|
|
// rsa_blinding_release marks the cached BN_BLINDING at the given index as free
|
|
|
|
|
// for other threads to use.
|
2014-06-20 20:00:00 +01:00
|
|
|
|
static void rsa_blinding_release(RSA *rsa, BN_BLINDING *blinding,
|
|
|
|
|
unsigned blinding_index) {
|
|
|
|
|
if (blinding_index == MAX_BLINDINGS_PER_RSA) {
|
2017-08-18 19:06:02 +01:00
|
|
|
|
// This blinding wasn't cached.
|
2014-06-20 20:00:00 +01:00
|
|
|
|
BN_BLINDING_free(blinding);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2015-04-13 19:04:14 +01:00
|
|
|
|
CRYPTO_MUTEX_lock_write(&rsa->lock);
|
2014-06-20 20:00:00 +01:00
|
|
|
|
rsa->blindings_inuse[blinding_index] = 0;
|
2016-05-24 16:28:36 +01:00
|
|
|
|
CRYPTO_MUTEX_unlock_write(&rsa->lock);
|
2014-06-20 20:00:00 +01:00
|
|
|
|
}
|
|
|
|
|
|
2017-08-18 19:06:02 +01:00
|
|
|
|
// signing
|
2015-10-29 17:19:12 +00:00
|
|
|
|
int rsa_default_sign_raw(RSA *rsa, size_t *out_len, uint8_t *out,
|
|
|
|
|
size_t max_out, const uint8_t *in, size_t in_len,
|
|
|
|
|
int padding) {
|
2014-06-20 20:00:00 +01:00
|
|
|
|
const unsigned rsa_size = RSA_size(rsa);
|
|
|
|
|
uint8_t *buf = NULL;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
int i, ret = 0;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
|
|
|
|
if (max_out < rsa_size) {
|
2015-06-29 05:28:17 +01:00
|
|
|
|
OPENSSL_PUT_ERROR(RSA, RSA_R_OUTPUT_BUFFER_TOO_SMALL);
|
2014-06-20 20:00:00 +01:00
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
buf = OPENSSL_malloc(rsa_size);
|
2014-08-18 21:29:45 +01:00
|
|
|
|
if (buf == NULL) {
|
2015-06-29 05:28:17 +01:00
|
|
|
|
OPENSSL_PUT_ERROR(RSA, ERR_R_MALLOC_FAILURE);
|
2014-06-20 20:00:00 +01:00
|
|
|
|
goto err;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
switch (padding) {
|
|
|
|
|
case RSA_PKCS1_PADDING:
|
|
|
|
|
i = RSA_padding_add_PKCS1_type_1(buf, rsa_size, in, in_len);
|
|
|
|
|
break;
|
|
|
|
|
case RSA_NO_PADDING:
|
|
|
|
|
i = RSA_padding_add_none(buf, rsa_size, in, in_len);
|
|
|
|
|
break;
|
|
|
|
|
default:
|
2015-06-29 05:28:17 +01:00
|
|
|
|
OPENSSL_PUT_ERROR(RSA, RSA_R_UNKNOWN_PADDING_TYPE);
|
2014-06-20 20:00:00 +01:00
|
|
|
|
goto err;
|
|
|
|
|
}
|
|
|
|
|
|
2014-08-18 21:29:45 +01:00
|
|
|
|
if (i <= 0) {
|
2014-06-20 20:00:00 +01:00
|
|
|
|
goto err;
|
|
|
|
|
}
|
|
|
|
|
|
2014-08-18 21:29:45 +01:00
|
|
|
|
if (!RSA_private_transform(rsa, out, buf, rsa_size)) {
|
2015-02-24 21:49:41 +00:00
|
|
|
|
goto err;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
*out_len = rsa_size;
|
|
|
|
|
ret = 1;
|
|
|
|
|
|
|
|
|
|
err:
|
2017-08-30 18:49:05 +01:00
|
|
|
|
OPENSSL_free(buf);
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
2015-10-29 17:19:12 +00:00
|
|
|
|
int rsa_default_decrypt(RSA *rsa, size_t *out_len, uint8_t *out, size_t max_out,
|
|
|
|
|
const uint8_t *in, size_t in_len, int padding) {
|
2014-06-20 20:00:00 +01:00
|
|
|
|
const unsigned rsa_size = RSA_size(rsa);
|
|
|
|
|
uint8_t *buf = NULL;
|
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
|
|
if (max_out < rsa_size) {
|
2015-06-29 05:28:17 +01:00
|
|
|
|
OPENSSL_PUT_ERROR(RSA, RSA_R_OUTPUT_BUFFER_TOO_SMALL);
|
2014-06-20 20:00:00 +01:00
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2014-07-24 18:09:19 +01:00
|
|
|
|
if (padding == RSA_NO_PADDING) {
|
|
|
|
|
buf = out;
|
|
|
|
|
} else {
|
2017-08-18 19:06:02 +01:00
|
|
|
|
// Allocate a temporary buffer to hold the padded plaintext.
|
2014-07-24 18:09:19 +01:00
|
|
|
|
buf = OPENSSL_malloc(rsa_size);
|
|
|
|
|
if (buf == NULL) {
|
|
|
|
|
OPENSSL_PUT_ERROR(RSA, ERR_R_MALLOC_FAILURE);
|
|
|
|
|
goto err;
|
|
|
|
|
}
|
2014-06-20 20:00:00 +01:00
|
|
|
|
}
|
|
|
|
|
|
2014-08-18 21:29:45 +01:00
|
|
|
|
if (in_len != rsa_size) {
|
2015-06-29 05:28:17 +01:00
|
|
|
|
OPENSSL_PUT_ERROR(RSA, RSA_R_DATA_LEN_NOT_EQUAL_TO_MOD_LEN);
|
2014-06-20 20:00:00 +01:00
|
|
|
|
goto err;
|
|
|
|
|
}
|
|
|
|
|
|
2014-08-18 21:29:45 +01:00
|
|
|
|
if (!RSA_private_transform(rsa, buf, in, rsa_size)) {
|
2014-06-20 20:00:00 +01:00
|
|
|
|
goto err;
|
|
|
|
|
}
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
|
|
|
|
switch (padding) {
|
|
|
|
|
case RSA_PKCS1_PADDING:
|
2017-03-16 17:15:31 +00:00
|
|
|
|
ret =
|
|
|
|
|
RSA_padding_check_PKCS1_type_2(out, out_len, rsa_size, buf, rsa_size);
|
2014-06-20 20:00:00 +01:00
|
|
|
|
break;
|
|
|
|
|
case RSA_PKCS1_OAEP_PADDING:
|
2017-08-18 19:06:02 +01:00
|
|
|
|
// Use the default parameters: SHA-1 for both hashes and no label.
|
2017-03-16 17:15:31 +00:00
|
|
|
|
ret = RSA_padding_check_PKCS1_OAEP_mgf1(out, out_len, rsa_size, buf,
|
|
|
|
|
rsa_size, NULL, 0, NULL, NULL);
|
2014-06-20 20:00:00 +01:00
|
|
|
|
break;
|
|
|
|
|
case RSA_NO_PADDING:
|
2017-03-16 17:15:31 +00:00
|
|
|
|
*out_len = rsa_size;
|
|
|
|
|
ret = 1;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
break;
|
|
|
|
|
default:
|
2015-06-29 05:28:17 +01:00
|
|
|
|
OPENSSL_PUT_ERROR(RSA, RSA_R_UNKNOWN_PADDING_TYPE);
|
2014-06-20 20:00:00 +01:00
|
|
|
|
goto err;
|
|
|
|
|
}
|
|
|
|
|
|
2017-03-16 17:15:31 +00:00
|
|
|
|
if (!ret) {
|
2015-06-29 05:28:17 +01:00
|
|
|
|
OPENSSL_PUT_ERROR(RSA, RSA_R_PADDING_CHECK_FAILED);
|
2014-06-20 20:00:00 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
err:
|
2017-08-30 18:49:05 +01:00
|
|
|
|
if (padding != RSA_NO_PADDING) {
|
2014-06-20 20:00:00 +01:00
|
|
|
|
OPENSSL_free(buf);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
2016-03-25 23:24:46 +00:00
|
|
|
|
static int mod_exp(BIGNUM *r0, const BIGNUM *I, RSA *rsa, BN_CTX *ctx);
|
|
|
|
|
|
2016-03-04 18:54:07 +00:00
|
|
|
|
int RSA_verify_raw(RSA *rsa, size_t *out_len, uint8_t *out, size_t max_out,
|
|
|
|
|
const uint8_t *in, size_t in_len, int padding) {
|
|
|
|
|
if (rsa->n == NULL || rsa->e == NULL) {
|
|
|
|
|
OPENSSL_PUT_ERROR(RSA, RSA_R_VALUE_MISSING);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2014-06-20 20:00:00 +01:00
|
|
|
|
const unsigned rsa_size = RSA_size(rsa);
|
|
|
|
|
BIGNUM *f, *result;
|
|
|
|
|
|
|
|
|
|
if (max_out < rsa_size) {
|
2015-06-29 05:28:17 +01:00
|
|
|
|
OPENSSL_PUT_ERROR(RSA, RSA_R_OUTPUT_BUFFER_TOO_SMALL);
|
2014-06-20 20:00:00 +01:00
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2016-03-04 19:20:07 +00:00
|
|
|
|
if (in_len != rsa_size) {
|
|
|
|
|
OPENSSL_PUT_ERROR(RSA, RSA_R_DATA_LEN_NOT_EQUAL_TO_MOD_LEN);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2016-01-12 20:47:25 +00:00
|
|
|
|
if (!check_modulus_and_exponent_sizes(rsa)) {
|
2014-06-20 20:00:00 +01:00
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2016-03-04 23:42:47 +00:00
|
|
|
|
BN_CTX *ctx = BN_CTX_new();
|
2014-06-20 20:00:00 +01:00
|
|
|
|
if (ctx == NULL) {
|
2016-03-04 23:42:47 +00:00
|
|
|
|
return 0;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
}
|
|
|
|
|
|
2016-03-04 23:42:47 +00:00
|
|
|
|
int ret = 0;
|
|
|
|
|
uint8_t *buf = NULL;
|
|
|
|
|
|
2014-06-20 20:00:00 +01:00
|
|
|
|
BN_CTX_start(ctx);
|
|
|
|
|
f = BN_CTX_get(ctx);
|
|
|
|
|
result = BN_CTX_get(ctx);
|
2016-03-04 23:42:47 +00:00
|
|
|
|
if (f == NULL || result == NULL) {
|
|
|
|
|
OPENSSL_PUT_ERROR(RSA, ERR_R_MALLOC_FAILURE);
|
|
|
|
|
goto err;
|
|
|
|
|
}
|
|
|
|
|
|
2014-07-24 18:09:19 +01:00
|
|
|
|
if (padding == RSA_NO_PADDING) {
|
|
|
|
|
buf = out;
|
|
|
|
|
} else {
|
2017-08-18 19:06:02 +01:00
|
|
|
|
// Allocate a temporary buffer to hold the padded plaintext.
|
2014-07-24 18:09:19 +01:00
|
|
|
|
buf = OPENSSL_malloc(rsa_size);
|
|
|
|
|
if (buf == NULL) {
|
|
|
|
|
OPENSSL_PUT_ERROR(RSA, ERR_R_MALLOC_FAILURE);
|
|
|
|
|
goto err;
|
|
|
|
|
}
|
|
|
|
|
}
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
|
|
|
|
if (BN_bin2bn(in, in_len, f) == NULL) {
|
|
|
|
|
goto err;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (BN_ucmp(f, rsa->n) >= 0) {
|
Tweak RSA errors for compatibility.
cryptography.io wants RSA_R_BLOCK_TYPE_IS_NOT_02, only used by the
ancient RSA_padding_check_SSLv23 function. Define it but never emit it.
Additionally, it's rather finicky about RSA_R_TOO_LARGE* errors. We
merged them in BoringSSL because having RSA_R_TOO_LARGE,
RSA_R_TOO_LARGE_FOR_MODULUS, and RSA_R_TOO_LARGE_FOR_KEY_SIZE is a
little silly. But since we don't expect well-behaved code to condition
on error codes anyway, perhaps that wasn't worth it. Split them back
up.
Looking through OpenSSL, there is a vague semantic difference:
RSA_R_DIGEST_TOO_BIG_FOR_RSA_KEY - Specifically emitted if a digest is
too big for PKCS#1 signing with this key.
RSA_R_DATA_TOO_LARGE_FOR_KEY_SIZE - You asked me to sign or encrypt a
digest/plaintext, but it's too big for this key.
RSA_R_DATA_TOO_LARGE_FOR_MODULUS - You gave me an RSA ciphertext or
signature and it is not fully reduced modulo N.
-OR-
The padding functions produced something that isn't reduced, but I
believe this is unreachable outside of RSA_NO_PADDING.
RSA_R_DATA_TOO_LARGE - Some low-level padding function was told to copy
a digest/plaintext into some buffer, but the buffer was too small. I
think this is basically unreachable.
-OR-
You asked me to verify a PSS signature, but I didn't need to bother
because the digest/salt parameters you picked were too big.
Update-Note: This depends on cl/196566462.
Change-Id: I2e539e075eff8bfcd52ccde365e975ebcee72567
Reviewed-on: https://boringssl-review.googlesource.com/28547
Reviewed-by: Adam Langley <agl@google.com>
2018-05-14 23:10:14 +01:00
|
|
|
|
OPENSSL_PUT_ERROR(RSA, RSA_R_DATA_TOO_LARGE_FOR_MODULUS);
|
2014-06-20 20:00:00 +01:00
|
|
|
|
goto err;
|
|
|
|
|
}
|
|
|
|
|
|
2016-03-25 20:11:04 +00:00
|
|
|
|
if (!BN_MONT_CTX_set_locked(&rsa->mont_n, &rsa->lock, rsa->n, ctx) ||
|
Fix threading issues with RSA freeze_private_key.
OpenSSL's RSA API is poorly designed and does not have a single place to
properly initialize the key. See
https://github.com/openssl/openssl/issues/5158.
To workaround this flaw, we must lazily instantiate pre-computed
Montgomery bits with locking. This is a ton of complexity. More
importantly, it makes it very difficult to implement RSA without side
channels. The correct in-memory representation of d, dmp1, and dmq1
depend on n, p, and q, respectively. (Those values have private
magnitudes and must be sized relative to the respective moduli.)
08805fe27910e09d05e87d61bc5411a4e3b2d999 attempted to fix up the various
widths under lock, when we set up BN_MONT_CTX. However, this introduces
threading issues because other threads may access those exposed
components (RSA_get0_* also count as exposed for these purposes because
they are get0 functions), while a private key operation is in progress.
Instead, we do the following:
- There is no actual need to minimize n, p, and q, but we have minimized
copies in the BN_MONT_CTXs, so use those.
- Store additional copies of d, dmp1, and dmq1, at the cost of more
memory used. These copies have the correct width and are private,
unlike d, dmp1, and dmq1 which are sadly exposed. Fix private key
operations to use them.
- Move the frozen bit out of rsa->flags, as that too was historically
accessible without locking.
(Serialization still uses the original BIGNUMs, but the RSAPrivateKey
serialization format already inherently leaks the magnitude, so this
doesn't matter.)
Change-Id: Ia3a9b0629f8efef23abb30bfed110d247d1db42f
Reviewed-on: https://boringssl-review.googlesource.com/25824
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
2018-02-09 20:52:58 +00:00
|
|
|
|
!BN_mod_exp_mont(result, f, rsa->e, &rsa->mont_n->N, ctx, rsa->mont_n)) {
|
2014-06-20 20:00:00 +01:00
|
|
|
|
goto err;
|
|
|
|
|
}
|
|
|
|
|
|
2014-06-20 20:00:00 +01:00
|
|
|
|
if (!BN_bn2bin_padded(buf, rsa_size, result)) {
|
2015-06-29 05:28:17 +01:00
|
|
|
|
OPENSSL_PUT_ERROR(RSA, ERR_R_INTERNAL_ERROR);
|
2014-06-20 20:00:00 +01:00
|
|
|
|
goto err;
|
|
|
|
|
}
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
|
|
|
|
switch (padding) {
|
|
|
|
|
case RSA_PKCS1_PADDING:
|
2017-03-16 15:54:11 +00:00
|
|
|
|
ret =
|
|
|
|
|
RSA_padding_check_PKCS1_type_1(out, out_len, rsa_size, buf, rsa_size);
|
2014-06-20 20:00:00 +01:00
|
|
|
|
break;
|
|
|
|
|
case RSA_NO_PADDING:
|
2017-03-16 15:54:11 +00:00
|
|
|
|
ret = 1;
|
|
|
|
|
*out_len = rsa_size;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
break;
|
|
|
|
|
default:
|
2015-06-29 05:28:17 +01:00
|
|
|
|
OPENSSL_PUT_ERROR(RSA, RSA_R_UNKNOWN_PADDING_TYPE);
|
2014-06-20 20:00:00 +01:00
|
|
|
|
goto err;
|
|
|
|
|
}
|
|
|
|
|
|
2017-03-16 15:54:11 +00:00
|
|
|
|
if (!ret) {
|
2015-06-29 05:28:17 +01:00
|
|
|
|
OPENSSL_PUT_ERROR(RSA, RSA_R_PADDING_CHECK_FAILED);
|
2017-03-16 15:54:11 +00:00
|
|
|
|
goto err;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
err:
|
2016-03-04 23:42:47 +00:00
|
|
|
|
BN_CTX_end(ctx);
|
|
|
|
|
BN_CTX_free(ctx);
|
|
|
|
|
if (buf != out) {
|
2014-06-20 20:00:00 +01:00
|
|
|
|
OPENSSL_free(buf);
|
|
|
|
|
}
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
2015-10-29 17:19:12 +00:00
|
|
|
|
int rsa_default_private_transform(RSA *rsa, uint8_t *out, const uint8_t *in,
|
|
|
|
|
size_t len) {
|
2017-06-22 15:53:25 +01:00
|
|
|
|
if (rsa->n == NULL || rsa->d == NULL) {
|
|
|
|
|
OPENSSL_PUT_ERROR(RSA, RSA_R_VALUE_MISSING);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2014-08-18 21:29:45 +01:00
|
|
|
|
BIGNUM *f, *result;
|
|
|
|
|
BN_CTX *ctx = NULL;
|
|
|
|
|
unsigned blinding_index = 0;
|
|
|
|
|
BN_BLINDING *blinding = NULL;
|
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
|
|
ctx = BN_CTX_new();
|
|
|
|
|
if (ctx == NULL) {
|
|
|
|
|
goto err;
|
|
|
|
|
}
|
|
|
|
|
BN_CTX_start(ctx);
|
|
|
|
|
f = BN_CTX_get(ctx);
|
|
|
|
|
result = BN_CTX_get(ctx);
|
|
|
|
|
|
|
|
|
|
if (f == NULL || result == NULL) {
|
2015-06-29 05:28:17 +01:00
|
|
|
|
OPENSSL_PUT_ERROR(RSA, ERR_R_MALLOC_FAILURE);
|
2014-08-18 21:29:45 +01:00
|
|
|
|
goto err;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (BN_bin2bn(in, len, f) == NULL) {
|
|
|
|
|
goto err;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (BN_ucmp(f, rsa->n) >= 0) {
|
2017-08-18 19:06:02 +01:00
|
|
|
|
// Usually the padding functions would catch this.
|
Tweak RSA errors for compatibility.
cryptography.io wants RSA_R_BLOCK_TYPE_IS_NOT_02, only used by the
ancient RSA_padding_check_SSLv23 function. Define it but never emit it.
Additionally, it's rather finicky about RSA_R_TOO_LARGE* errors. We
merged them in BoringSSL because having RSA_R_TOO_LARGE,
RSA_R_TOO_LARGE_FOR_MODULUS, and RSA_R_TOO_LARGE_FOR_KEY_SIZE is a
little silly. But since we don't expect well-behaved code to condition
on error codes anyway, perhaps that wasn't worth it. Split them back
up.
Looking through OpenSSL, there is a vague semantic difference:
RSA_R_DIGEST_TOO_BIG_FOR_RSA_KEY - Specifically emitted if a digest is
too big for PKCS#1 signing with this key.
RSA_R_DATA_TOO_LARGE_FOR_KEY_SIZE - You asked me to sign or encrypt a
digest/plaintext, but it's too big for this key.
RSA_R_DATA_TOO_LARGE_FOR_MODULUS - You gave me an RSA ciphertext or
signature and it is not fully reduced modulo N.
-OR-
The padding functions produced something that isn't reduced, but I
believe this is unreachable outside of RSA_NO_PADDING.
RSA_R_DATA_TOO_LARGE - Some low-level padding function was told to copy
a digest/plaintext into some buffer, but the buffer was too small. I
think this is basically unreachable.
-OR-
You asked me to verify a PSS signature, but I didn't need to bother
because the digest/salt parameters you picked were too big.
Update-Note: This depends on cl/196566462.
Change-Id: I2e539e075eff8bfcd52ccde365e975ebcee72567
Reviewed-on: https://boringssl-review.googlesource.com/28547
Reviewed-by: Adam Langley <agl@google.com>
2018-05-14 23:10:14 +01:00
|
|
|
|
OPENSSL_PUT_ERROR(RSA, RSA_R_DATA_TOO_LARGE_FOR_MODULUS);
|
2014-08-18 21:29:45 +01:00
|
|
|
|
goto err;
|
|
|
|
|
}
|
|
|
|
|
|
2018-01-23 21:48:53 +00:00
|
|
|
|
if (!freeze_private_key(rsa, ctx)) {
|
Verify RSA private key operation regardless of whether CRT is used.
Previously, the verification was only done when using the CRT method,
as the CRT method has been shown to be extremely sensitive to fault
attacks. However, there's no reason to avoid doing the verification
when the non-CRT method is used (performance-sensitive applications
should always be using the CRT-capable keys).
Previously, when we detected a fault (attack) through this verification,
libcrypto would fall back to the non-CRT method and assume that the
non-CRT method would give a correct result, despite having just
detecting corruption that is likely from an attack. Instead, just give
up, like NSS does.
Previously, the code tried to handle the case where the input was not
reduced mod rsa->n. This is (was) not possible, so avoid trying to
handle that. This simplifies the equality check and lets us use
|CRYPTO_memcmp|.
Change-Id: I78d1e55520a1c8c280cae2b7256e12ff6290507d
Reviewed-on: https://boringssl-review.googlesource.com/7582
Reviewed-by: David Benjamin <davidben@google.com>
2016-03-25 22:23:16 +00:00
|
|
|
|
OPENSSL_PUT_ERROR(RSA, ERR_R_INTERNAL_ERROR);
|
|
|
|
|
goto err;
|
|
|
|
|
}
|
|
|
|
|
|
2017-06-13 21:00:25 +01:00
|
|
|
|
const int do_blinding = (rsa->flags & RSA_FLAG_NO_BLINDING) == 0;
|
|
|
|
|
|
|
|
|
|
if (rsa->e == NULL && do_blinding) {
|
2017-08-18 19:06:02 +01:00
|
|
|
|
// We cannot do blinding or verification without |e|, and continuing without
|
|
|
|
|
// those countermeasures is dangerous. However, the Java/Android RSA API
|
|
|
|
|
// requires support for keys where only |d| and |n| (and not |e|) are known.
|
|
|
|
|
// The callers that require that bad behavior set |RSA_FLAG_NO_BLINDING|.
|
2017-06-13 21:00:25 +01:00
|
|
|
|
OPENSSL_PUT_ERROR(RSA, RSA_R_NO_PUBLIC_EXPONENT);
|
|
|
|
|
goto err;
|
|
|
|
|
}
|
Require the public exponent to be available in RSA blinding.
Require the public exponent to be available unless
|RSA_FLAG_NO_BLINDING| is set on the key. Also, document this.
If the public exponent |e| is not available, then we could compute it
from |p|, |q|, and |d|. However, there's no reasonable situation in
which we'd have |p| or |q| but not |e|; either we have all the CRT
parameters, or we have (e, d, n), or we have only (d, n). The
calculation to compute |e| exposes the private key to risk of side
channel attacks.
Also, it was particularly wasteful to compute |e| for each
|BN_BLINDING| created, instead of just once before the first
|BN_BLINDING| was created.
|BN_BLINDING| now no longer needs to contain a duplicate copy of |e|,
so it is now more space-efficient.
Note that the condition |b->e != NULL| in |bn_blinding_update| was
always true since commit cbf56a5683ddda831ff91c46ea48d1fba545db66.
Change-Id: Ic2fd6980e0d359dcd53772a7c31bdd0267e316b4
Reviewed-on: https://boringssl-review.googlesource.com/7594
Reviewed-by: David Benjamin <davidben@google.com>
2016-03-27 06:42:31 +01:00
|
|
|
|
|
2017-06-13 21:00:25 +01:00
|
|
|
|
if (do_blinding) {
|
2014-08-18 21:29:45 +01:00
|
|
|
|
blinding = rsa_blinding_get(rsa, &blinding_index, ctx);
|
|
|
|
|
if (blinding == NULL) {
|
2015-06-29 05:28:17 +01:00
|
|
|
|
OPENSSL_PUT_ERROR(RSA, ERR_R_INTERNAL_ERROR);
|
2014-08-18 21:29:45 +01:00
|
|
|
|
goto err;
|
|
|
|
|
}
|
Require the public exponent to be available in RSA blinding.
Require the public exponent to be available unless
|RSA_FLAG_NO_BLINDING| is set on the key. Also, document this.
If the public exponent |e| is not available, then we could compute it
from |p|, |q|, and |d|. However, there's no reasonable situation in
which we'd have |p| or |q| but not |e|; either we have all the CRT
parameters, or we have (e, d, n), or we have only (d, n). The
calculation to compute |e| exposes the private key to risk of side
channel attacks.
Also, it was particularly wasteful to compute |e| for each
|BN_BLINDING| created, instead of just once before the first
|BN_BLINDING| was created.
|BN_BLINDING| now no longer needs to contain a duplicate copy of |e|,
so it is now more space-efficient.
Note that the condition |b->e != NULL| in |bn_blinding_update| was
always true since commit cbf56a5683ddda831ff91c46ea48d1fba545db66.
Change-Id: Ic2fd6980e0d359dcd53772a7c31bdd0267e316b4
Reviewed-on: https://boringssl-review.googlesource.com/7594
Reviewed-by: David Benjamin <davidben@google.com>
2016-03-27 06:42:31 +01:00
|
|
|
|
if (!BN_BLINDING_convert(f, blinding, rsa->e, rsa->mont_n, ctx)) {
|
2014-08-18 21:29:45 +01:00
|
|
|
|
goto err;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-03-25 23:15:39 +00:00
|
|
|
|
if (rsa->p != NULL && rsa->q != NULL && rsa->e != NULL && rsa->dmp1 != NULL &&
|
2018-01-26 22:22:27 +00:00
|
|
|
|
rsa->dmq1 != NULL && rsa->iqmp != NULL &&
|
|
|
|
|
// Require that we can reduce |f| by |rsa->p| and |rsa->q| in constant
|
|
|
|
|
// time, which requires primes be the same size, rounded to the Montgomery
|
|
|
|
|
// coefficient. (See |mod_montgomery|.) This is not required by RFC 8017,
|
|
|
|
|
// but it is true for keys generated by us and all common implementations.
|
|
|
|
|
bn_less_than_montgomery_R(rsa->q, rsa->mont_p) &&
|
|
|
|
|
bn_less_than_montgomery_R(rsa->p, rsa->mont_q)) {
|
2016-03-25 23:24:46 +00:00
|
|
|
|
if (!mod_exp(result, f, rsa, ctx)) {
|
2014-08-18 21:29:45 +01:00
|
|
|
|
goto err;
|
|
|
|
|
}
|
Fix threading issues with RSA freeze_private_key.
OpenSSL's RSA API is poorly designed and does not have a single place to
properly initialize the key. See
https://github.com/openssl/openssl/issues/5158.
To workaround this flaw, we must lazily instantiate pre-computed
Montgomery bits with locking. This is a ton of complexity. More
importantly, it makes it very difficult to implement RSA without side
channels. The correct in-memory representation of d, dmp1, and dmq1
depend on n, p, and q, respectively. (Those values have private
magnitudes and must be sized relative to the respective moduli.)
08805fe27910e09d05e87d61bc5411a4e3b2d999 attempted to fix up the various
widths under lock, when we set up BN_MONT_CTX. However, this introduces
threading issues because other threads may access those exposed
components (RSA_get0_* also count as exposed for these purposes because
they are get0 functions), while a private key operation is in progress.
Instead, we do the following:
- There is no actual need to minimize n, p, and q, but we have minimized
copies in the BN_MONT_CTXs, so use those.
- Store additional copies of d, dmp1, and dmq1, at the cost of more
memory used. These copies have the correct width and are private,
unlike d, dmp1, and dmq1 which are sadly exposed. Fix private key
operations to use them.
- Move the frozen bit out of rsa->flags, as that too was historically
accessible without locking.
(Serialization still uses the original BIGNUMs, but the RSAPrivateKey
serialization format already inherently leaks the magnitude, so this
doesn't matter.)
Change-Id: Ia3a9b0629f8efef23abb30bfed110d247d1db42f
Reviewed-on: https://boringssl-review.googlesource.com/25824
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
2018-02-09 20:52:58 +00:00
|
|
|
|
} else if (!BN_mod_exp_mont_consttime(result, f, rsa->d_fixed, rsa->n, ctx,
|
2016-08-03 05:21:18 +01:00
|
|
|
|
rsa->mont_n)) {
|
|
|
|
|
goto err;
|
Verify RSA private key operation regardless of whether CRT is used.
Previously, the verification was only done when using the CRT method,
as the CRT method has been shown to be extremely sensitive to fault
attacks. However, there's no reason to avoid doing the verification
when the non-CRT method is used (performance-sensitive applications
should always be using the CRT-capable keys).
Previously, when we detected a fault (attack) through this verification,
libcrypto would fall back to the non-CRT method and assume that the
non-CRT method would give a correct result, despite having just
detecting corruption that is likely from an attack. Instead, just give
up, like NSS does.
Previously, the code tried to handle the case where the input was not
reduced mod rsa->n. This is (was) not possible, so avoid trying to
handle that. This simplifies the equality check and lets us use
|CRYPTO_memcmp|.
Change-Id: I78d1e55520a1c8c280cae2b7256e12ff6290507d
Reviewed-on: https://boringssl-review.googlesource.com/7582
Reviewed-by: David Benjamin <davidben@google.com>
2016-03-25 22:23:16 +00:00
|
|
|
|
}
|
|
|
|
|
|
2017-08-18 19:06:02 +01:00
|
|
|
|
// Verify the result to protect against fault attacks as described in the
|
|
|
|
|
// 1997 paper "On the Importance of Checking Cryptographic Protocols for
|
|
|
|
|
// Faults" by Dan Boneh, Richard A. DeMillo, and Richard J. Lipton. Some
|
|
|
|
|
// implementations do this only when the CRT is used, but we do it in all
|
|
|
|
|
// cases. Section 6 of the aforementioned paper describes an attack that
|
|
|
|
|
// works when the CRT isn't used. That attack is much less likely to succeed
|
|
|
|
|
// than the CRT attack, but there have likely been improvements since 1997.
|
|
|
|
|
//
|
|
|
|
|
// This check is cheap assuming |e| is small; it almost always is.
|
2017-06-13 21:00:25 +01:00
|
|
|
|
if (rsa->e != NULL) {
|
Verify RSA private key operation regardless of whether CRT is used.
Previously, the verification was only done when using the CRT method,
as the CRT method has been shown to be extremely sensitive to fault
attacks. However, there's no reason to avoid doing the verification
when the non-CRT method is used (performance-sensitive applications
should always be using the CRT-capable keys).
Previously, when we detected a fault (attack) through this verification,
libcrypto would fall back to the non-CRT method and assume that the
non-CRT method would give a correct result, despite having just
detecting corruption that is likely from an attack. Instead, just give
up, like NSS does.
Previously, the code tried to handle the case where the input was not
reduced mod rsa->n. This is (was) not possible, so avoid trying to
handle that. This simplifies the equality check and lets us use
|CRYPTO_memcmp|.
Change-Id: I78d1e55520a1c8c280cae2b7256e12ff6290507d
Reviewed-on: https://boringssl-review.googlesource.com/7582
Reviewed-by: David Benjamin <davidben@google.com>
2016-03-25 22:23:16 +00:00
|
|
|
|
BIGNUM *vrfy = BN_CTX_get(ctx);
|
|
|
|
|
if (vrfy == NULL ||
|
|
|
|
|
!BN_mod_exp_mont(vrfy, result, rsa->e, rsa->n, ctx, rsa->mont_n) ||
|
|
|
|
|
!BN_equal_consttime(vrfy, f)) {
|
|
|
|
|
OPENSSL_PUT_ERROR(RSA, ERR_R_INTERNAL_ERROR);
|
2014-08-18 21:29:45 +01:00
|
|
|
|
goto err;
|
|
|
|
|
}
|
|
|
|
|
|
2017-06-13 21:00:25 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (do_blinding &&
|
|
|
|
|
!BN_BLINDING_invert(result, blinding, rsa->mont_n, ctx)) {
|
|
|
|
|
goto err;
|
2014-08-18 21:29:45 +01:00
|
|
|
|
}
|
|
|
|
|
|
2018-01-26 03:29:02 +00:00
|
|
|
|
// The computation should have left |result| as a maximally-wide number, so
|
|
|
|
|
// that it and serializing does not leak information about the magnitude of
|
|
|
|
|
// the result.
|
|
|
|
|
//
|
2018-05-21 19:09:05 +01:00
|
|
|
|
// See Falko Strenzke, "Manger's Attack revisited", ICICS 2010.
|
Fix threading issues with RSA freeze_private_key.
OpenSSL's RSA API is poorly designed and does not have a single place to
properly initialize the key. See
https://github.com/openssl/openssl/issues/5158.
To workaround this flaw, we must lazily instantiate pre-computed
Montgomery bits with locking. This is a ton of complexity. More
importantly, it makes it very difficult to implement RSA without side
channels. The correct in-memory representation of d, dmp1, and dmq1
depend on n, p, and q, respectively. (Those values have private
magnitudes and must be sized relative to the respective moduli.)
08805fe27910e09d05e87d61bc5411a4e3b2d999 attempted to fix up the various
widths under lock, when we set up BN_MONT_CTX. However, this introduces
threading issues because other threads may access those exposed
components (RSA_get0_* also count as exposed for these purposes because
they are get0 functions), while a private key operation is in progress.
Instead, we do the following:
- There is no actual need to minimize n, p, and q, but we have minimized
copies in the BN_MONT_CTXs, so use those.
- Store additional copies of d, dmp1, and dmq1, at the cost of more
memory used. These copies have the correct width and are private,
unlike d, dmp1, and dmq1 which are sadly exposed. Fix private key
operations to use them.
- Move the frozen bit out of rsa->flags, as that too was historically
accessible without locking.
(Serialization still uses the original BIGNUMs, but the RSAPrivateKey
serialization format already inherently leaks the magnitude, so this
doesn't matter.)
Change-Id: Ia3a9b0629f8efef23abb30bfed110d247d1db42f
Reviewed-on: https://boringssl-review.googlesource.com/25824
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
2018-02-09 20:52:58 +00:00
|
|
|
|
assert(result->width == rsa->mont_n->N.width);
|
2014-08-18 21:29:45 +01:00
|
|
|
|
if (!BN_bn2bin_padded(out, len, result)) {
|
2015-06-29 05:28:17 +01:00
|
|
|
|
OPENSSL_PUT_ERROR(RSA, ERR_R_INTERNAL_ERROR);
|
2014-08-18 21:29:45 +01:00
|
|
|
|
goto err;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ret = 1;
|
|
|
|
|
|
|
|
|
|
err:
|
|
|
|
|
if (ctx != NULL) {
|
|
|
|
|
BN_CTX_end(ctx);
|
|
|
|
|
BN_CTX_free(ctx);
|
|
|
|
|
}
|
|
|
|
|
if (blinding != NULL) {
|
|
|
|
|
rsa_blinding_release(rsa, blinding, blinding_index);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
2017-12-14 17:54:12 +00:00
|
|
|
|
// mod_montgomery sets |r| to |I| mod |p|. |I| must already be fully reduced
|
|
|
|
|
// modulo |p| times |q|. It returns one on success and zero on error.
|
|
|
|
|
static int mod_montgomery(BIGNUM *r, const BIGNUM *I, const BIGNUM *p,
|
|
|
|
|
const BN_MONT_CTX *mont_p, const BIGNUM *q,
|
|
|
|
|
BN_CTX *ctx) {
|
2018-01-23 21:17:55 +00:00
|
|
|
|
// Reducing in constant-time with Montgomery reduction requires I <= p * R. We
|
2018-01-26 22:22:27 +00:00
|
|
|
|
// have I < p * q, so this follows if q < R. The caller should have checked
|
|
|
|
|
// this already.
|
2018-01-23 21:17:55 +00:00
|
|
|
|
if (!bn_less_than_montgomery_R(q, mont_p)) {
|
2018-01-26 22:22:27 +00:00
|
|
|
|
OPENSSL_PUT_ERROR(RSA, ERR_R_INTERNAL_ERROR);
|
|
|
|
|
return 0;
|
2017-12-14 17:54:12 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (// Reduce mod p with Montgomery reduction. This computes I * R^-1 mod p.
|
|
|
|
|
!BN_from_montgomery(r, I, mont_p, ctx) ||
|
|
|
|
|
// Multiply by R^2 and do another Montgomery reduction to compute
|
|
|
|
|
// I * R^-1 * R^2 * R^-1 = I mod p.
|
|
|
|
|
!BN_to_montgomery(r, r, mont_p, ctx)) {
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// By precomputing R^3 mod p (normally |BN_MONT_CTX| only uses R^2 mod p) and
|
|
|
|
|
// adjusting the API for |BN_mod_exp_mont_consttime|, we could instead compute
|
|
|
|
|
// I * R mod p here and save a reduction per prime. But this would require
|
2018-02-13 20:43:46 +00:00
|
|
|
|
// changing the RSAZ code and may not be worth it. Note that the RSAZ code
|
|
|
|
|
// uses a different radix, so it uses R' = 2^1044. There we'd actually want
|
|
|
|
|
// R^2 * R', and would futher benefit from a precomputed R'^2. It currently
|
|
|
|
|
// converts |mont_p->RR| to R'^2.
|
2017-12-14 17:54:12 +00:00
|
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
|
2014-06-20 20:00:00 +01:00
|
|
|
|
static int mod_exp(BIGNUM *r0, const BIGNUM *I, RSA *rsa, BN_CTX *ctx) {
|
2016-03-25 23:24:46 +00:00
|
|
|
|
assert(ctx != NULL);
|
|
|
|
|
|
2016-03-25 23:15:39 +00:00
|
|
|
|
assert(rsa->n != NULL);
|
|
|
|
|
assert(rsa->e != NULL);
|
|
|
|
|
assert(rsa->d != NULL);
|
|
|
|
|
assert(rsa->p != NULL);
|
|
|
|
|
assert(rsa->q != NULL);
|
|
|
|
|
assert(rsa->dmp1 != NULL);
|
|
|
|
|
assert(rsa->dmq1 != NULL);
|
|
|
|
|
assert(rsa->iqmp != NULL);
|
|
|
|
|
|
Make the rest of RSA CRT constant-time.
Alas, the existence of RSA keys with q > p is obnoxious, but we can
canonicalize it away. To my knowledge, the remaining leaks in RSA are:
- Key generation. This is kind of hopelessly non-constant-time but
perhaps deserves a more careful ponder. Though hopefully it does not
come in at a measurable point for practical purposes.
- Private key serialization. RSAPrivateKey inherently leaks the
magnitudes of d, dmp1, dmq1, and iqmp. This is unavoidable but
hopefully does not come in at a measurable point for practical
purposes.
- If p and q have different word widths, we currently fall back to the
variable-time BN_mod rather than Montgomery reduction at the start of
CRT. I can think of ways to apply Montgomery reduction, but it's
probably better to deny CRT to such keys, if not reject them outright.
- bn_mul_fixed and bn_sqr_fixed which affect the Montgomery
multiplication bn_mul_mont-less configurations, as well as the final
CRT multiplication. We should fix this.
Bug: 233
Change-Id: I8c2ecf8f8ec104e9f26299b66ac8cbb0cad04616
Reviewed-on: https://boringssl-review.googlesource.com/25263
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
2018-01-24 22:22:17 +00:00
|
|
|
|
BIGNUM *r1, *m1;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
|
|
BN_CTX_start(ctx);
|
|
|
|
|
r1 = BN_CTX_get(ctx);
|
|
|
|
|
m1 = BN_CTX_get(ctx);
|
2016-03-20 08:39:37 +00:00
|
|
|
|
if (r1 == NULL ||
|
Make the rest of RSA CRT constant-time.
Alas, the existence of RSA keys with q > p is obnoxious, but we can
canonicalize it away. To my knowledge, the remaining leaks in RSA are:
- Key generation. This is kind of hopelessly non-constant-time but
perhaps deserves a more careful ponder. Though hopefully it does not
come in at a measurable point for practical purposes.
- Private key serialization. RSAPrivateKey inherently leaks the
magnitudes of d, dmp1, dmq1, and iqmp. This is unavoidable but
hopefully does not come in at a measurable point for practical
purposes.
- If p and q have different word widths, we currently fall back to the
variable-time BN_mod rather than Montgomery reduction at the start of
CRT. I can think of ways to apply Montgomery reduction, but it's
probably better to deny CRT to such keys, if not reject them outright.
- bn_mul_fixed and bn_sqr_fixed which affect the Montgomery
multiplication bn_mul_mont-less configurations, as well as the final
CRT multiplication. We should fix this.
Bug: 233
Change-Id: I8c2ecf8f8ec104e9f26299b66ac8cbb0cad04616
Reviewed-on: https://boringssl-review.googlesource.com/25263
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
2018-01-24 22:22:17 +00:00
|
|
|
|
m1 == NULL) {
|
2016-03-20 08:39:37 +00:00
|
|
|
|
goto err;
|
|
|
|
|
}
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
2018-01-23 21:48:53 +00:00
|
|
|
|
if (!freeze_private_key(rsa, ctx)) {
|
2016-03-25 19:12:48 +00:00
|
|
|
|
goto err;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
}
|
|
|
|
|
|
Make the rest of RSA CRT constant-time.
Alas, the existence of RSA keys with q > p is obnoxious, but we can
canonicalize it away. To my knowledge, the remaining leaks in RSA are:
- Key generation. This is kind of hopelessly non-constant-time but
perhaps deserves a more careful ponder. Though hopefully it does not
come in at a measurable point for practical purposes.
- Private key serialization. RSAPrivateKey inherently leaks the
magnitudes of d, dmp1, dmq1, and iqmp. This is unavoidable but
hopefully does not come in at a measurable point for practical
purposes.
- If p and q have different word widths, we currently fall back to the
variable-time BN_mod rather than Montgomery reduction at the start of
CRT. I can think of ways to apply Montgomery reduction, but it's
probably better to deny CRT to such keys, if not reject them outright.
- bn_mul_fixed and bn_sqr_fixed which affect the Montgomery
multiplication bn_mul_mont-less configurations, as well as the final
CRT multiplication. We should fix this.
Bug: 233
Change-Id: I8c2ecf8f8ec104e9f26299b66ac8cbb0cad04616
Reviewed-on: https://boringssl-review.googlesource.com/25263
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
2018-01-24 22:22:17 +00:00
|
|
|
|
// Implementing RSA with CRT in constant-time is sensitive to which prime is
|
|
|
|
|
// larger. Canonicalize fields so that |p| is the larger prime.
|
Fix threading issues with RSA freeze_private_key.
OpenSSL's RSA API is poorly designed and does not have a single place to
properly initialize the key. See
https://github.com/openssl/openssl/issues/5158.
To workaround this flaw, we must lazily instantiate pre-computed
Montgomery bits with locking. This is a ton of complexity. More
importantly, it makes it very difficult to implement RSA without side
channels. The correct in-memory representation of d, dmp1, and dmq1
depend on n, p, and q, respectively. (Those values have private
magnitudes and must be sized relative to the respective moduli.)
08805fe27910e09d05e87d61bc5411a4e3b2d999 attempted to fix up the various
widths under lock, when we set up BN_MONT_CTX. However, this introduces
threading issues because other threads may access those exposed
components (RSA_get0_* also count as exposed for these purposes because
they are get0 functions), while a private key operation is in progress.
Instead, we do the following:
- There is no actual need to minimize n, p, and q, but we have minimized
copies in the BN_MONT_CTXs, so use those.
- Store additional copies of d, dmp1, and dmq1, at the cost of more
memory used. These copies have the correct width and are private,
unlike d, dmp1, and dmq1 which are sadly exposed. Fix private key
operations to use them.
- Move the frozen bit out of rsa->flags, as that too was historically
accessible without locking.
(Serialization still uses the original BIGNUMs, but the RSAPrivateKey
serialization format already inherently leaks the magnitude, so this
doesn't matter.)
Change-Id: Ia3a9b0629f8efef23abb30bfed110d247d1db42f
Reviewed-on: https://boringssl-review.googlesource.com/25824
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
2018-02-09 20:52:58 +00:00
|
|
|
|
const BIGNUM *dmp1 = rsa->dmp1_fixed, *dmq1 = rsa->dmq1_fixed;
|
Make the rest of RSA CRT constant-time.
Alas, the existence of RSA keys with q > p is obnoxious, but we can
canonicalize it away. To my knowledge, the remaining leaks in RSA are:
- Key generation. This is kind of hopelessly non-constant-time but
perhaps deserves a more careful ponder. Though hopefully it does not
come in at a measurable point for practical purposes.
- Private key serialization. RSAPrivateKey inherently leaks the
magnitudes of d, dmp1, dmq1, and iqmp. This is unavoidable but
hopefully does not come in at a measurable point for practical
purposes.
- If p and q have different word widths, we currently fall back to the
variable-time BN_mod rather than Montgomery reduction at the start of
CRT. I can think of ways to apply Montgomery reduction, but it's
probably better to deny CRT to such keys, if not reject them outright.
- bn_mul_fixed and bn_sqr_fixed which affect the Montgomery
multiplication bn_mul_mont-less configurations, as well as the final
CRT multiplication. We should fix this.
Bug: 233
Change-Id: I8c2ecf8f8ec104e9f26299b66ac8cbb0cad04616
Reviewed-on: https://boringssl-review.googlesource.com/25263
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
2018-01-24 22:22:17 +00:00
|
|
|
|
const BN_MONT_CTX *mont_p = rsa->mont_p, *mont_q = rsa->mont_q;
|
2018-01-27 23:54:28 +00:00
|
|
|
|
if (BN_cmp(rsa->p, rsa->q) < 0) {
|
Make the rest of RSA CRT constant-time.
Alas, the existence of RSA keys with q > p is obnoxious, but we can
canonicalize it away. To my knowledge, the remaining leaks in RSA are:
- Key generation. This is kind of hopelessly non-constant-time but
perhaps deserves a more careful ponder. Though hopefully it does not
come in at a measurable point for practical purposes.
- Private key serialization. RSAPrivateKey inherently leaks the
magnitudes of d, dmp1, dmq1, and iqmp. This is unavoidable but
hopefully does not come in at a measurable point for practical
purposes.
- If p and q have different word widths, we currently fall back to the
variable-time BN_mod rather than Montgomery reduction at the start of
CRT. I can think of ways to apply Montgomery reduction, but it's
probably better to deny CRT to such keys, if not reject them outright.
- bn_mul_fixed and bn_sqr_fixed which affect the Montgomery
multiplication bn_mul_mont-less configurations, as well as the final
CRT multiplication. We should fix this.
Bug: 233
Change-Id: I8c2ecf8f8ec104e9f26299b66ac8cbb0cad04616
Reviewed-on: https://boringssl-review.googlesource.com/25263
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
2018-01-24 22:22:17 +00:00
|
|
|
|
mont_p = rsa->mont_q;
|
|
|
|
|
mont_q = rsa->mont_p;
|
Fix threading issues with RSA freeze_private_key.
OpenSSL's RSA API is poorly designed and does not have a single place to
properly initialize the key. See
https://github.com/openssl/openssl/issues/5158.
To workaround this flaw, we must lazily instantiate pre-computed
Montgomery bits with locking. This is a ton of complexity. More
importantly, it makes it very difficult to implement RSA without side
channels. The correct in-memory representation of d, dmp1, and dmq1
depend on n, p, and q, respectively. (Those values have private
magnitudes and must be sized relative to the respective moduli.)
08805fe27910e09d05e87d61bc5411a4e3b2d999 attempted to fix up the various
widths under lock, when we set up BN_MONT_CTX. However, this introduces
threading issues because other threads may access those exposed
components (RSA_get0_* also count as exposed for these purposes because
they are get0 functions), while a private key operation is in progress.
Instead, we do the following:
- There is no actual need to minimize n, p, and q, but we have minimized
copies in the BN_MONT_CTXs, so use those.
- Store additional copies of d, dmp1, and dmq1, at the cost of more
memory used. These copies have the correct width and are private,
unlike d, dmp1, and dmq1 which are sadly exposed. Fix private key
operations to use them.
- Move the frozen bit out of rsa->flags, as that too was historically
accessible without locking.
(Serialization still uses the original BIGNUMs, but the RSAPrivateKey
serialization format already inherently leaks the magnitude, so this
doesn't matter.)
Change-Id: Ia3a9b0629f8efef23abb30bfed110d247d1db42f
Reviewed-on: https://boringssl-review.googlesource.com/25824
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
2018-02-09 20:52:58 +00:00
|
|
|
|
dmp1 = rsa->dmq1_fixed;
|
|
|
|
|
dmq1 = rsa->dmp1_fixed;
|
Make the rest of RSA CRT constant-time.
Alas, the existence of RSA keys with q > p is obnoxious, but we can
canonicalize it away. To my knowledge, the remaining leaks in RSA are:
- Key generation. This is kind of hopelessly non-constant-time but
perhaps deserves a more careful ponder. Though hopefully it does not
come in at a measurable point for practical purposes.
- Private key serialization. RSAPrivateKey inherently leaks the
magnitudes of d, dmp1, dmq1, and iqmp. This is unavoidable but
hopefully does not come in at a measurable point for practical
purposes.
- If p and q have different word widths, we currently fall back to the
variable-time BN_mod rather than Montgomery reduction at the start of
CRT. I can think of ways to apply Montgomery reduction, but it's
probably better to deny CRT to such keys, if not reject them outright.
- bn_mul_fixed and bn_sqr_fixed which affect the Montgomery
multiplication bn_mul_mont-less configurations, as well as the final
CRT multiplication. We should fix this.
Bug: 233
Change-Id: I8c2ecf8f8ec104e9f26299b66ac8cbb0cad04616
Reviewed-on: https://boringssl-review.googlesource.com/25263
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
2018-01-24 22:22:17 +00:00
|
|
|
|
}
|
|
|
|
|
|
Fix threading issues with RSA freeze_private_key.
OpenSSL's RSA API is poorly designed and does not have a single place to
properly initialize the key. See
https://github.com/openssl/openssl/issues/5158.
To workaround this flaw, we must lazily instantiate pre-computed
Montgomery bits with locking. This is a ton of complexity. More
importantly, it makes it very difficult to implement RSA without side
channels. The correct in-memory representation of d, dmp1, and dmq1
depend on n, p, and q, respectively. (Those values have private
magnitudes and must be sized relative to the respective moduli.)
08805fe27910e09d05e87d61bc5411a4e3b2d999 attempted to fix up the various
widths under lock, when we set up BN_MONT_CTX. However, this introduces
threading issues because other threads may access those exposed
components (RSA_get0_* also count as exposed for these purposes because
they are get0 functions), while a private key operation is in progress.
Instead, we do the following:
- There is no actual need to minimize n, p, and q, but we have minimized
copies in the BN_MONT_CTXs, so use those.
- Store additional copies of d, dmp1, and dmq1, at the cost of more
memory used. These copies have the correct width and are private,
unlike d, dmp1, and dmq1 which are sadly exposed. Fix private key
operations to use them.
- Move the frozen bit out of rsa->flags, as that too was historically
accessible without locking.
(Serialization still uses the original BIGNUMs, but the RSAPrivateKey
serialization format already inherently leaks the magnitude, so this
doesn't matter.)
Change-Id: Ia3a9b0629f8efef23abb30bfed110d247d1db42f
Reviewed-on: https://boringssl-review.googlesource.com/25824
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
2018-02-09 20:52:58 +00:00
|
|
|
|
// Use the minimal-width versions of |n|, |p|, and |q|. Either works, but if
|
|
|
|
|
// someone gives us non-minimal values, these will be slightly more efficient
|
|
|
|
|
// on the non-Montgomery operations.
|
|
|
|
|
const BIGNUM *n = &rsa->mont_n->N;
|
|
|
|
|
const BIGNUM *p = &mont_p->N;
|
|
|
|
|
const BIGNUM *q = &mont_q->N;
|
|
|
|
|
|
2017-12-14 17:54:12 +00:00
|
|
|
|
// This is a pre-condition for |mod_montgomery|. It was already checked by the
|
|
|
|
|
// caller.
|
Fix threading issues with RSA freeze_private_key.
OpenSSL's RSA API is poorly designed and does not have a single place to
properly initialize the key. See
https://github.com/openssl/openssl/issues/5158.
To workaround this flaw, we must lazily instantiate pre-computed
Montgomery bits with locking. This is a ton of complexity. More
importantly, it makes it very difficult to implement RSA without side
channels. The correct in-memory representation of d, dmp1, and dmq1
depend on n, p, and q, respectively. (Those values have private
magnitudes and must be sized relative to the respective moduli.)
08805fe27910e09d05e87d61bc5411a4e3b2d999 attempted to fix up the various
widths under lock, when we set up BN_MONT_CTX. However, this introduces
threading issues because other threads may access those exposed
components (RSA_get0_* also count as exposed for these purposes because
they are get0 functions), while a private key operation is in progress.
Instead, we do the following:
- There is no actual need to minimize n, p, and q, but we have minimized
copies in the BN_MONT_CTXs, so use those.
- Store additional copies of d, dmp1, and dmq1, at the cost of more
memory used. These copies have the correct width and are private,
unlike d, dmp1, and dmq1 which are sadly exposed. Fix private key
operations to use them.
- Move the frozen bit out of rsa->flags, as that too was historically
accessible without locking.
(Serialization still uses the original BIGNUMs, but the RSAPrivateKey
serialization format already inherently leaks the magnitude, so this
doesn't matter.)
Change-Id: Ia3a9b0629f8efef23abb30bfed110d247d1db42f
Reviewed-on: https://boringssl-review.googlesource.com/25824
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
2018-02-09 20:52:58 +00:00
|
|
|
|
assert(BN_ucmp(I, n) < 0);
|
2017-12-14 17:54:12 +00:00
|
|
|
|
|
Make the rest of RSA CRT constant-time.
Alas, the existence of RSA keys with q > p is obnoxious, but we can
canonicalize it away. To my knowledge, the remaining leaks in RSA are:
- Key generation. This is kind of hopelessly non-constant-time but
perhaps deserves a more careful ponder. Though hopefully it does not
come in at a measurable point for practical purposes.
- Private key serialization. RSAPrivateKey inherently leaks the
magnitudes of d, dmp1, dmq1, and iqmp. This is unavoidable but
hopefully does not come in at a measurable point for practical
purposes.
- If p and q have different word widths, we currently fall back to the
variable-time BN_mod rather than Montgomery reduction at the start of
CRT. I can think of ways to apply Montgomery reduction, but it's
probably better to deny CRT to such keys, if not reject them outright.
- bn_mul_fixed and bn_sqr_fixed which affect the Montgomery
multiplication bn_mul_mont-less configurations, as well as the final
CRT multiplication. We should fix this.
Bug: 233
Change-Id: I8c2ecf8f8ec104e9f26299b66ac8cbb0cad04616
Reviewed-on: https://boringssl-review.googlesource.com/25263
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
2018-01-24 22:22:17 +00:00
|
|
|
|
if (// |m1| is the result modulo |q|.
|
|
|
|
|
!mod_montgomery(r1, I, q, mont_q, p, ctx) ||
|
|
|
|
|
!BN_mod_exp_mont_consttime(m1, r1, dmq1, q, ctx, mont_q) ||
|
|
|
|
|
// |r0| is the result modulo |p|.
|
|
|
|
|
!mod_montgomery(r1, I, p, mont_p, q, ctx) ||
|
|
|
|
|
!BN_mod_exp_mont_consttime(r0, r1, dmp1, p, ctx, mont_p) ||
|
|
|
|
|
// Compute r0 = r0 - m1 mod p. |p| is the larger prime, so |m1| is already
|
|
|
|
|
// fully reduced mod |p|.
|
2018-02-06 23:56:10 +00:00
|
|
|
|
!bn_mod_sub_consttime(r0, r0, m1, p, ctx) ||
|
Make the rest of RSA CRT constant-time.
Alas, the existence of RSA keys with q > p is obnoxious, but we can
canonicalize it away. To my knowledge, the remaining leaks in RSA are:
- Key generation. This is kind of hopelessly non-constant-time but
perhaps deserves a more careful ponder. Though hopefully it does not
come in at a measurable point for practical purposes.
- Private key serialization. RSAPrivateKey inherently leaks the
magnitudes of d, dmp1, dmq1, and iqmp. This is unavoidable but
hopefully does not come in at a measurable point for practical
purposes.
- If p and q have different word widths, we currently fall back to the
variable-time BN_mod rather than Montgomery reduction at the start of
CRT. I can think of ways to apply Montgomery reduction, but it's
probably better to deny CRT to such keys, if not reject them outright.
- bn_mul_fixed and bn_sqr_fixed which affect the Montgomery
multiplication bn_mul_mont-less configurations, as well as the final
CRT multiplication. We should fix this.
Bug: 233
Change-Id: I8c2ecf8f8ec104e9f26299b66ac8cbb0cad04616
Reviewed-on: https://boringssl-review.googlesource.com/25263
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
2018-01-24 22:22:17 +00:00
|
|
|
|
// r0 = r0 * iqmp mod p. We use Montgomery multiplication to compute this
|
|
|
|
|
// in constant time. |inv_small_mod_large_mont| is in Montgomery form and
|
|
|
|
|
// r0 is not, so the result is taken out of Montgomery form.
|
|
|
|
|
!BN_mod_mul_montgomery(r0, r0, rsa->inv_small_mod_large_mont, mont_p,
|
|
|
|
|
ctx) ||
|
|
|
|
|
// r0 = r0 * q + m1 gives the final result. Reducing modulo q gives m1, so
|
|
|
|
|
// it is correct mod p. Reducing modulo p gives (r0-m1)*iqmp*q + m1 = r0,
|
|
|
|
|
// so it is correct mod q. Finally, the result is bounded by [m1, n + m1),
|
|
|
|
|
// and the result is at least |m1|, so this must be the unique answer in
|
|
|
|
|
// [0, n).
|
2018-02-06 23:56:10 +00:00
|
|
|
|
!bn_mul_consttime(r0, r0, q, ctx) ||
|
|
|
|
|
!bn_uadd_consttime(r0, r0, m1) ||
|
Fix threading issues with RSA freeze_private_key.
OpenSSL's RSA API is poorly designed and does not have a single place to
properly initialize the key. See
https://github.com/openssl/openssl/issues/5158.
To workaround this flaw, we must lazily instantiate pre-computed
Montgomery bits with locking. This is a ton of complexity. More
importantly, it makes it very difficult to implement RSA without side
channels. The correct in-memory representation of d, dmp1, and dmq1
depend on n, p, and q, respectively. (Those values have private
magnitudes and must be sized relative to the respective moduli.)
08805fe27910e09d05e87d61bc5411a4e3b2d999 attempted to fix up the various
widths under lock, when we set up BN_MONT_CTX. However, this introduces
threading issues because other threads may access those exposed
components (RSA_get0_* also count as exposed for these purposes because
they are get0 functions), while a private key operation is in progress.
Instead, we do the following:
- There is no actual need to minimize n, p, and q, but we have minimized
copies in the BN_MONT_CTXs, so use those.
- Store additional copies of d, dmp1, and dmq1, at the cost of more
memory used. These copies have the correct width and are private,
unlike d, dmp1, and dmq1 which are sadly exposed. Fix private key
operations to use them.
- Move the frozen bit out of rsa->flags, as that too was historically
accessible without locking.
(Serialization still uses the original BIGNUMs, but the RSAPrivateKey
serialization format already inherently leaks the magnitude, so this
doesn't matter.)
Change-Id: Ia3a9b0629f8efef23abb30bfed110d247d1db42f
Reviewed-on: https://boringssl-review.googlesource.com/25824
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
2018-02-09 20:52:58 +00:00
|
|
|
|
// The result should be bounded by |n|, but fixed-width operations may
|
Make the rest of RSA CRT constant-time.
Alas, the existence of RSA keys with q > p is obnoxious, but we can
canonicalize it away. To my knowledge, the remaining leaks in RSA are:
- Key generation. This is kind of hopelessly non-constant-time but
perhaps deserves a more careful ponder. Though hopefully it does not
come in at a measurable point for practical purposes.
- Private key serialization. RSAPrivateKey inherently leaks the
magnitudes of d, dmp1, dmq1, and iqmp. This is unavoidable but
hopefully does not come in at a measurable point for practical
purposes.
- If p and q have different word widths, we currently fall back to the
variable-time BN_mod rather than Montgomery reduction at the start of
CRT. I can think of ways to apply Montgomery reduction, but it's
probably better to deny CRT to such keys, if not reject them outright.
- bn_mul_fixed and bn_sqr_fixed which affect the Montgomery
multiplication bn_mul_mont-less configurations, as well as the final
CRT multiplication. We should fix this.
Bug: 233
Change-Id: I8c2ecf8f8ec104e9f26299b66ac8cbb0cad04616
Reviewed-on: https://boringssl-review.googlesource.com/25263
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
2018-01-24 22:22:17 +00:00
|
|
|
|
// bound the width slightly higher, so fix it.
|
Fix threading issues with RSA freeze_private_key.
OpenSSL's RSA API is poorly designed and does not have a single place to
properly initialize the key. See
https://github.com/openssl/openssl/issues/5158.
To workaround this flaw, we must lazily instantiate pre-computed
Montgomery bits with locking. This is a ton of complexity. More
importantly, it makes it very difficult to implement RSA without side
channels. The correct in-memory representation of d, dmp1, and dmq1
depend on n, p, and q, respectively. (Those values have private
magnitudes and must be sized relative to the respective moduli.)
08805fe27910e09d05e87d61bc5411a4e3b2d999 attempted to fix up the various
widths under lock, when we set up BN_MONT_CTX. However, this introduces
threading issues because other threads may access those exposed
components (RSA_get0_* also count as exposed for these purposes because
they are get0 functions), while a private key operation is in progress.
Instead, we do the following:
- There is no actual need to minimize n, p, and q, but we have minimized
copies in the BN_MONT_CTXs, so use those.
- Store additional copies of d, dmp1, and dmq1, at the cost of more
memory used. These copies have the correct width and are private,
unlike d, dmp1, and dmq1 which are sadly exposed. Fix private key
operations to use them.
- Move the frozen bit out of rsa->flags, as that too was historically
accessible without locking.
(Serialization still uses the original BIGNUMs, but the RSAPrivateKey
serialization format already inherently leaks the magnitude, so this
doesn't matter.)
Change-Id: Ia3a9b0629f8efef23abb30bfed110d247d1db42f
Reviewed-on: https://boringssl-review.googlesource.com/25824
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
2018-02-09 20:52:58 +00:00
|
|
|
|
!bn_resize_words(r0, n->width)) {
|
2014-06-20 20:00:00 +01:00
|
|
|
|
goto err;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ret = 1;
|
|
|
|
|
|
|
|
|
|
err:
|
|
|
|
|
BN_CTX_end(ctx);
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
2017-04-10 23:05:19 +01:00
|
|
|
|
static int ensure_bignum(BIGNUM **out) {
|
|
|
|
|
if (*out == NULL) {
|
|
|
|
|
*out = BN_new();
|
|
|
|
|
}
|
|
|
|
|
return *out != NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2017-08-18 19:06:02 +01:00
|
|
|
|
// kBoringSSLRSASqrtTwo is the BIGNUM representation of ⌊2¹⁵³⁵×√2⌋. This is
|
|
|
|
|
// chosen to give enough precision for 3072-bit RSA, the largest key size FIPS
|
|
|
|
|
// specifies. Key sizes beyond this will round up.
|
|
|
|
|
//
|
|
|
|
|
// To verify this number, check that n² < 2³⁰⁷¹ < (n+1)², where n is value
|
|
|
|
|
// represented here. Note the components are listed in little-endian order. Here
|
|
|
|
|
// is some sample Python code to check:
|
|
|
|
|
//
|
|
|
|
|
// >>> TOBN = lambda a, b: a << 32 | b
|
|
|
|
|
// >>> l = [ <paste the contents of kSqrtTwo> ]
|
|
|
|
|
// >>> n = sum(a * 2**(64*i) for i, a in enumerate(l))
|
|
|
|
|
// >>> n**2 < 2**3071 < (n+1)**2
|
|
|
|
|
// True
|
2017-04-10 23:35:22 +01:00
|
|
|
|
const BN_ULONG kBoringSSLRSASqrtTwo[] = {
|
|
|
|
|
TOBN(0xdea06241, 0xf7aa81c2), TOBN(0xf6a1be3f, 0xca221307),
|
|
|
|
|
TOBN(0x332a5e9f, 0x7bda1ebf), TOBN(0x0104dc01, 0xfe32352f),
|
|
|
|
|
TOBN(0xb8cf341b, 0x6f8236c7), TOBN(0x4264dabc, 0xd528b651),
|
|
|
|
|
TOBN(0xf4d3a02c, 0xebc93e0c), TOBN(0x81394ab6, 0xd8fd0efd),
|
|
|
|
|
TOBN(0xeaa4a089, 0x9040ca4a), TOBN(0xf52f120f, 0x836e582e),
|
|
|
|
|
TOBN(0xcb2a6343, 0x31f3c84d), TOBN(0xc6d5a8a3, 0x8bb7e9dc),
|
|
|
|
|
TOBN(0x460abc72, 0x2f7c4e33), TOBN(0xcab1bc91, 0x1688458a),
|
|
|
|
|
TOBN(0x53059c60, 0x11bc337b), TOBN(0xd2202e87, 0x42af1f4e),
|
|
|
|
|
TOBN(0x78048736, 0x3dfa2768), TOBN(0x0f74a85e, 0x439c7b4a),
|
|
|
|
|
TOBN(0xa8b1fe6f, 0xdc83db39), TOBN(0x4afc8304, 0x3ab8a2c3),
|
|
|
|
|
TOBN(0xed17ac85, 0x83339915), TOBN(0x1d6f60ba, 0x893ba84c),
|
|
|
|
|
TOBN(0x597d89b3, 0x754abe9f), TOBN(0xb504f333, 0xf9de6484),
|
|
|
|
|
};
|
|
|
|
|
const size_t kBoringSSLRSASqrtTwoLen = OPENSSL_ARRAY_SIZE(kBoringSSLRSASqrtTwo);
|
|
|
|
|
|
2017-08-18 19:06:02 +01:00
|
|
|
|
// generate_prime sets |out| to a prime with length |bits| such that |out|-1 is
|
|
|
|
|
// relatively prime to |e|. If |p| is non-NULL, |out| will also not be close to
|
2018-03-04 05:13:13 +00:00
|
|
|
|
// |p|. |sqrt2| must be ⌊2^(bits-1)×√2⌋ (or a slightly overestimate for large
|
|
|
|
|
// sizes), and |pow2_bits_100| must be 2^(bits-100).
|
2018-04-10 23:35:16 +01:00
|
|
|
|
//
|
|
|
|
|
// This function fails with probability around 2^-21.
|
2017-04-10 23:35:22 +01:00
|
|
|
|
static int generate_prime(BIGNUM *out, int bits, const BIGNUM *e,
|
2018-03-04 05:13:13 +00:00
|
|
|
|
const BIGNUM *p, const BIGNUM *sqrt2,
|
|
|
|
|
const BIGNUM *pow2_bits_100, BN_CTX *ctx,
|
2018-01-20 23:55:47 +00:00
|
|
|
|
BN_GENCB *cb) {
|
2017-04-10 23:35:22 +01:00
|
|
|
|
if (bits < 128 || (bits % BN_BITS2) != 0) {
|
|
|
|
|
OPENSSL_PUT_ERROR(RSA, ERR_R_INTERNAL_ERROR);
|
|
|
|
|
return 0;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
}
|
2018-03-04 05:13:13 +00:00
|
|
|
|
assert(BN_is_pow2(pow2_bits_100));
|
|
|
|
|
assert(BN_is_bit_set(pow2_bits_100, bits - 100));
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
2017-11-03 19:24:36 +00:00
|
|
|
|
// See FIPS 186-4 appendix B.3.3, steps 4 and 5. Note |bits| here is nlen/2.
|
|
|
|
|
|
|
|
|
|
// Use the limit from steps 4.7 and 5.8 for most values of |e|. When |e| is 3,
|
|
|
|
|
// the 186-4 limit is too low, so we use a higher one. Note this case is not
|
|
|
|
|
// reachable from |RSA_generate_key_fips|.
|
2018-04-10 23:35:16 +01:00
|
|
|
|
//
|
|
|
|
|
// |limit| determines the failure probability. We must find a prime that is
|
|
|
|
|
// not 1 mod |e|. By the prime number theorem, we'll find one with probability
|
|
|
|
|
// p = (e-1)/e * 2/(ln(2)*bits). Note the second term is doubled because we
|
|
|
|
|
// discard even numbers.
|
|
|
|
|
//
|
|
|
|
|
// The failure probability is thus (1-p)^limit. To convert that to a power of
|
|
|
|
|
// two, we take logs. -log_2((1-p)^limit) = -limit * ln(1-p) / ln(2).
|
|
|
|
|
//
|
|
|
|
|
// >>> def f(bits, e, limit):
|
|
|
|
|
// ... p = (e-1.0)/e * 2.0/(math.log(2)*bits)
|
|
|
|
|
// ... return -limit * math.log(1 - p) / math.log(2)
|
|
|
|
|
// ...
|
|
|
|
|
// >>> f(1024, 65537, 5*1024)
|
|
|
|
|
// 20.842750558272634
|
|
|
|
|
// >>> f(1536, 65537, 5*1536)
|
|
|
|
|
// 20.83294549602474
|
|
|
|
|
// >>> f(2048, 65537, 5*2048)
|
|
|
|
|
// 20.828047576234948
|
|
|
|
|
// >>> f(1024, 3, 8*1024)
|
|
|
|
|
// 22.222147925962307
|
|
|
|
|
// >>> f(1536, 3, 8*1536)
|
|
|
|
|
// 22.21518251065506
|
|
|
|
|
// >>> f(2048, 3, 8*2048)
|
|
|
|
|
// 22.211701985875937
|
2017-11-03 19:24:36 +00:00
|
|
|
|
if (bits >= INT_MAX/32) {
|
2017-04-10 23:35:22 +01:00
|
|
|
|
OPENSSL_PUT_ERROR(RSA, RSA_R_MODULUS_TOO_LARGE);
|
|
|
|
|
return 0;
|
2015-02-11 06:17:41 +00:00
|
|
|
|
}
|
2018-04-10 23:35:16 +01:00
|
|
|
|
int limit = BN_is_word(e, 3) ? bits * 8 : bits * 5;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
2017-04-10 23:35:22 +01:00
|
|
|
|
int ret = 0, tries = 0, rand_tries = 0;
|
|
|
|
|
BN_CTX_start(ctx);
|
|
|
|
|
BIGNUM *tmp = BN_CTX_get(ctx);
|
|
|
|
|
if (tmp == NULL) {
|
2015-06-12 02:42:14 +01:00
|
|
|
|
goto err;
|
|
|
|
|
}
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
|
|
|
|
for (;;) {
|
2017-08-18 19:06:02 +01:00
|
|
|
|
// Generate a random number of length |bits| where the bottom bit is set
|
|
|
|
|
// (steps 4.2, 4.3, 5.2 and 5.3) and the top bit is set (implied by the
|
|
|
|
|
// bound checked below in steps 4.4 and 5.5).
|
2017-04-10 23:35:22 +01:00
|
|
|
|
if (!BN_rand(out, bits, BN_RAND_TOP_ONE, BN_RAND_BOTTOM_ODD) ||
|
|
|
|
|
!BN_GENCB_call(cb, BN_GENCB_GENERATED, rand_tries++)) {
|
2014-06-20 20:00:00 +01:00
|
|
|
|
goto err;
|
2015-02-11 06:17:41 +00:00
|
|
|
|
}
|
2017-04-10 23:35:22 +01:00
|
|
|
|
|
|
|
|
|
if (p != NULL) {
|
2017-08-18 19:06:02 +01:00
|
|
|
|
// If |p| and |out| are too close, try again (step 5.4).
|
2018-03-04 05:38:00 +00:00
|
|
|
|
if (!bn_abs_sub_consttime(tmp, out, p, ctx)) {
|
2017-04-10 23:35:22 +01:00
|
|
|
|
goto err;
|
|
|
|
|
}
|
2018-03-04 05:13:13 +00:00
|
|
|
|
if (BN_cmp(tmp, pow2_bits_100) <= 0) {
|
2017-04-10 23:35:22 +01:00
|
|
|
|
continue;
|
|
|
|
|
}
|
2015-02-11 06:17:41 +00:00
|
|
|
|
}
|
2017-04-10 23:35:22 +01:00
|
|
|
|
|
2018-01-20 23:55:47 +00:00
|
|
|
|
// If out < 2^(bits-1)×√2, try again (steps 4.4 and 5.5). This is equivalent
|
|
|
|
|
// to out <= ⌊2^(bits-1)×√2⌋, or out <= sqrt2 for FIPS key sizes.
|
2017-08-18 19:06:02 +01:00
|
|
|
|
//
|
|
|
|
|
// For larger keys, the comparison is approximate, leaning towards
|
|
|
|
|
// retrying. That is, we reject a negligible fraction of primes that are
|
|
|
|
|
// within the FIPS bound, but we will never accept a prime outside the
|
2018-01-20 23:55:47 +00:00
|
|
|
|
// bound, ensuring the resulting RSA key is the right size.
|
2018-01-27 23:54:28 +00:00
|
|
|
|
if (BN_cmp(out, sqrt2) <= 0) {
|
2017-04-10 23:35:22 +01:00
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
2018-02-06 23:32:30 +00:00
|
|
|
|
// RSA key generation's bottleneck is discarding composites. If it fails
|
|
|
|
|
// trial division, do not bother computing a GCD or performing Rabin-Miller.
|
|
|
|
|
if (!bn_odd_number_is_obviously_composite(out)) {
|
|
|
|
|
// Check gcd(out-1, e) is one (steps 4.5 and 5.6).
|
2018-03-04 04:57:52 +00:00
|
|
|
|
int relatively_prime;
|
2018-02-06 23:32:30 +00:00
|
|
|
|
if (!BN_sub(tmp, out, BN_value_one()) ||
|
2018-03-04 04:57:52 +00:00
|
|
|
|
!bn_is_relatively_prime(&relatively_prime, tmp, e, ctx)) {
|
2017-04-10 23:35:22 +01:00
|
|
|
|
goto err;
|
|
|
|
|
}
|
2018-03-04 04:57:52 +00:00
|
|
|
|
if (relatively_prime) {
|
2018-02-06 23:32:30 +00:00
|
|
|
|
// Test |out| for primality (steps 4.5.1 and 5.6.1).
|
|
|
|
|
int is_probable_prime;
|
|
|
|
|
if (!BN_primality_test(&is_probable_prime, out, BN_prime_checks, ctx, 0,
|
|
|
|
|
cb)) {
|
|
|
|
|
goto err;
|
|
|
|
|
}
|
|
|
|
|
if (is_probable_prime) {
|
|
|
|
|
ret = 1;
|
|
|
|
|
goto err;
|
|
|
|
|
}
|
2015-02-11 06:17:41 +00:00
|
|
|
|
}
|
2014-06-20 20:00:00 +01:00
|
|
|
|
}
|
2017-04-10 23:35:22 +01:00
|
|
|
|
|
2017-08-18 19:06:02 +01:00
|
|
|
|
// If we've tried too many times to find a prime, abort (steps 4.7 and
|
|
|
|
|
// 5.8).
|
2017-04-10 23:35:22 +01:00
|
|
|
|
tries++;
|
2017-11-03 19:24:36 +00:00
|
|
|
|
if (tries >= limit) {
|
2017-04-10 23:35:22 +01:00
|
|
|
|
OPENSSL_PUT_ERROR(RSA, RSA_R_TOO_MANY_ITERATIONS);
|
2014-06-20 20:00:00 +01:00
|
|
|
|
goto err;
|
2015-02-11 06:17:41 +00:00
|
|
|
|
}
|
2017-04-10 23:35:22 +01:00
|
|
|
|
if (!BN_GENCB_call(cb, 2, tries)) {
|
2014-06-20 20:00:00 +01:00
|
|
|
|
goto err;
|
2015-02-11 06:17:41 +00:00
|
|
|
|
}
|
2014-06-20 20:00:00 +01:00
|
|
|
|
}
|
2015-05-26 19:36:46 +01:00
|
|
|
|
|
2017-04-10 23:35:22 +01:00
|
|
|
|
err:
|
|
|
|
|
BN_CTX_end(ctx);
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
2015-05-26 19:36:46 +01:00
|
|
|
|
|
2018-04-10 23:35:16 +01:00
|
|
|
|
// rsa_generate_key_impl generates an RSA key using a generalized version of
|
|
|
|
|
// FIPS 186-4 appendix B.3. |RSA_generate_key_fips| performs additional checks
|
|
|
|
|
// for FIPS-compliant key generation.
|
|
|
|
|
//
|
|
|
|
|
// This function returns one on success and zero on failure. It has a failure
|
|
|
|
|
// probability of about 2^-20.
|
|
|
|
|
static int rsa_generate_key_impl(RSA *rsa, int bits, BIGNUM *e_value,
|
|
|
|
|
BN_GENCB *cb) {
|
2017-08-18 19:06:02 +01:00
|
|
|
|
// See FIPS 186-4 appendix B.3. This function implements a generalized version
|
|
|
|
|
// of the FIPS algorithm. |RSA_generate_key_fips| performs additional checks
|
|
|
|
|
// for FIPS-compliant key generation.
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
2017-08-18 19:06:02 +01:00
|
|
|
|
// Always generate RSA keys which are a multiple of 128 bits. Round |bits|
|
|
|
|
|
// down as needed.
|
2017-04-10 23:35:22 +01:00
|
|
|
|
bits &= ~127;
|
|
|
|
|
|
2017-08-18 19:06:02 +01:00
|
|
|
|
// Reject excessively small keys.
|
2017-04-10 23:35:22 +01:00
|
|
|
|
if (bits < 256) {
|
|
|
|
|
OPENSSL_PUT_ERROR(RSA, RSA_R_KEY_SIZE_TOO_SMALL);
|
|
|
|
|
return 0;
|
2015-02-11 06:17:41 +00:00
|
|
|
|
}
|
2017-04-10 23:35:22 +01:00
|
|
|
|
|
Limit the public exponent in RSA_generate_key_ex.
Windows CryptoAPI and Go bound public exponents at 2^32-1, so don't
generate keys which would violate that.
https://github.com/golang/go/issues/3161
https://msdn.microsoft.com/en-us/library/aa387685(VS.85).aspx
BoringSSL itself also enforces a 33-bit limit.
I don't currently have plans to take much advantage of it, but the
modular inverse step and one of the GCDs in RSA key generation are
helped by small public exponents[0]. In case someone feels inspired
later, get this limit enforced now. Use 32-bits as that's a more
convenient limit, and there's no requirement to produce e=2^32+1 keys.
(Is there still a requirement to accept them?)
[0] This isn't too bad, but it's only worth it if it produces simpler or
smaller code. RSA keygen is not performance-critical.
1. Make bn_mod_u16_consttime work for uint32_t. It only barely doesn't
work. Maybe only accept 3 and 65537 and pre-compute, maybe call into
bn_div_rem_words and friends, maybe just tighten the bound a hair
longer.
2. Implement bn_div_u32_consttime by incorporating 32-bit chunks much
like bn_mod_u32_consttime.
3. Perform one normal Euclidean algorithm iteration rather than using the
binary version. u, v, B, and D are now single words, while A and C
are full-width.
4. Continue with binary Euclidean algorithm (u and v are still secret),
taking advantage of most values being small.
Update-Note: RSA_generate_key_ex will no longer generate keys with
public exponents larger than 2^32-1. Everyone uses 65537, save some
folks who use 3, so this shouldn't matter.
Change-Id: I0d28a29a30d9ff73bff282e34dd98e2b64c35c79
Reviewed-on: https://boringssl-review.googlesource.com/26365
Reviewed-by: Adam Langley <alangley@gmail.com>
2018-03-04 03:07:49 +00:00
|
|
|
|
// Reject excessively large public exponents. Windows CryptoAPI and Go don't
|
|
|
|
|
// support values larger than 32 bits, so match their limits for generating
|
|
|
|
|
// keys. (|check_modulus_and_exponent_sizes| uses a slightly more conservative
|
|
|
|
|
// value, but we don't need to support generating such keys.)
|
|
|
|
|
// https://github.com/golang/go/issues/3161
|
|
|
|
|
// https://msdn.microsoft.com/en-us/library/aa387685(VS.85).aspx
|
|
|
|
|
if (BN_num_bits(e_value) > 32) {
|
|
|
|
|
OPENSSL_PUT_ERROR(RSA, RSA_R_BAD_E_VALUE);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2017-04-10 23:35:22 +01:00
|
|
|
|
int ret = 0;
|
2018-03-04 05:13:13 +00:00
|
|
|
|
int prime_bits = bits / 2;
|
2017-04-10 23:35:22 +01:00
|
|
|
|
BN_CTX *ctx = BN_CTX_new();
|
|
|
|
|
if (ctx == NULL) {
|
|
|
|
|
goto bn_err;
|
2015-02-11 06:17:41 +00:00
|
|
|
|
}
|
2017-04-10 23:35:22 +01:00
|
|
|
|
BN_CTX_start(ctx);
|
2017-05-04 18:50:39 +01:00
|
|
|
|
BIGNUM *totient = BN_CTX_get(ctx);
|
|
|
|
|
BIGNUM *pm1 = BN_CTX_get(ctx);
|
|
|
|
|
BIGNUM *qm1 = BN_CTX_get(ctx);
|
2018-01-20 23:55:47 +00:00
|
|
|
|
BIGNUM *sqrt2 = BN_CTX_get(ctx);
|
2018-03-04 05:13:13 +00:00
|
|
|
|
BIGNUM *pow2_prime_bits_100 = BN_CTX_get(ctx);
|
|
|
|
|
BIGNUM *pow2_prime_bits = BN_CTX_get(ctx);
|
2018-03-04 04:57:52 +00:00
|
|
|
|
if (totient == NULL || pm1 == NULL || qm1 == NULL || sqrt2 == NULL ||
|
|
|
|
|
pow2_prime_bits_100 == NULL || pow2_prime_bits == NULL ||
|
2018-03-04 05:13:13 +00:00
|
|
|
|
!BN_set_bit(pow2_prime_bits_100, prime_bits - 100) ||
|
|
|
|
|
!BN_set_bit(pow2_prime_bits, prime_bits)) {
|
2017-04-10 23:35:22 +01:00
|
|
|
|
goto bn_err;
|
2015-02-11 06:17:41 +00:00
|
|
|
|
}
|
2017-04-10 23:35:22 +01:00
|
|
|
|
|
2017-08-18 19:06:02 +01:00
|
|
|
|
// We need the RSA components non-NULL.
|
2017-04-10 23:35:22 +01:00
|
|
|
|
if (!ensure_bignum(&rsa->n) ||
|
|
|
|
|
!ensure_bignum(&rsa->d) ||
|
|
|
|
|
!ensure_bignum(&rsa->e) ||
|
|
|
|
|
!ensure_bignum(&rsa->p) ||
|
|
|
|
|
!ensure_bignum(&rsa->q) ||
|
|
|
|
|
!ensure_bignum(&rsa->dmp1) ||
|
Make the rest of RSA CRT constant-time.
Alas, the existence of RSA keys with q > p is obnoxious, but we can
canonicalize it away. To my knowledge, the remaining leaks in RSA are:
- Key generation. This is kind of hopelessly non-constant-time but
perhaps deserves a more careful ponder. Though hopefully it does not
come in at a measurable point for practical purposes.
- Private key serialization. RSAPrivateKey inherently leaks the
magnitudes of d, dmp1, dmq1, and iqmp. This is unavoidable but
hopefully does not come in at a measurable point for practical
purposes.
- If p and q have different word widths, we currently fall back to the
variable-time BN_mod rather than Montgomery reduction at the start of
CRT. I can think of ways to apply Montgomery reduction, but it's
probably better to deny CRT to such keys, if not reject them outright.
- bn_mul_fixed and bn_sqr_fixed which affect the Montgomery
multiplication bn_mul_mont-less configurations, as well as the final
CRT multiplication. We should fix this.
Bug: 233
Change-Id: I8c2ecf8f8ec104e9f26299b66ac8cbb0cad04616
Reviewed-on: https://boringssl-review.googlesource.com/25263
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
2018-01-24 22:22:17 +00:00
|
|
|
|
!ensure_bignum(&rsa->dmq1)) {
|
2017-04-10 23:35:22 +01:00
|
|
|
|
goto bn_err;
|
2015-02-11 06:17:41 +00:00
|
|
|
|
}
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
2017-04-10 23:35:22 +01:00
|
|
|
|
if (!BN_copy(rsa->e, e_value)) {
|
|
|
|
|
goto bn_err;
|
|
|
|
|
}
|
|
|
|
|
|
2018-01-20 23:55:47 +00:00
|
|
|
|
// Compute sqrt2 >= ⌊2^(prime_bits-1)×√2⌋.
|
|
|
|
|
if (!bn_set_words(sqrt2, kBoringSSLRSASqrtTwo, kBoringSSLRSASqrtTwoLen)) {
|
|
|
|
|
goto bn_err;
|
|
|
|
|
}
|
|
|
|
|
int sqrt2_bits = kBoringSSLRSASqrtTwoLen * BN_BITS2;
|
|
|
|
|
assert(sqrt2_bits == (int)BN_num_bits(sqrt2));
|
|
|
|
|
if (sqrt2_bits > prime_bits) {
|
|
|
|
|
// For key sizes up to 3072 (prime_bits = 1536), this is exactly
|
|
|
|
|
// ⌊2^(prime_bits-1)×√2⌋.
|
|
|
|
|
if (!BN_rshift(sqrt2, sqrt2, sqrt2_bits - prime_bits)) {
|
|
|
|
|
goto bn_err;
|
|
|
|
|
}
|
|
|
|
|
} else if (prime_bits > sqrt2_bits) {
|
|
|
|
|
// For key sizes beyond 3072, this is approximate. We err towards retrying
|
|
|
|
|
// to ensure our key is the right size and round up.
|
|
|
|
|
if (!BN_add_word(sqrt2, 1) ||
|
|
|
|
|
!BN_lshift(sqrt2, sqrt2, prime_bits - sqrt2_bits)) {
|
|
|
|
|
goto bn_err;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
assert(prime_bits == (int)BN_num_bits(sqrt2));
|
|
|
|
|
|
2017-04-10 23:35:22 +01:00
|
|
|
|
do {
|
2017-08-18 19:06:02 +01:00
|
|
|
|
// Generate p and q, each of size |prime_bits|, using the steps outlined in
|
|
|
|
|
// appendix FIPS 186-4 appendix B.3.3.
|
2018-04-10 23:35:16 +01:00
|
|
|
|
//
|
|
|
|
|
// Each call to |generate_prime| fails with probability p = 2^-21. The
|
|
|
|
|
// probability that either call fails is 1 - (1-p)^2, which is around 2^-20.
|
2018-03-04 05:13:13 +00:00
|
|
|
|
if (!generate_prime(rsa->p, prime_bits, rsa->e, NULL, sqrt2,
|
|
|
|
|
pow2_prime_bits_100, ctx, cb) ||
|
2017-04-10 23:35:22 +01:00
|
|
|
|
!BN_GENCB_call(cb, 3, 0) ||
|
2018-03-04 05:13:13 +00:00
|
|
|
|
!generate_prime(rsa->q, prime_bits, rsa->e, rsa->p, sqrt2,
|
|
|
|
|
pow2_prime_bits_100, ctx, cb) ||
|
2017-04-10 23:35:22 +01:00
|
|
|
|
!BN_GENCB_call(cb, 3, 1)) {
|
|
|
|
|
goto bn_err;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (BN_cmp(rsa->p, rsa->q) < 0) {
|
|
|
|
|
BIGNUM *tmp = rsa->p;
|
|
|
|
|
rsa->p = rsa->q;
|
|
|
|
|
rsa->q = tmp;
|
|
|
|
|
}
|
|
|
|
|
|
2017-08-18 19:06:02 +01:00
|
|
|
|
// Calculate d = e^(-1) (mod lcm(p-1, q-1)), per FIPS 186-4. This differs
|
|
|
|
|
// from typical RSA implementations which use (p-1)*(q-1).
|
|
|
|
|
//
|
|
|
|
|
// Note this means the size of d might reveal information about p-1 and
|
|
|
|
|
// q-1. However, we do operations with Chinese Remainder Theorem, so we only
|
|
|
|
|
// use d (mod p-1) and d (mod q-1) as exponents. Using a minimal totient
|
|
|
|
|
// does not affect those two values.
|
2018-03-04 04:57:52 +00:00
|
|
|
|
int no_inverse;
|
|
|
|
|
if (!bn_usub_consttime(pm1, rsa->p, BN_value_one()) ||
|
|
|
|
|
!bn_usub_consttime(qm1, rsa->q, BN_value_one()) ||
|
|
|
|
|
!bn_lcm_consttime(totient, pm1, qm1, ctx) ||
|
|
|
|
|
!bn_mod_inverse_consttime(rsa->d, &no_inverse, rsa->e, totient, ctx)) {
|
2017-04-10 23:35:22 +01:00
|
|
|
|
goto bn_err;
|
|
|
|
|
}
|
|
|
|
|
|
2018-03-04 05:13:13 +00:00
|
|
|
|
// Retry if |rsa->d| <= 2^|prime_bits|. See appendix B.3.1's guidance on
|
|
|
|
|
// values for d.
|
|
|
|
|
} while (BN_cmp(rsa->d, pow2_prime_bits) <= 0);
|
2017-04-10 23:35:22 +01:00
|
|
|
|
|
2017-08-18 19:06:02 +01:00
|
|
|
|
if (// Calculate n.
|
2018-03-04 04:57:52 +00:00
|
|
|
|
!bn_mul_consttime(rsa->n, rsa->p, rsa->q, ctx) ||
|
2017-08-18 19:06:02 +01:00
|
|
|
|
// Calculate d mod (p-1).
|
2018-03-04 04:57:52 +00:00
|
|
|
|
!bn_div_consttime(NULL, rsa->dmp1, rsa->d, pm1, ctx) ||
|
2017-08-18 19:06:02 +01:00
|
|
|
|
// Calculate d mod (q-1)
|
2018-03-04 04:57:52 +00:00
|
|
|
|
!bn_div_consttime(NULL, rsa->dmq1, rsa->d, qm1, ctx)) {
|
2017-04-10 23:35:22 +01:00
|
|
|
|
goto bn_err;
|
2015-02-11 06:17:41 +00:00
|
|
|
|
}
|
2018-03-04 04:57:52 +00:00
|
|
|
|
bn_set_minimal_width(rsa->n);
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
2017-08-18 19:06:02 +01:00
|
|
|
|
// Sanity-check that |rsa->n| has the specified size. This is implied by
|
|
|
|
|
// |generate_prime|'s bounds.
|
2017-04-10 23:35:22 +01:00
|
|
|
|
if (BN_num_bits(rsa->n) != (unsigned)bits) {
|
|
|
|
|
OPENSSL_PUT_ERROR(RSA, ERR_R_INTERNAL_ERROR);
|
2014-06-20 20:00:00 +01:00
|
|
|
|
goto err;
|
2015-02-11 06:17:41 +00:00
|
|
|
|
}
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
Make the rest of RSA CRT constant-time.
Alas, the existence of RSA keys with q > p is obnoxious, but we can
canonicalize it away. To my knowledge, the remaining leaks in RSA are:
- Key generation. This is kind of hopelessly non-constant-time but
perhaps deserves a more careful ponder. Though hopefully it does not
come in at a measurable point for practical purposes.
- Private key serialization. RSAPrivateKey inherently leaks the
magnitudes of d, dmp1, dmq1, and iqmp. This is unavoidable but
hopefully does not come in at a measurable point for practical
purposes.
- If p and q have different word widths, we currently fall back to the
variable-time BN_mod rather than Montgomery reduction at the start of
CRT. I can think of ways to apply Montgomery reduction, but it's
probably better to deny CRT to such keys, if not reject them outright.
- bn_mul_fixed and bn_sqr_fixed which affect the Montgomery
multiplication bn_mul_mont-less configurations, as well as the final
CRT multiplication. We should fix this.
Bug: 233
Change-Id: I8c2ecf8f8ec104e9f26299b66ac8cbb0cad04616
Reviewed-on: https://boringssl-review.googlesource.com/25263
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
2018-01-24 22:22:17 +00:00
|
|
|
|
// Call |freeze_private_key| to compute the inverse of q mod p, by way of
|
|
|
|
|
// |rsa->mont_p|.
|
|
|
|
|
if (!freeze_private_key(rsa, ctx)) {
|
2017-04-10 23:35:22 +01:00
|
|
|
|
goto bn_err;
|
2015-02-11 06:17:41 +00:00
|
|
|
|
}
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
2017-08-18 19:06:02 +01:00
|
|
|
|
// The key generation process is complex and thus error-prone. It could be
|
|
|
|
|
// disastrous to generate and then use a bad key so double-check that the key
|
|
|
|
|
// makes sense.
|
2017-04-10 23:35:22 +01:00
|
|
|
|
if (!RSA_check_key(rsa)) {
|
2016-03-21 23:47:32 +00:00
|
|
|
|
OPENSSL_PUT_ERROR(RSA, RSA_R_INTERNAL_ERROR);
|
2017-04-10 23:35:22 +01:00
|
|
|
|
goto err;
|
2016-03-21 23:47:32 +00:00
|
|
|
|
}
|
|
|
|
|
|
2017-04-10 23:35:22 +01:00
|
|
|
|
ret = 1;
|
|
|
|
|
|
|
|
|
|
bn_err:
|
|
|
|
|
if (!ret) {
|
2015-06-29 05:28:17 +01:00
|
|
|
|
OPENSSL_PUT_ERROR(RSA, ERR_LIB_BN);
|
2014-06-20 20:00:00 +01:00
|
|
|
|
}
|
2017-04-10 23:35:22 +01:00
|
|
|
|
err:
|
2014-06-20 20:00:00 +01:00
|
|
|
|
if (ctx != NULL) {
|
|
|
|
|
BN_CTX_end(ctx);
|
|
|
|
|
BN_CTX_free(ctx);
|
|
|
|
|
}
|
2017-04-10 23:35:22 +01:00
|
|
|
|
return ret;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
}
|
|
|
|
|
|
2018-04-10 23:35:16 +01:00
|
|
|
|
static void replace_bignum(BIGNUM **out, BIGNUM **in) {
|
|
|
|
|
BN_free(*out);
|
|
|
|
|
*out = *in;
|
|
|
|
|
*in = NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void replace_bn_mont_ctx(BN_MONT_CTX **out, BN_MONT_CTX **in) {
|
|
|
|
|
BN_MONT_CTX_free(*out);
|
|
|
|
|
*out = *in;
|
|
|
|
|
*in = NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int RSA_generate_key_ex(RSA *rsa, int bits, BIGNUM *e_value, BN_GENCB *cb) {
|
|
|
|
|
// |rsa_generate_key_impl|'s 2^-20 failure probability is too high at scale,
|
|
|
|
|
// so we run the FIPS algorithm four times, bringing it down to 2^-80. We
|
|
|
|
|
// should just adjust the retry limit, but FIPS 186-4 prescribes that value
|
|
|
|
|
// and thus results in unnecessary complexity.
|
|
|
|
|
for (int i = 0; i < 4; i++) {
|
|
|
|
|
ERR_clear_error();
|
|
|
|
|
// Generate into scratch space, to avoid leaving partial work on failure.
|
|
|
|
|
RSA *tmp = RSA_new();
|
|
|
|
|
if (tmp == NULL) {
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
if (rsa_generate_key_impl(tmp, bits, e_value, cb)) {
|
|
|
|
|
replace_bignum(&rsa->n, &tmp->n);
|
|
|
|
|
replace_bignum(&rsa->e, &tmp->e);
|
|
|
|
|
replace_bignum(&rsa->d, &tmp->d);
|
|
|
|
|
replace_bignum(&rsa->p, &tmp->p);
|
|
|
|
|
replace_bignum(&rsa->q, &tmp->q);
|
|
|
|
|
replace_bignum(&rsa->dmp1, &tmp->dmp1);
|
|
|
|
|
replace_bignum(&rsa->dmq1, &tmp->dmq1);
|
|
|
|
|
replace_bignum(&rsa->iqmp, &tmp->iqmp);
|
|
|
|
|
replace_bn_mont_ctx(&rsa->mont_n, &tmp->mont_n);
|
|
|
|
|
replace_bn_mont_ctx(&rsa->mont_p, &tmp->mont_p);
|
|
|
|
|
replace_bn_mont_ctx(&rsa->mont_q, &tmp->mont_q);
|
|
|
|
|
replace_bignum(&rsa->d_fixed, &tmp->d_fixed);
|
|
|
|
|
replace_bignum(&rsa->dmp1_fixed, &tmp->dmp1_fixed);
|
|
|
|
|
replace_bignum(&rsa->dmq1_fixed, &tmp->dmq1_fixed);
|
|
|
|
|
replace_bignum(&rsa->inv_small_mod_large_mont,
|
|
|
|
|
&tmp->inv_small_mod_large_mont);
|
|
|
|
|
rsa->private_key_frozen = tmp->private_key_frozen;
|
|
|
|
|
RSA_free(tmp);
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
uint32_t err = ERR_peek_error();
|
|
|
|
|
RSA_free(tmp);
|
|
|
|
|
tmp = NULL;
|
|
|
|
|
// Only retry on |RSA_R_TOO_MANY_ITERATIONS|. This is so a caller-induced
|
|
|
|
|
// failure in |BN_GENCB_call| is still fatal.
|
|
|
|
|
if (ERR_GET_LIB(err) != ERR_LIB_RSA ||
|
|
|
|
|
ERR_GET_REASON(err) != RSA_R_TOO_MANY_ITERATIONS) {
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2017-05-16 19:35:22 +01:00
|
|
|
|
int RSA_generate_key_fips(RSA *rsa, int bits, BN_GENCB *cb) {
|
2017-08-18 19:06:02 +01:00
|
|
|
|
// FIPS 186-4 allows 2048-bit and 3072-bit RSA keys (1024-bit and 1536-bit
|
|
|
|
|
// primes, respectively) with the prime generation method we use.
|
2017-05-16 19:35:22 +01:00
|
|
|
|
if (bits != 2048 && bits != 3072) {
|
|
|
|
|
OPENSSL_PUT_ERROR(RSA, RSA_R_BAD_RSA_PARAMETERS);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
BIGNUM *e = BN_new();
|
|
|
|
|
int ret = e != NULL &&
|
|
|
|
|
BN_set_word(e, RSA_F4) &&
|
|
|
|
|
RSA_generate_key_ex(rsa, bits, e, cb) &&
|
|
|
|
|
RSA_check_fips(rsa);
|
|
|
|
|
BN_free(e);
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
2017-05-03 19:50:51 +01:00
|
|
|
|
DEFINE_METHOD_FUNCTION(RSA_METHOD, RSA_default_method) {
|
2017-08-18 19:06:02 +01:00
|
|
|
|
// All of the methods are NULL to make it easier for the compiler/linker to
|
|
|
|
|
// drop unused functions. The wrapper functions will select the appropriate
|
|
|
|
|
// |rsa_default_*| implementation.
|
2017-05-03 19:50:51 +01:00
|
|
|
|
OPENSSL_memset(out, 0, sizeof(RSA_METHOD));
|
|
|
|
|
out->common.is_static = 1;
|
|
|
|
|
}
|