2014-06-20 20:00:00 +01:00
|
|
|
/* Written by Dr Stephen N Henson (steve@openssl.org) for the OpenSSL
|
|
|
|
* project 2006.
|
|
|
|
*/
|
|
|
|
/* ====================================================================
|
|
|
|
* Copyright (c) 2006 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/evp.h>
|
|
|
|
|
2015-08-07 17:34:57 +01:00
|
|
|
#include <openssl/bn.h>
|
2015-09-15 21:47:35 +01:00
|
|
|
#include <openssl/bytestring.h>
|
2014-06-20 20:00:00 +01:00
|
|
|
#include <openssl/digest.h>
|
|
|
|
#include <openssl/err.h>
|
|
|
|
#include <openssl/mem.h>
|
|
|
|
#include <openssl/rsa.h>
|
|
|
|
|
2017-05-03 19:50:51 +01:00
|
|
|
#include "../fipsmodule/rsa/internal.h"
|
2017-05-10 00:04:11 +01:00
|
|
|
#include "../internal.h"
|
2014-06-20 20:00:00 +01:00
|
|
|
#include "internal.h"
|
|
|
|
|
|
|
|
|
2017-05-10 00:04:11 +01:00
|
|
|
static struct CRYPTO_STATIC_MUTEX g_buggy_lock = CRYPTO_STATIC_MUTEX_INIT;
|
2017-09-18 20:26:06 +01:00
|
|
|
static int g_buggy = 0;
|
2017-05-10 00:04:11 +01:00
|
|
|
|
|
|
|
void EVP_set_buggy_rsa_parser(int buggy) {
|
|
|
|
CRYPTO_STATIC_MUTEX_lock_write(&g_buggy_lock);
|
|
|
|
g_buggy = buggy;
|
|
|
|
CRYPTO_STATIC_MUTEX_unlock_write(&g_buggy_lock);
|
|
|
|
}
|
|
|
|
|
Implement new SPKI parsers.
Many consumers need SPKI support (X.509, TLS, QUIC, WebCrypto), each
with different ways to set signature parameters. SPKIs themselves can
get complex with id-RSASSA-PSS keys which come with various constraints
in the key parameters. This suggests we want a common in-library
representation of an SPKI.
This adds two new functions EVP_parse_public_key and
EVP_marshal_public_key which converts EVP_PKEY to and from SPKI and
implements X509_PUBKEY functions with them. EVP_PKEY seems to have been
intended to be able to express the supported SPKI types with
full-fidelity, so these APIs will continue this.
This means future support for id-RSASSA-PSS would *not* repurpose
EVP_PKEY_RSA. I'm worried about code assuming EVP_PKEY_RSA implies
acting on the RSA* is legal. Instead, it'd add an EVP_PKEY_RSA_PSS and
the data pointer would be some (exposed, so the caller may still check
key size, etc.) RSA_PSS_KEY struct. Internally, the EVP_PKEY_CTX
implementation would enforce the key constraints. If RSA_PSS_KEY would
later need its own API, that code would move there, but that seems
unlikely.
Ideally we'd have a 1:1 correspondence with key OID, although we may
have to fudge things if mistakes happen in standardization. (Whether or
not X.509 reuses id-ecPublicKey for Ed25519, we'll give it a separate
EVP_PKEY type.)
DSA parsing hooks are still implemented, missing parameters and all for
now. This isn't any worse than before.
Decoupling from the giant crypto/obj OID table will be a later task.
BUG=522228
Change-Id: I0e3964edf20cb795a18b0991d17e5ca8bce3e28c
Reviewed-on: https://boringssl-review.googlesource.com/6861
Reviewed-by: Adam Langley <agl@google.com>
2015-12-31 02:40:40 +00:00
|
|
|
static int rsa_pub_encode(CBB *out, const EVP_PKEY *key) {
|
2017-08-18 19:06:02 +01:00
|
|
|
// See RFC 3279, section 2.3.1.
|
2016-03-25 22:07:16 +00:00
|
|
|
CBB spki, algorithm, oid, null, key_bitstring;
|
Implement new SPKI parsers.
Many consumers need SPKI support (X.509, TLS, QUIC, WebCrypto), each
with different ways to set signature parameters. SPKIs themselves can
get complex with id-RSASSA-PSS keys which come with various constraints
in the key parameters. This suggests we want a common in-library
representation of an SPKI.
This adds two new functions EVP_parse_public_key and
EVP_marshal_public_key which converts EVP_PKEY to and from SPKI and
implements X509_PUBKEY functions with them. EVP_PKEY seems to have been
intended to be able to express the supported SPKI types with
full-fidelity, so these APIs will continue this.
This means future support for id-RSASSA-PSS would *not* repurpose
EVP_PKEY_RSA. I'm worried about code assuming EVP_PKEY_RSA implies
acting on the RSA* is legal. Instead, it'd add an EVP_PKEY_RSA_PSS and
the data pointer would be some (exposed, so the caller may still check
key size, etc.) RSA_PSS_KEY struct. Internally, the EVP_PKEY_CTX
implementation would enforce the key constraints. If RSA_PSS_KEY would
later need its own API, that code would move there, but that seems
unlikely.
Ideally we'd have a 1:1 correspondence with key OID, although we may
have to fudge things if mistakes happen in standardization. (Whether or
not X.509 reuses id-ecPublicKey for Ed25519, we'll give it a separate
EVP_PKEY type.)
DSA parsing hooks are still implemented, missing parameters and all for
now. This isn't any worse than before.
Decoupling from the giant crypto/obj OID table will be a later task.
BUG=522228
Change-Id: I0e3964edf20cb795a18b0991d17e5ca8bce3e28c
Reviewed-on: https://boringssl-review.googlesource.com/6861
Reviewed-by: Adam Langley <agl@google.com>
2015-12-31 02:40:40 +00:00
|
|
|
if (!CBB_add_asn1(out, &spki, CBS_ASN1_SEQUENCE) ||
|
|
|
|
!CBB_add_asn1(&spki, &algorithm, CBS_ASN1_SEQUENCE) ||
|
2016-03-25 22:07:16 +00:00
|
|
|
!CBB_add_asn1(&algorithm, &oid, CBS_ASN1_OBJECT) ||
|
|
|
|
!CBB_add_bytes(&oid, rsa_asn1_meth.oid, rsa_asn1_meth.oid_len) ||
|
Implement new SPKI parsers.
Many consumers need SPKI support (X.509, TLS, QUIC, WebCrypto), each
with different ways to set signature parameters. SPKIs themselves can
get complex with id-RSASSA-PSS keys which come with various constraints
in the key parameters. This suggests we want a common in-library
representation of an SPKI.
This adds two new functions EVP_parse_public_key and
EVP_marshal_public_key which converts EVP_PKEY to and from SPKI and
implements X509_PUBKEY functions with them. EVP_PKEY seems to have been
intended to be able to express the supported SPKI types with
full-fidelity, so these APIs will continue this.
This means future support for id-RSASSA-PSS would *not* repurpose
EVP_PKEY_RSA. I'm worried about code assuming EVP_PKEY_RSA implies
acting on the RSA* is legal. Instead, it'd add an EVP_PKEY_RSA_PSS and
the data pointer would be some (exposed, so the caller may still check
key size, etc.) RSA_PSS_KEY struct. Internally, the EVP_PKEY_CTX
implementation would enforce the key constraints. If RSA_PSS_KEY would
later need its own API, that code would move there, but that seems
unlikely.
Ideally we'd have a 1:1 correspondence with key OID, although we may
have to fudge things if mistakes happen in standardization. (Whether or
not X.509 reuses id-ecPublicKey for Ed25519, we'll give it a separate
EVP_PKEY type.)
DSA parsing hooks are still implemented, missing parameters and all for
now. This isn't any worse than before.
Decoupling from the giant crypto/obj OID table will be a later task.
BUG=522228
Change-Id: I0e3964edf20cb795a18b0991d17e5ca8bce3e28c
Reviewed-on: https://boringssl-review.googlesource.com/6861
Reviewed-by: Adam Langley <agl@google.com>
2015-12-31 02:40:40 +00:00
|
|
|
!CBB_add_asn1(&algorithm, &null, CBS_ASN1_NULL) ||
|
|
|
|
!CBB_add_asn1(&spki, &key_bitstring, CBS_ASN1_BITSTRING) ||
|
|
|
|
!CBB_add_u8(&key_bitstring, 0 /* padding */) ||
|
|
|
|
!RSA_marshal_public_key(&key_bitstring, key->pkey.rsa) ||
|
|
|
|
!CBB_flush(out)) {
|
|
|
|
OPENSSL_PUT_ERROR(EVP, EVP_R_ENCODE_ERROR);
|
2014-06-20 20:00:00 +01:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
Implement new SPKI parsers.
Many consumers need SPKI support (X.509, TLS, QUIC, WebCrypto), each
with different ways to set signature parameters. SPKIs themselves can
get complex with id-RSASSA-PSS keys which come with various constraints
in the key parameters. This suggests we want a common in-library
representation of an SPKI.
This adds two new functions EVP_parse_public_key and
EVP_marshal_public_key which converts EVP_PKEY to and from SPKI and
implements X509_PUBKEY functions with them. EVP_PKEY seems to have been
intended to be able to express the supported SPKI types with
full-fidelity, so these APIs will continue this.
This means future support for id-RSASSA-PSS would *not* repurpose
EVP_PKEY_RSA. I'm worried about code assuming EVP_PKEY_RSA implies
acting on the RSA* is legal. Instead, it'd add an EVP_PKEY_RSA_PSS and
the data pointer would be some (exposed, so the caller may still check
key size, etc.) RSA_PSS_KEY struct. Internally, the EVP_PKEY_CTX
implementation would enforce the key constraints. If RSA_PSS_KEY would
later need its own API, that code would move there, but that seems
unlikely.
Ideally we'd have a 1:1 correspondence with key OID, although we may
have to fudge things if mistakes happen in standardization. (Whether or
not X.509 reuses id-ecPublicKey for Ed25519, we'll give it a separate
EVP_PKEY type.)
DSA parsing hooks are still implemented, missing parameters and all for
now. This isn't any worse than before.
Decoupling from the giant crypto/obj OID table will be a later task.
BUG=522228
Change-Id: I0e3964edf20cb795a18b0991d17e5ca8bce3e28c
Reviewed-on: https://boringssl-review.googlesource.com/6861
Reviewed-by: Adam Langley <agl@google.com>
2015-12-31 02:40:40 +00:00
|
|
|
static int rsa_pub_decode(EVP_PKEY *out, CBS *params, CBS *key) {
|
2017-05-10 00:04:11 +01:00
|
|
|
int buggy;
|
|
|
|
CRYPTO_STATIC_MUTEX_lock_read(&g_buggy_lock);
|
|
|
|
buggy = g_buggy;
|
|
|
|
CRYPTO_STATIC_MUTEX_unlock_read(&g_buggy_lock);
|
|
|
|
|
2017-08-18 19:06:02 +01:00
|
|
|
// See RFC 3279, section 2.3.1.
|
Implement new SPKI parsers.
Many consumers need SPKI support (X.509, TLS, QUIC, WebCrypto), each
with different ways to set signature parameters. SPKIs themselves can
get complex with id-RSASSA-PSS keys which come with various constraints
in the key parameters. This suggests we want a common in-library
representation of an SPKI.
This adds two new functions EVP_parse_public_key and
EVP_marshal_public_key which converts EVP_PKEY to and from SPKI and
implements X509_PUBKEY functions with them. EVP_PKEY seems to have been
intended to be able to express the supported SPKI types with
full-fidelity, so these APIs will continue this.
This means future support for id-RSASSA-PSS would *not* repurpose
EVP_PKEY_RSA. I'm worried about code assuming EVP_PKEY_RSA implies
acting on the RSA* is legal. Instead, it'd add an EVP_PKEY_RSA_PSS and
the data pointer would be some (exposed, so the caller may still check
key size, etc.) RSA_PSS_KEY struct. Internally, the EVP_PKEY_CTX
implementation would enforce the key constraints. If RSA_PSS_KEY would
later need its own API, that code would move there, but that seems
unlikely.
Ideally we'd have a 1:1 correspondence with key OID, although we may
have to fudge things if mistakes happen in standardization. (Whether or
not X.509 reuses id-ecPublicKey for Ed25519, we'll give it a separate
EVP_PKEY type.)
DSA parsing hooks are still implemented, missing parameters and all for
now. This isn't any worse than before.
Decoupling from the giant crypto/obj OID table will be a later task.
BUG=522228
Change-Id: I0e3964edf20cb795a18b0991d17e5ca8bce3e28c
Reviewed-on: https://boringssl-review.googlesource.com/6861
Reviewed-by: Adam Langley <agl@google.com>
2015-12-31 02:40:40 +00:00
|
|
|
|
2017-08-18 19:06:02 +01:00
|
|
|
// The parameters must be NULL.
|
Implement new SPKI parsers.
Many consumers need SPKI support (X.509, TLS, QUIC, WebCrypto), each
with different ways to set signature parameters. SPKIs themselves can
get complex with id-RSASSA-PSS keys which come with various constraints
in the key parameters. This suggests we want a common in-library
representation of an SPKI.
This adds two new functions EVP_parse_public_key and
EVP_marshal_public_key which converts EVP_PKEY to and from SPKI and
implements X509_PUBKEY functions with them. EVP_PKEY seems to have been
intended to be able to express the supported SPKI types with
full-fidelity, so these APIs will continue this.
This means future support for id-RSASSA-PSS would *not* repurpose
EVP_PKEY_RSA. I'm worried about code assuming EVP_PKEY_RSA implies
acting on the RSA* is legal. Instead, it'd add an EVP_PKEY_RSA_PSS and
the data pointer would be some (exposed, so the caller may still check
key size, etc.) RSA_PSS_KEY struct. Internally, the EVP_PKEY_CTX
implementation would enforce the key constraints. If RSA_PSS_KEY would
later need its own API, that code would move there, but that seems
unlikely.
Ideally we'd have a 1:1 correspondence with key OID, although we may
have to fudge things if mistakes happen in standardization. (Whether or
not X.509 reuses id-ecPublicKey for Ed25519, we'll give it a separate
EVP_PKEY type.)
DSA parsing hooks are still implemented, missing parameters and all for
now. This isn't any worse than before.
Decoupling from the giant crypto/obj OID table will be a later task.
BUG=522228
Change-Id: I0e3964edf20cb795a18b0991d17e5ca8bce3e28c
Reviewed-on: https://boringssl-review.googlesource.com/6861
Reviewed-by: Adam Langley <agl@google.com>
2015-12-31 02:40:40 +00:00
|
|
|
CBS null;
|
|
|
|
if (!CBS_get_asn1(params, &null, CBS_ASN1_NULL) ||
|
|
|
|
CBS_len(&null) != 0 ||
|
|
|
|
CBS_len(params) != 0) {
|
|
|
|
OPENSSL_PUT_ERROR(EVP, EVP_R_DECODE_ERROR);
|
2014-06-20 20:00:00 +01:00
|
|
|
return 0;
|
|
|
|
}
|
2015-09-15 21:47:35 +01:00
|
|
|
|
2017-08-18 19:06:02 +01:00
|
|
|
// Estonian IDs issued between September 2014 to September 2015 are
|
|
|
|
// broken. See https://crbug.com/532048 and https://crbug.com/534766.
|
|
|
|
//
|
|
|
|
// TODO(davidben): Switch this to the strict version in March 2016 or when
|
|
|
|
// Chromium can force client certificates down a different codepath, whichever
|
|
|
|
// comes first.
|
2017-05-10 00:04:11 +01:00
|
|
|
RSA *rsa = buggy ? RSA_parse_public_key_buggy(key) : RSA_parse_public_key(key);
|
Implement new SPKI parsers.
Many consumers need SPKI support (X.509, TLS, QUIC, WebCrypto), each
with different ways to set signature parameters. SPKIs themselves can
get complex with id-RSASSA-PSS keys which come with various constraints
in the key parameters. This suggests we want a common in-library
representation of an SPKI.
This adds two new functions EVP_parse_public_key and
EVP_marshal_public_key which converts EVP_PKEY to and from SPKI and
implements X509_PUBKEY functions with them. EVP_PKEY seems to have been
intended to be able to express the supported SPKI types with
full-fidelity, so these APIs will continue this.
This means future support for id-RSASSA-PSS would *not* repurpose
EVP_PKEY_RSA. I'm worried about code assuming EVP_PKEY_RSA implies
acting on the RSA* is legal. Instead, it'd add an EVP_PKEY_RSA_PSS and
the data pointer would be some (exposed, so the caller may still check
key size, etc.) RSA_PSS_KEY struct. Internally, the EVP_PKEY_CTX
implementation would enforce the key constraints. If RSA_PSS_KEY would
later need its own API, that code would move there, but that seems
unlikely.
Ideally we'd have a 1:1 correspondence with key OID, although we may
have to fudge things if mistakes happen in standardization. (Whether or
not X.509 reuses id-ecPublicKey for Ed25519, we'll give it a separate
EVP_PKEY type.)
DSA parsing hooks are still implemented, missing parameters and all for
now. This isn't any worse than before.
Decoupling from the giant crypto/obj OID table will be a later task.
BUG=522228
Change-Id: I0e3964edf20cb795a18b0991d17e5ca8bce3e28c
Reviewed-on: https://boringssl-review.googlesource.com/6861
Reviewed-by: Adam Langley <agl@google.com>
2015-12-31 02:40:40 +00:00
|
|
|
if (rsa == NULL || CBS_len(key) != 0) {
|
2015-09-15 21:47:35 +01:00
|
|
|
OPENSSL_PUT_ERROR(EVP, EVP_R_DECODE_ERROR);
|
|
|
|
RSA_free(rsa);
|
2014-06-20 20:00:00 +01:00
|
|
|
return 0;
|
|
|
|
}
|
2015-09-15 21:47:35 +01:00
|
|
|
|
Implement new SPKI parsers.
Many consumers need SPKI support (X.509, TLS, QUIC, WebCrypto), each
with different ways to set signature parameters. SPKIs themselves can
get complex with id-RSASSA-PSS keys which come with various constraints
in the key parameters. This suggests we want a common in-library
representation of an SPKI.
This adds two new functions EVP_parse_public_key and
EVP_marshal_public_key which converts EVP_PKEY to and from SPKI and
implements X509_PUBKEY functions with them. EVP_PKEY seems to have been
intended to be able to express the supported SPKI types with
full-fidelity, so these APIs will continue this.
This means future support for id-RSASSA-PSS would *not* repurpose
EVP_PKEY_RSA. I'm worried about code assuming EVP_PKEY_RSA implies
acting on the RSA* is legal. Instead, it'd add an EVP_PKEY_RSA_PSS and
the data pointer would be some (exposed, so the caller may still check
key size, etc.) RSA_PSS_KEY struct. Internally, the EVP_PKEY_CTX
implementation would enforce the key constraints. If RSA_PSS_KEY would
later need its own API, that code would move there, but that seems
unlikely.
Ideally we'd have a 1:1 correspondence with key OID, although we may
have to fudge things if mistakes happen in standardization. (Whether or
not X.509 reuses id-ecPublicKey for Ed25519, we'll give it a separate
EVP_PKEY type.)
DSA parsing hooks are still implemented, missing parameters and all for
now. This isn't any worse than before.
Decoupling from the giant crypto/obj OID table will be a later task.
BUG=522228
Change-Id: I0e3964edf20cb795a18b0991d17e5ca8bce3e28c
Reviewed-on: https://boringssl-review.googlesource.com/6861
Reviewed-by: Adam Langley <agl@google.com>
2015-12-31 02:40:40 +00:00
|
|
|
EVP_PKEY_assign_RSA(out, rsa);
|
2014-06-20 20:00:00 +01:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int rsa_pub_cmp(const EVP_PKEY *a, const EVP_PKEY *b) {
|
|
|
|
return BN_cmp(b->pkey.rsa->n, a->pkey.rsa->n) == 0 &&
|
|
|
|
BN_cmp(b->pkey.rsa->e, a->pkey.rsa->e) == 0;
|
|
|
|
}
|
|
|
|
|
2016-01-01 06:17:30 +00:00
|
|
|
static int rsa_priv_encode(CBB *out, const EVP_PKEY *key) {
|
2016-03-25 22:07:16 +00:00
|
|
|
CBB pkcs8, algorithm, oid, null, private_key;
|
2016-01-01 06:17:30 +00:00
|
|
|
if (!CBB_add_asn1(out, &pkcs8, CBS_ASN1_SEQUENCE) ||
|
|
|
|
!CBB_add_asn1_uint64(&pkcs8, 0 /* version */) ||
|
|
|
|
!CBB_add_asn1(&pkcs8, &algorithm, CBS_ASN1_SEQUENCE) ||
|
2016-03-25 22:07:16 +00:00
|
|
|
!CBB_add_asn1(&algorithm, &oid, CBS_ASN1_OBJECT) ||
|
|
|
|
!CBB_add_bytes(&oid, rsa_asn1_meth.oid, rsa_asn1_meth.oid_len) ||
|
2016-01-01 06:17:30 +00:00
|
|
|
!CBB_add_asn1(&algorithm, &null, CBS_ASN1_NULL) ||
|
|
|
|
!CBB_add_asn1(&pkcs8, &private_key, CBS_ASN1_OCTETSTRING) ||
|
|
|
|
!RSA_marshal_private_key(&private_key, key->pkey.rsa) ||
|
|
|
|
!CBB_flush(out)) {
|
|
|
|
OPENSSL_PUT_ERROR(EVP, EVP_R_ENCODE_ERROR);
|
2014-06-20 20:00:00 +01:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2016-01-01 06:17:30 +00:00
|
|
|
static int rsa_priv_decode(EVP_PKEY *out, CBS *params, CBS *key) {
|
2017-08-18 19:06:02 +01:00
|
|
|
// Per RFC 3447, A.1, the parameters have type NULL.
|
2016-01-01 06:17:30 +00:00
|
|
|
CBS null;
|
|
|
|
if (!CBS_get_asn1(params, &null, CBS_ASN1_NULL) ||
|
|
|
|
CBS_len(&null) != 0 ||
|
|
|
|
CBS_len(params) != 0) {
|
|
|
|
OPENSSL_PUT_ERROR(EVP, EVP_R_DECODE_ERROR);
|
2014-06-20 20:00:00 +01:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-01-01 06:17:30 +00:00
|
|
|
RSA *rsa = RSA_parse_private_key(key);
|
|
|
|
if (rsa == NULL || CBS_len(key) != 0) {
|
|
|
|
OPENSSL_PUT_ERROR(EVP, EVP_R_DECODE_ERROR);
|
|
|
|
RSA_free(rsa);
|
2014-06-20 20:00:00 +01:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-01-01 06:17:30 +00:00
|
|
|
EVP_PKEY_assign_RSA(out, rsa);
|
2014-06-20 20:00:00 +01:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2014-07-18 23:39:42 +01:00
|
|
|
static int rsa_opaque(const EVP_PKEY *pkey) {
|
|
|
|
return RSA_is_opaque(pkey->pkey.rsa);
|
|
|
|
}
|
|
|
|
|
2014-06-20 20:00:00 +01:00
|
|
|
static int int_rsa_size(const EVP_PKEY *pkey) {
|
|
|
|
return RSA_size(pkey->pkey.rsa);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int rsa_bits(const EVP_PKEY *pkey) {
|
|
|
|
return BN_num_bits(pkey->pkey.rsa->n);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void int_rsa_free(EVP_PKEY *pkey) { RSA_free(pkey->pkey.rsa); }
|
|
|
|
|
|
|
|
const EVP_PKEY_ASN1_METHOD rsa_asn1_meth = {
|
|
|
|
EVP_PKEY_RSA,
|
2017-08-18 19:06:02 +01:00
|
|
|
// 1.2.840.113549.1.1.1
|
2016-03-25 22:07:16 +00:00
|
|
|
{0x2a, 0x86, 0x48, 0x86, 0xf7, 0x0d, 0x01, 0x01, 0x01}, 9,
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
|
|
rsa_pub_decode,
|
|
|
|
rsa_pub_encode,
|
|
|
|
rsa_pub_cmp,
|
|
|
|
|
|
|
|
rsa_priv_decode,
|
|
|
|
rsa_priv_encode,
|
|
|
|
|
2014-07-18 23:39:42 +01:00
|
|
|
rsa_opaque,
|
|
|
|
|
2014-06-20 20:00:00 +01:00
|
|
|
int_rsa_size,
|
|
|
|
rsa_bits,
|
|
|
|
|
2015-08-07 17:34:57 +01:00
|
|
|
0,0,0,
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
|
|
int_rsa_free,
|
|
|
|
};
|