Mirror of BoringSSL (grpc依赖) https://boringssl.googlesource.com/boringssl
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

391 lines
10 KiB

/* Written by Dr Stephen N Henson (steve@openssl.org) for the OpenSSL
* project 2000. */
/* ====================================================================
* Copyright (c) 2000-2005 The OpenSSL Project. All rights reserved.
*
* 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 above 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 acknowledgment:
* "This product includes software developed by the OpenSSL Project
* for use in the OpenSSL Toolkit. (http://www.OpenSSL.org/)"
*
* 4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to
* endorse or promote products derived from this software without
* prior written permission. For written permission, please contact
* licensing@OpenSSL.org.
*
* 5. Products derived from this software may not be called "OpenSSL"
* nor may "OpenSSL" appear in their names without prior written
* permission of the OpenSSL Project.
*
* 6. Redistributions of any form whatsoever must retain the following
* acknowledgment:
* "This product includes software developed by the OpenSSL Project
* for use in the OpenSSL Toolkit (http://www.OpenSSL.org/)"
*
* THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY
* EXPRESSED 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 OpenSSL PROJECT OR
* ITS 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.
* ====================================================================
*
* This product includes cryptographic software written by Eric Young
* (eay@cryptsoft.com). This product includes software written by Tim
* Hudson (tjh@cryptsoft.com). */
#include <openssl/dsa.h>
#include <assert.h>
#include <openssl/bn.h>
#include <openssl/bytestring.h>
#include <openssl/err.h>
#include <openssl/mem.h>
Bound RSA and DSA key sizes better. Most asymmetric operations scale superlinearly, which makes them potential DoS vectors. This (and other problems) are mitigated with fixed sizes, like RSA-2048, P-256, or curve25519. In older algorithms like RSA and DSA, these sizes are conventions rather than well-defined algorithms. "Everyone" uses RSA-2048, but code which imports an RSA key may see an arbitrary key size, possibly from an untrusted source. This is commonly a public key, so we bound RSA key sizes in check_modulus_and_exponent_sizes. However, some applications import external private keys, and may need tighter bounds. These typically parse the key then check the result. However, parsing itself can perform superlinear work (RSA_check_key or recovering the DSA public key). This CL does the following: - Rename check_modulus_and_exponent_sizes to rsa_check_public_key and additionally call it from RSA_check_key. - Fix a bug where RSA_check_key, on CRT-less keys, did not bound d, and bound p and q before multiplying (quadratic). - Our DSA verifier had stricter checks on q (160-, 224-, and 256-bit only) than our DSA signer (multiple of 8 bits). Aligner the signer to the verifier's checks. - Validate DSA group sizes on parse, as well as priv_key < q, to bound the running time. Ideally these invariants would be checked exactly once at construction, but our RSA and DSA implementations suffer from some OpenSSL's API mistakes (https://crbug.com/boringssl/316), which means it is hard to consistently enforce invariants. This CL focuses on the parser, but later I'd like to better rationalize the freeze_private_key logic. Performance of parsing RSA and DSA keys, gathered on my laptop. Did 15130 RSA-2048 parse operations in 5022458us (3012.5 ops/sec) Did 4888 RSA-4096 parse operations in 5060606us (965.9 ops/sec) Did 354 RSA-16384 parse operations in 5043565us (70.2 ops/sec) Did 88 RSA-32768 parse operations in 5038293us (17.5 ops/sec) [rejected by this CL] Did 35000 DSA-1024/256 parse operations in 5030447us (6957.6 ops/sec) Did 11316 DSA-2048/256 parse operations in 5094664us (2221.1 ops/sec) Did 5488 DSA-3072/256 parse operations in 5096032us (1076.9 ops/sec) Did 3172 DSA-4096/256 parse operations in 5041220us (629.2 ops/sec) Did 840 DSA-8192/256 parse operations in 5070616us (165.7 ops/sec) Did 285 DSA-10000/256 parse operations in 5004033us (57.0 ops/sec) Did 74 DSA-20000/256 parse operations in 5066299us (14.6 ops/sec) [rejected by this CL] Update-Note: Some invalid or overly large RSA and DSA keys may previously have been accepted that are now rejected at parse time. For public keys, this only moves the error from verification to parsing. In some private key cases, we would previously allow signing with those keys, but the resulting signatures would not be accepted by BoringSSL anyway. This CL makes us behave more consistently. Bug: oss-fuzz:24730 Change-Id: I4ad2003ee61138b693e65d3da4c6aa00bc165251 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42504 Reviewed-by: Adam Langley <agl@google.com>
5 years ago
#include "internal.h"
#include "../bytestring/internal.h"
Bound RSA and DSA key sizes better. Most asymmetric operations scale superlinearly, which makes them potential DoS vectors. This (and other problems) are mitigated with fixed sizes, like RSA-2048, P-256, or curve25519. In older algorithms like RSA and DSA, these sizes are conventions rather than well-defined algorithms. "Everyone" uses RSA-2048, but code which imports an RSA key may see an arbitrary key size, possibly from an untrusted source. This is commonly a public key, so we bound RSA key sizes in check_modulus_and_exponent_sizes. However, some applications import external private keys, and may need tighter bounds. These typically parse the key then check the result. However, parsing itself can perform superlinear work (RSA_check_key or recovering the DSA public key). This CL does the following: - Rename check_modulus_and_exponent_sizes to rsa_check_public_key and additionally call it from RSA_check_key. - Fix a bug where RSA_check_key, on CRT-less keys, did not bound d, and bound p and q before multiplying (quadratic). - Our DSA verifier had stricter checks on q (160-, 224-, and 256-bit only) than our DSA signer (multiple of 8 bits). Aligner the signer to the verifier's checks. - Validate DSA group sizes on parse, as well as priv_key < q, to bound the running time. Ideally these invariants would be checked exactly once at construction, but our RSA and DSA implementations suffer from some OpenSSL's API mistakes (https://crbug.com/boringssl/316), which means it is hard to consistently enforce invariants. This CL focuses on the parser, but later I'd like to better rationalize the freeze_private_key logic. Performance of parsing RSA and DSA keys, gathered on my laptop. Did 15130 RSA-2048 parse operations in 5022458us (3012.5 ops/sec) Did 4888 RSA-4096 parse operations in 5060606us (965.9 ops/sec) Did 354 RSA-16384 parse operations in 5043565us (70.2 ops/sec) Did 88 RSA-32768 parse operations in 5038293us (17.5 ops/sec) [rejected by this CL] Did 35000 DSA-1024/256 parse operations in 5030447us (6957.6 ops/sec) Did 11316 DSA-2048/256 parse operations in 5094664us (2221.1 ops/sec) Did 5488 DSA-3072/256 parse operations in 5096032us (1076.9 ops/sec) Did 3172 DSA-4096/256 parse operations in 5041220us (629.2 ops/sec) Did 840 DSA-8192/256 parse operations in 5070616us (165.7 ops/sec) Did 285 DSA-10000/256 parse operations in 5004033us (57.0 ops/sec) Did 74 DSA-20000/256 parse operations in 5066299us (14.6 ops/sec) [rejected by this CL] Update-Note: Some invalid or overly large RSA and DSA keys may previously have been accepted that are now rejected at parse time. For public keys, this only moves the error from verification to parsing. In some private key cases, we would previously allow signing with those keys, but the resulting signatures would not be accepted by BoringSSL anyway. This CL makes us behave more consistently. Bug: oss-fuzz:24730 Change-Id: I4ad2003ee61138b693e65d3da4c6aa00bc165251 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42504 Reviewed-by: Adam Langley <agl@google.com>
5 years ago
#define OPENSSL_DSA_MAX_MODULUS_BITS 10000
// This function is in dsa_asn1.c rather than dsa.c because it is reachable from
// |EVP_PKEY| parsers. This makes it easier for the static linker to drop most
// of the DSA implementation.
int dsa_check_parameters(const DSA *dsa) {
if (!dsa->p || !dsa->q || !dsa->g) {
OPENSSL_PUT_ERROR(DSA, DSA_R_MISSING_PARAMETERS);
return 0;
}
// Reject invalid parameters. In particular, signing will infinite loop if |g|
// is zero.
if (BN_is_zero(dsa->p) || BN_is_zero(dsa->q) || BN_is_zero(dsa->g)) {
OPENSSL_PUT_ERROR(DSA, DSA_R_INVALID_PARAMETERS);
return 0;
}
// FIPS 186-4 allows only three different sizes for q.
unsigned q_bits = BN_num_bits(dsa->q);
if (q_bits != 160 && q_bits != 224 && q_bits != 256) {
OPENSSL_PUT_ERROR(DSA, DSA_R_BAD_Q_VALUE);
return 0;
}
// Bound |dsa->p| to avoid a DoS vector. Note this limit is much larger than
// the one in FIPS 186-4, which only allows L = 1024, 2048, and 3072.
if (BN_num_bits(dsa->p) > OPENSSL_DSA_MAX_MODULUS_BITS) {
OPENSSL_PUT_ERROR(DSA, DSA_R_MODULUS_TOO_LARGE);
return 0;
}
return 1;
}
static int parse_integer(CBS *cbs, BIGNUM **out) {
assert(*out == NULL);
*out = BN_new();
if (*out == NULL) {
return 0;
}
return BN_parse_asn1_unsigned(cbs, *out);
}
static int marshal_integer(CBB *cbb, BIGNUM *bn) {
if (bn == NULL) {
// A DSA object may be missing some components.
OPENSSL_PUT_ERROR(DSA, ERR_R_PASSED_NULL_PARAMETER);
return 0;
}
return BN_marshal_asn1(cbb, bn);
}
DSA_SIG *DSA_SIG_parse(CBS *cbs) {
DSA_SIG *ret = DSA_SIG_new();
if (ret == NULL) {
return NULL;
}
CBS child;
if (!CBS_get_asn1(cbs, &child, CBS_ASN1_SEQUENCE) ||
!parse_integer(&child, &ret->r) ||
!parse_integer(&child, &ret->s) ||
CBS_len(&child) != 0) {
OPENSSL_PUT_ERROR(DSA, DSA_R_DECODE_ERROR);
DSA_SIG_free(ret);
return NULL;
}
return ret;
}
int DSA_SIG_marshal(CBB *cbb, const DSA_SIG *sig) {
CBB child;
if (!CBB_add_asn1(cbb, &child, CBS_ASN1_SEQUENCE) ||
!marshal_integer(&child, sig->r) ||
!marshal_integer(&child, sig->s) ||
!CBB_flush(cbb)) {
OPENSSL_PUT_ERROR(DSA, DSA_R_ENCODE_ERROR);
return 0;
}
return 1;
}
DSA *DSA_parse_public_key(CBS *cbs) {
DSA *ret = DSA_new();
if (ret == NULL) {
return NULL;
}
CBS child;
if (!CBS_get_asn1(cbs, &child, CBS_ASN1_SEQUENCE) ||
!parse_integer(&child, &ret->pub_key) ||
!parse_integer(&child, &ret->p) ||
!parse_integer(&child, &ret->q) ||
!parse_integer(&child, &ret->g) ||
CBS_len(&child) != 0) {
OPENSSL_PUT_ERROR(DSA, DSA_R_DECODE_ERROR);
Bound RSA and DSA key sizes better. Most asymmetric operations scale superlinearly, which makes them potential DoS vectors. This (and other problems) are mitigated with fixed sizes, like RSA-2048, P-256, or curve25519. In older algorithms like RSA and DSA, these sizes are conventions rather than well-defined algorithms. "Everyone" uses RSA-2048, but code which imports an RSA key may see an arbitrary key size, possibly from an untrusted source. This is commonly a public key, so we bound RSA key sizes in check_modulus_and_exponent_sizes. However, some applications import external private keys, and may need tighter bounds. These typically parse the key then check the result. However, parsing itself can perform superlinear work (RSA_check_key or recovering the DSA public key). This CL does the following: - Rename check_modulus_and_exponent_sizes to rsa_check_public_key and additionally call it from RSA_check_key. - Fix a bug where RSA_check_key, on CRT-less keys, did not bound d, and bound p and q before multiplying (quadratic). - Our DSA verifier had stricter checks on q (160-, 224-, and 256-bit only) than our DSA signer (multiple of 8 bits). Aligner the signer to the verifier's checks. - Validate DSA group sizes on parse, as well as priv_key < q, to bound the running time. Ideally these invariants would be checked exactly once at construction, but our RSA and DSA implementations suffer from some OpenSSL's API mistakes (https://crbug.com/boringssl/316), which means it is hard to consistently enforce invariants. This CL focuses on the parser, but later I'd like to better rationalize the freeze_private_key logic. Performance of parsing RSA and DSA keys, gathered on my laptop. Did 15130 RSA-2048 parse operations in 5022458us (3012.5 ops/sec) Did 4888 RSA-4096 parse operations in 5060606us (965.9 ops/sec) Did 354 RSA-16384 parse operations in 5043565us (70.2 ops/sec) Did 88 RSA-32768 parse operations in 5038293us (17.5 ops/sec) [rejected by this CL] Did 35000 DSA-1024/256 parse operations in 5030447us (6957.6 ops/sec) Did 11316 DSA-2048/256 parse operations in 5094664us (2221.1 ops/sec) Did 5488 DSA-3072/256 parse operations in 5096032us (1076.9 ops/sec) Did 3172 DSA-4096/256 parse operations in 5041220us (629.2 ops/sec) Did 840 DSA-8192/256 parse operations in 5070616us (165.7 ops/sec) Did 285 DSA-10000/256 parse operations in 5004033us (57.0 ops/sec) Did 74 DSA-20000/256 parse operations in 5066299us (14.6 ops/sec) [rejected by this CL] Update-Note: Some invalid or overly large RSA and DSA keys may previously have been accepted that are now rejected at parse time. For public keys, this only moves the error from verification to parsing. In some private key cases, we would previously allow signing with those keys, but the resulting signatures would not be accepted by BoringSSL anyway. This CL makes us behave more consistently. Bug: oss-fuzz:24730 Change-Id: I4ad2003ee61138b693e65d3da4c6aa00bc165251 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42504 Reviewed-by: Adam Langley <agl@google.com>
5 years ago
goto err;
}
if (!dsa_check_parameters(ret)) {
goto err;
}
return ret;
Bound RSA and DSA key sizes better. Most asymmetric operations scale superlinearly, which makes them potential DoS vectors. This (and other problems) are mitigated with fixed sizes, like RSA-2048, P-256, or curve25519. In older algorithms like RSA and DSA, these sizes are conventions rather than well-defined algorithms. "Everyone" uses RSA-2048, but code which imports an RSA key may see an arbitrary key size, possibly from an untrusted source. This is commonly a public key, so we bound RSA key sizes in check_modulus_and_exponent_sizes. However, some applications import external private keys, and may need tighter bounds. These typically parse the key then check the result. However, parsing itself can perform superlinear work (RSA_check_key or recovering the DSA public key). This CL does the following: - Rename check_modulus_and_exponent_sizes to rsa_check_public_key and additionally call it from RSA_check_key. - Fix a bug where RSA_check_key, on CRT-less keys, did not bound d, and bound p and q before multiplying (quadratic). - Our DSA verifier had stricter checks on q (160-, 224-, and 256-bit only) than our DSA signer (multiple of 8 bits). Aligner the signer to the verifier's checks. - Validate DSA group sizes on parse, as well as priv_key < q, to bound the running time. Ideally these invariants would be checked exactly once at construction, but our RSA and DSA implementations suffer from some OpenSSL's API mistakes (https://crbug.com/boringssl/316), which means it is hard to consistently enforce invariants. This CL focuses on the parser, but later I'd like to better rationalize the freeze_private_key logic. Performance of parsing RSA and DSA keys, gathered on my laptop. Did 15130 RSA-2048 parse operations in 5022458us (3012.5 ops/sec) Did 4888 RSA-4096 parse operations in 5060606us (965.9 ops/sec) Did 354 RSA-16384 parse operations in 5043565us (70.2 ops/sec) Did 88 RSA-32768 parse operations in 5038293us (17.5 ops/sec) [rejected by this CL] Did 35000 DSA-1024/256 parse operations in 5030447us (6957.6 ops/sec) Did 11316 DSA-2048/256 parse operations in 5094664us (2221.1 ops/sec) Did 5488 DSA-3072/256 parse operations in 5096032us (1076.9 ops/sec) Did 3172 DSA-4096/256 parse operations in 5041220us (629.2 ops/sec) Did 840 DSA-8192/256 parse operations in 5070616us (165.7 ops/sec) Did 285 DSA-10000/256 parse operations in 5004033us (57.0 ops/sec) Did 74 DSA-20000/256 parse operations in 5066299us (14.6 ops/sec) [rejected by this CL] Update-Note: Some invalid or overly large RSA and DSA keys may previously have been accepted that are now rejected at parse time. For public keys, this only moves the error from verification to parsing. In some private key cases, we would previously allow signing with those keys, but the resulting signatures would not be accepted by BoringSSL anyway. This CL makes us behave more consistently. Bug: oss-fuzz:24730 Change-Id: I4ad2003ee61138b693e65d3da4c6aa00bc165251 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42504 Reviewed-by: Adam Langley <agl@google.com>
5 years ago
err:
DSA_free(ret);
return NULL;
}
int DSA_marshal_public_key(CBB *cbb, const DSA *dsa) {
CBB child;
if (!CBB_add_asn1(cbb, &child, CBS_ASN1_SEQUENCE) ||
!marshal_integer(&child, dsa->pub_key) ||
!marshal_integer(&child, dsa->p) ||
!marshal_integer(&child, dsa->q) ||
!marshal_integer(&child, dsa->g) ||
!CBB_flush(cbb)) {
OPENSSL_PUT_ERROR(DSA, DSA_R_ENCODE_ERROR);
return 0;
}
return 1;
}
DSA *DSA_parse_parameters(CBS *cbs) {
DSA *ret = DSA_new();
if (ret == NULL) {
return NULL;
}
CBS child;
if (!CBS_get_asn1(cbs, &child, CBS_ASN1_SEQUENCE) ||
!parse_integer(&child, &ret->p) ||
!parse_integer(&child, &ret->q) ||
!parse_integer(&child, &ret->g) ||
CBS_len(&child) != 0) {
OPENSSL_PUT_ERROR(DSA, DSA_R_DECODE_ERROR);
Bound RSA and DSA key sizes better. Most asymmetric operations scale superlinearly, which makes them potential DoS vectors. This (and other problems) are mitigated with fixed sizes, like RSA-2048, P-256, or curve25519. In older algorithms like RSA and DSA, these sizes are conventions rather than well-defined algorithms. "Everyone" uses RSA-2048, but code which imports an RSA key may see an arbitrary key size, possibly from an untrusted source. This is commonly a public key, so we bound RSA key sizes in check_modulus_and_exponent_sizes. However, some applications import external private keys, and may need tighter bounds. These typically parse the key then check the result. However, parsing itself can perform superlinear work (RSA_check_key or recovering the DSA public key). This CL does the following: - Rename check_modulus_and_exponent_sizes to rsa_check_public_key and additionally call it from RSA_check_key. - Fix a bug where RSA_check_key, on CRT-less keys, did not bound d, and bound p and q before multiplying (quadratic). - Our DSA verifier had stricter checks on q (160-, 224-, and 256-bit only) than our DSA signer (multiple of 8 bits). Aligner the signer to the verifier's checks. - Validate DSA group sizes on parse, as well as priv_key < q, to bound the running time. Ideally these invariants would be checked exactly once at construction, but our RSA and DSA implementations suffer from some OpenSSL's API mistakes (https://crbug.com/boringssl/316), which means it is hard to consistently enforce invariants. This CL focuses on the parser, but later I'd like to better rationalize the freeze_private_key logic. Performance of parsing RSA and DSA keys, gathered on my laptop. Did 15130 RSA-2048 parse operations in 5022458us (3012.5 ops/sec) Did 4888 RSA-4096 parse operations in 5060606us (965.9 ops/sec) Did 354 RSA-16384 parse operations in 5043565us (70.2 ops/sec) Did 88 RSA-32768 parse operations in 5038293us (17.5 ops/sec) [rejected by this CL] Did 35000 DSA-1024/256 parse operations in 5030447us (6957.6 ops/sec) Did 11316 DSA-2048/256 parse operations in 5094664us (2221.1 ops/sec) Did 5488 DSA-3072/256 parse operations in 5096032us (1076.9 ops/sec) Did 3172 DSA-4096/256 parse operations in 5041220us (629.2 ops/sec) Did 840 DSA-8192/256 parse operations in 5070616us (165.7 ops/sec) Did 285 DSA-10000/256 parse operations in 5004033us (57.0 ops/sec) Did 74 DSA-20000/256 parse operations in 5066299us (14.6 ops/sec) [rejected by this CL] Update-Note: Some invalid or overly large RSA and DSA keys may previously have been accepted that are now rejected at parse time. For public keys, this only moves the error from verification to parsing. In some private key cases, we would previously allow signing with those keys, but the resulting signatures would not be accepted by BoringSSL anyway. This CL makes us behave more consistently. Bug: oss-fuzz:24730 Change-Id: I4ad2003ee61138b693e65d3da4c6aa00bc165251 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42504 Reviewed-by: Adam Langley <agl@google.com>
5 years ago
goto err;
}
if (!dsa_check_parameters(ret)) {
goto err;
}
return ret;
Bound RSA and DSA key sizes better. Most asymmetric operations scale superlinearly, which makes them potential DoS vectors. This (and other problems) are mitigated with fixed sizes, like RSA-2048, P-256, or curve25519. In older algorithms like RSA and DSA, these sizes are conventions rather than well-defined algorithms. "Everyone" uses RSA-2048, but code which imports an RSA key may see an arbitrary key size, possibly from an untrusted source. This is commonly a public key, so we bound RSA key sizes in check_modulus_and_exponent_sizes. However, some applications import external private keys, and may need tighter bounds. These typically parse the key then check the result. However, parsing itself can perform superlinear work (RSA_check_key or recovering the DSA public key). This CL does the following: - Rename check_modulus_and_exponent_sizes to rsa_check_public_key and additionally call it from RSA_check_key. - Fix a bug where RSA_check_key, on CRT-less keys, did not bound d, and bound p and q before multiplying (quadratic). - Our DSA verifier had stricter checks on q (160-, 224-, and 256-bit only) than our DSA signer (multiple of 8 bits). Aligner the signer to the verifier's checks. - Validate DSA group sizes on parse, as well as priv_key < q, to bound the running time. Ideally these invariants would be checked exactly once at construction, but our RSA and DSA implementations suffer from some OpenSSL's API mistakes (https://crbug.com/boringssl/316), which means it is hard to consistently enforce invariants. This CL focuses on the parser, but later I'd like to better rationalize the freeze_private_key logic. Performance of parsing RSA and DSA keys, gathered on my laptop. Did 15130 RSA-2048 parse operations in 5022458us (3012.5 ops/sec) Did 4888 RSA-4096 parse operations in 5060606us (965.9 ops/sec) Did 354 RSA-16384 parse operations in 5043565us (70.2 ops/sec) Did 88 RSA-32768 parse operations in 5038293us (17.5 ops/sec) [rejected by this CL] Did 35000 DSA-1024/256 parse operations in 5030447us (6957.6 ops/sec) Did 11316 DSA-2048/256 parse operations in 5094664us (2221.1 ops/sec) Did 5488 DSA-3072/256 parse operations in 5096032us (1076.9 ops/sec) Did 3172 DSA-4096/256 parse operations in 5041220us (629.2 ops/sec) Did 840 DSA-8192/256 parse operations in 5070616us (165.7 ops/sec) Did 285 DSA-10000/256 parse operations in 5004033us (57.0 ops/sec) Did 74 DSA-20000/256 parse operations in 5066299us (14.6 ops/sec) [rejected by this CL] Update-Note: Some invalid or overly large RSA and DSA keys may previously have been accepted that are now rejected at parse time. For public keys, this only moves the error from verification to parsing. In some private key cases, we would previously allow signing with those keys, but the resulting signatures would not be accepted by BoringSSL anyway. This CL makes us behave more consistently. Bug: oss-fuzz:24730 Change-Id: I4ad2003ee61138b693e65d3da4c6aa00bc165251 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42504 Reviewed-by: Adam Langley <agl@google.com>
5 years ago
err:
DSA_free(ret);
return NULL;
}
int DSA_marshal_parameters(CBB *cbb, const DSA *dsa) {
CBB child;
if (!CBB_add_asn1(cbb, &child, CBS_ASN1_SEQUENCE) ||
!marshal_integer(&child, dsa->p) ||
!marshal_integer(&child, dsa->q) ||
!marshal_integer(&child, dsa->g) ||
!CBB_flush(cbb)) {
OPENSSL_PUT_ERROR(DSA, DSA_R_ENCODE_ERROR);
return 0;
}
return 1;
}
DSA *DSA_parse_private_key(CBS *cbs) {
DSA *ret = DSA_new();
if (ret == NULL) {
return NULL;
}
CBS child;
uint64_t version;
if (!CBS_get_asn1(cbs, &child, CBS_ASN1_SEQUENCE) ||
!CBS_get_asn1_uint64(&child, &version)) {
OPENSSL_PUT_ERROR(DSA, DSA_R_DECODE_ERROR);
goto err;
}
if (version != 0) {
OPENSSL_PUT_ERROR(DSA, DSA_R_BAD_VERSION);
goto err;
}
if (!parse_integer(&child, &ret->p) ||
!parse_integer(&child, &ret->q) ||
!parse_integer(&child, &ret->g) ||
!parse_integer(&child, &ret->pub_key) ||
!parse_integer(&child, &ret->priv_key) ||
CBS_len(&child) != 0) {
OPENSSL_PUT_ERROR(DSA, DSA_R_DECODE_ERROR);
goto err;
}
Bound RSA and DSA key sizes better. Most asymmetric operations scale superlinearly, which makes them potential DoS vectors. This (and other problems) are mitigated with fixed sizes, like RSA-2048, P-256, or curve25519. In older algorithms like RSA and DSA, these sizes are conventions rather than well-defined algorithms. "Everyone" uses RSA-2048, but code which imports an RSA key may see an arbitrary key size, possibly from an untrusted source. This is commonly a public key, so we bound RSA key sizes in check_modulus_and_exponent_sizes. However, some applications import external private keys, and may need tighter bounds. These typically parse the key then check the result. However, parsing itself can perform superlinear work (RSA_check_key or recovering the DSA public key). This CL does the following: - Rename check_modulus_and_exponent_sizes to rsa_check_public_key and additionally call it from RSA_check_key. - Fix a bug where RSA_check_key, on CRT-less keys, did not bound d, and bound p and q before multiplying (quadratic). - Our DSA verifier had stricter checks on q (160-, 224-, and 256-bit only) than our DSA signer (multiple of 8 bits). Aligner the signer to the verifier's checks. - Validate DSA group sizes on parse, as well as priv_key < q, to bound the running time. Ideally these invariants would be checked exactly once at construction, but our RSA and DSA implementations suffer from some OpenSSL's API mistakes (https://crbug.com/boringssl/316), which means it is hard to consistently enforce invariants. This CL focuses on the parser, but later I'd like to better rationalize the freeze_private_key logic. Performance of parsing RSA and DSA keys, gathered on my laptop. Did 15130 RSA-2048 parse operations in 5022458us (3012.5 ops/sec) Did 4888 RSA-4096 parse operations in 5060606us (965.9 ops/sec) Did 354 RSA-16384 parse operations in 5043565us (70.2 ops/sec) Did 88 RSA-32768 parse operations in 5038293us (17.5 ops/sec) [rejected by this CL] Did 35000 DSA-1024/256 parse operations in 5030447us (6957.6 ops/sec) Did 11316 DSA-2048/256 parse operations in 5094664us (2221.1 ops/sec) Did 5488 DSA-3072/256 parse operations in 5096032us (1076.9 ops/sec) Did 3172 DSA-4096/256 parse operations in 5041220us (629.2 ops/sec) Did 840 DSA-8192/256 parse operations in 5070616us (165.7 ops/sec) Did 285 DSA-10000/256 parse operations in 5004033us (57.0 ops/sec) Did 74 DSA-20000/256 parse operations in 5066299us (14.6 ops/sec) [rejected by this CL] Update-Note: Some invalid or overly large RSA and DSA keys may previously have been accepted that are now rejected at parse time. For public keys, this only moves the error from verification to parsing. In some private key cases, we would previously allow signing with those keys, but the resulting signatures would not be accepted by BoringSSL anyway. This CL makes us behave more consistently. Bug: oss-fuzz:24730 Change-Id: I4ad2003ee61138b693e65d3da4c6aa00bc165251 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42504 Reviewed-by: Adam Langley <agl@google.com>
5 years ago
if (!dsa_check_parameters(ret)) {
goto err;
}
return ret;
err:
DSA_free(ret);
return NULL;
}
int DSA_marshal_private_key(CBB *cbb, const DSA *dsa) {
CBB child;
if (!CBB_add_asn1(cbb, &child, CBS_ASN1_SEQUENCE) ||
!CBB_add_asn1_uint64(&child, 0 /* version */) ||
!marshal_integer(&child, dsa->p) ||
!marshal_integer(&child, dsa->q) ||
!marshal_integer(&child, dsa->g) ||
!marshal_integer(&child, dsa->pub_key) ||
!marshal_integer(&child, dsa->priv_key) ||
!CBB_flush(cbb)) {
OPENSSL_PUT_ERROR(DSA, DSA_R_ENCODE_ERROR);
return 0;
}
return 1;
}
DSA_SIG *d2i_DSA_SIG(DSA_SIG **out_sig, const uint8_t **inp, long len) {
if (len < 0) {
return NULL;
}
CBS cbs;
CBS_init(&cbs, *inp, (size_t)len);
DSA_SIG *ret = DSA_SIG_parse(&cbs);
if (ret == NULL) {
return NULL;
}
if (out_sig != NULL) {
DSA_SIG_free(*out_sig);
*out_sig = ret;
}
*inp = CBS_data(&cbs);
return ret;
}
int i2d_DSA_SIG(const DSA_SIG *in, uint8_t **outp) {
CBB cbb;
if (!CBB_init(&cbb, 0) ||
!DSA_SIG_marshal(&cbb, in)) {
CBB_cleanup(&cbb);
return -1;
}
return CBB_finish_i2d(&cbb, outp);
}
DSA *d2i_DSAPublicKey(DSA **out, const uint8_t **inp, long len) {
if (len < 0) {
return NULL;
}
CBS cbs;
CBS_init(&cbs, *inp, (size_t)len);
DSA *ret = DSA_parse_public_key(&cbs);
if (ret == NULL) {
return NULL;
}
if (out != NULL) {
DSA_free(*out);
*out = ret;
}
*inp = CBS_data(&cbs);
return ret;
}
int i2d_DSAPublicKey(const DSA *in, uint8_t **outp) {
CBB cbb;
if (!CBB_init(&cbb, 0) ||
!DSA_marshal_public_key(&cbb, in)) {
CBB_cleanup(&cbb);
return -1;
}
return CBB_finish_i2d(&cbb, outp);
}
DSA *d2i_DSAPrivateKey(DSA **out, const uint8_t **inp, long len) {
if (len < 0) {
return NULL;
}
CBS cbs;
CBS_init(&cbs, *inp, (size_t)len);
DSA *ret = DSA_parse_private_key(&cbs);
if (ret == NULL) {
return NULL;
}
if (out != NULL) {
DSA_free(*out);
*out = ret;
}
*inp = CBS_data(&cbs);
return ret;
}
int i2d_DSAPrivateKey(const DSA *in, uint8_t **outp) {
CBB cbb;
if (!CBB_init(&cbb, 0) ||
!DSA_marshal_private_key(&cbb, in)) {
CBB_cleanup(&cbb);
return -1;
}
return CBB_finish_i2d(&cbb, outp);
}
DSA *d2i_DSAparams(DSA **out, const uint8_t **inp, long len) {
if (len < 0) {
return NULL;
}
CBS cbs;
CBS_init(&cbs, *inp, (size_t)len);
DSA *ret = DSA_parse_parameters(&cbs);
if (ret == NULL) {
return NULL;
}
if (out != NULL) {
DSA_free(*out);
*out = ret;
}
*inp = CBS_data(&cbs);
return ret;
}
int i2d_DSAparams(const DSA *in, uint8_t **outp) {
CBB cbb;
if (!CBB_init(&cbb, 0) ||
!DSA_marshal_parameters(&cbb, in)) {
CBB_cleanup(&cbb);
return -1;
}
return CBB_finish_i2d(&cbb, outp);
}