kris/boringssl
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
5fc99c6603
boringssl/crypto/evp/p_ec_asn1.c

258 lines
8.1 KiB
C
Raw Normal View History

Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
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>
#include <openssl/bn.h>
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
#include <openssl/bytestring.h>
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
#include <openssl/ec.h>
Implement new PKCS#8 parsers. As with SPKI parsers, the intent is make EVP_PKEY capture the key's constraints in full fidelity, so we'd have to add new types or store the information in the underlying key object if people introduce variant key types with weird constraints on them. Note that because PKCS#8 has a space for arbitrary attributes, this parser must admit a hole. I'm assuming for now that we don't need an API that enforces no attributes and just ignore trailing data in the structure for simplicity. BUG=499653 Change-Id: I6fc641355e87136c7220f5d7693566d1144a68e8 Reviewed-on: https://boringssl-review.googlesource.com/6866 Reviewed-by: Adam Langley <agl@google.com>
2016-01-01 06:17:30 +00:00
#include <openssl/ec_key.h>
#include <openssl/ecdsa.h>
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
#include <openssl/err.h>
#include "internal.h"
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 eckey_pub_encode(CBB *out, const EVP_PKEY *key) {
const EC_KEY *ec_key = key->pkey.ec;
const EC_GROUP *group = EC_KEY_get0_group(ec_key);
const EC_POINT *public_key = EC_KEY_get0_public_key(ec_key);
/* See RFC 5480, section 2. */
Decouple crypto/evp from the OID table. BUG=chromium:499653 Change-Id: I4e8d4af3129dbf61d4a8846ec9db685e83999d5e Reviewed-on: https://boringssl-review.googlesource.com/7565 Reviewed-by: Steven Valdez <svaldez@google.com> Reviewed-by: David Benjamin <davidben@google.com>
2016-03-25 22:07:16 +00:00
CBB spki, algorithm, oid, 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) ||
Decouple crypto/evp from the OID table. BUG=chromium:499653 Change-Id: I4e8d4af3129dbf61d4a8846ec9db685e83999d5e Reviewed-on: https://boringssl-review.googlesource.com/7565 Reviewed-by: Steven Valdez <svaldez@google.com> Reviewed-by: David Benjamin <davidben@google.com>
2016-03-25 22:07:16 +00:00
!CBB_add_asn1(&algorithm, &oid, CBS_ASN1_OBJECT) ||
!CBB_add_bytes(&oid, ec_asn1_meth.oid, ec_asn1_meth.oid_len) ||
Decouple crypto/ec from the OID table. Instead, embed the (very short) encoding of the OID into built_in_curve. BUG=chromium:499653 Change-Id: I0db36f83c71fbd3321831f54fa5022f8304b30cd Reviewed-on: https://boringssl-review.googlesource.com/7564 Reviewed-by: Steven Valdez <svaldez@google.com> Reviewed-by: David Benjamin <davidben@google.com>
2016-03-25 22:07:15 +00:00
!EC_KEY_marshal_curve_name(&algorithm, group) ||
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(&spki, &key_bitstring, CBS_ASN1_BITSTRING) ||
!CBB_add_u8(&key_bitstring, 0 /* padding */) ||
!EC_POINT_point2cbb(&key_bitstring, group, public_key,
POINT_CONVERSION_UNCOMPRESSED, NULL) ||
!CBB_flush(out)) {
OPENSSL_PUT_ERROR(EVP, EVP_R_ENCODE_ERROR);
return 0;
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +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
return 1;
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +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
static int eckey_pub_decode(EVP_PKEY *out, CBS *params, CBS *key) {
/* See RFC 5480, section 2. */
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +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
/* The parameters are a named curve. */
Fix memory leak on invalid ecPublicKey parameters. One of the codepaths didn't free the group. Found by libFuzzer. BUG=chromium:603893 Change-Id: Icb81f2f89a8c1a52e29069321498986b193a0e56 Reviewed-on: https://boringssl-review.googlesource.com/7685 Reviewed-by: Steven Valdez <svaldez@google.com> Reviewed-by: Adam Langley <agl@google.com>
2016-04-15 20:34:30 +01:00
EC_POINT *point = NULL;
EC_KEY *eckey = NULL;
Decouple crypto/ec from the OID table. Instead, embed the (very short) encoding of the OID into built_in_curve. BUG=chromium:499653 Change-Id: I0db36f83c71fbd3321831f54fa5022f8304b30cd Reviewed-on: https://boringssl-review.googlesource.com/7564 Reviewed-by: Steven Valdez <svaldez@google.com> Reviewed-by: David Benjamin <davidben@google.com>
2016-03-25 22:07:15 +00:00
EC_GROUP *group = EC_KEY_parse_curve_name(params);
if (group == NULL || CBS_len(params) != 0) {
Don't allow the specifiedCurve form of ECParameters in SPKIs. Although RFC 3279 allows both, per RFC 5912, keys must use a named curve rather than spelling out the curve parameters. Although we do not allow arbitrary curves, we do have to (pretty hackishly) recognize built-in curves in ECPrivateKeys. It seems the cause of this was that OpenSSL, unless you set asn1_flag on the EC_GROUP, likes to encode keys by spelling out the parameters. This is in violation of RFC 5915, though probably not in violation of one of the other redundant ECC specifications. For more fun, it appears asn1_flag defaults to *off* in the API and *on* in the command-line tools. I think the original cause was these defaults meant the pre-BoringSSL Android/OpenSSL Chromium port wrote out Channel ID keys in this format. By now this should no longer by an issue, but it'll warrant a bit more investigation to be sure we can drop it. For now, keep this logic out of SPKIs by not calling d2i_ECParameters. d2i_ECParameters is a fairly pointless function when only named curves are allowed. In testing other implementations, none of Firefox, Safari, or IE11/Win will parse such certificates (i.e. the error is fatal and unbypassable). Likewise, because Mac and Windows' underlying libraries reject this, Chrome on Mac and Windows already rejects such things. Thus this change should be compatible. The following is the certificate and key I constructed to test with: -----BEGIN CERTIFICATE----- MIICwjCCAmqgAwIBAgIJANlMBNpJfb/rMAkGByqGSM49BAEwRTELMAkGA1UEBhMC QVUxEzARBgNVBAgMClNvbWUtU3RhdGUxITAfBgNVBAoMGEludGVybmV0IFdpZGdp dHMgUHR5IEx0ZDAeFw0xNDA0MjMyMzIxNTdaFw0xNDA1MjMyMzIxNTdaMEUxCzAJ BgNVBAYTAkFVMRMwEQYDVQQIDApTb21lLVN0YXRlMSEwHwYDVQQKDBhJbnRlcm5l dCBXaWRnaXRzIFB0eSBMdGQwggFLMIIBAwYHKoZIzj0CATCB9wIBATAsBgcqhkjO PQEBAiEA/////wAAAAEAAAAAAAAAAAAAAAD///////////////8wWwQg/////wAA AAEAAAAAAAAAAAAAAAD///////////////wEIFrGNdiqOpPns+u9VXaYhrxlHQaw zFOw9jvOPD4n0mBLAxUAxJ02CIbnBJNqZnjhE50mt4GffpAEQQRrF9Hy4SxCR/i8 5uVjpEDydwN9gS3rM6D0oTlF2JjClk/jQuL+Gn+bjufrSnwPnhYrzjNXazFezsu2 QGg3v1H1AiEA/////wAAAAD//////////7zm+q2nF56E87nKwvxjJVECAQEDQgAE 5itp4r9ln5e+Lx4NlIpM1Zdrt6keDUb73ampHp3culoB59aXqAoY+cPEox5W4nyD SNsWGhz1HX7xlC1Lz3IiwaNQME4wHQYDVR0OBBYEFKuE0qyrlfCCThZ4B1VXX+Qm jYLRMB8GA1UdIwQYMBaAFKuE0qyrlfCCThZ4B1VXX+QmjYLRMAwGA1UdEwQFMAMB Af8wCQYHKoZIzj0EAQNHADBEAiBATB6aVJxDD6YAxEM4vf6Sbg2Ty334ldXpkNwc TF+SngIgZ/f59kgDLf6YA04iLw1fUv5Wf1nLYJWwgrRFON5+zvw= -----END CERTIFICATE----- -----BEGIN EC PARAMETERS----- MIH3AgEBMCwGByqGSM49AQECIQD/////AAAAAQAAAAAAAAAAAAAAAP////////// /////zBbBCD/////AAAAAQAAAAAAAAAAAAAAAP///////////////AQgWsY12Ko6 k+ez671VdpiGvGUdBrDMU7D2O848PifSYEsDFQDEnTYIhucEk2pmeOETnSa3gZ9+ kARBBGsX0fLhLEJH+Lzm5WOkQPJ3A32BLeszoPShOUXYmMKWT+NC4v4af5uO5+tK fA+eFivOM1drMV7Oy7ZAaDe/UfUCIQD/////AAAAAP//////////vOb6racXnoTz ucrC/GMlUQIBAQ== -----END EC PARAMETERS----- -----BEGIN EC PRIVATE KEY----- MHcCAQEEIAcPCHJ61KBKnN1ZyU2JaHcItW/JXTB3DujRyc4Ki7RqoAoGCCqGSM49 AwEHoUQDQgAE5itp4r9ln5e+Lx4NlIpM1Zdrt6keDUb73ampHp3culoB59aXqAoY +cPEox5W4nyDSNsWGhz1HX7xlC1Lz3IiwQ== -----END EC PRIVATE KEY----- BUG=522228 Change-Id: I3723411a633dc07c4640027de07500293f8f7913 Reviewed-on: https://boringssl-review.googlesource.com/6853 Reviewed-by: Adam Langley <alangley@gmail.com>
2015-12-25 00:38:03 +00:00
OPENSSL_PUT_ERROR(EVP, EVP_R_DECODE_ERROR);
Fix memory leak on invalid ecPublicKey parameters. One of the codepaths didn't free the group. Found by libFuzzer. BUG=chromium:603893 Change-Id: Icb81f2f89a8c1a52e29069321498986b193a0e56 Reviewed-on: https://boringssl-review.googlesource.com/7685 Reviewed-by: Steven Valdez <svaldez@google.com> Reviewed-by: Adam Langley <agl@google.com>
2016-04-15 20:34:30 +01:00
goto err;
Don't allow the specifiedCurve form of ECParameters in SPKIs. Although RFC 3279 allows both, per RFC 5912, keys must use a named curve rather than spelling out the curve parameters. Although we do not allow arbitrary curves, we do have to (pretty hackishly) recognize built-in curves in ECPrivateKeys. It seems the cause of this was that OpenSSL, unless you set asn1_flag on the EC_GROUP, likes to encode keys by spelling out the parameters. This is in violation of RFC 5915, though probably not in violation of one of the other redundant ECC specifications. For more fun, it appears asn1_flag defaults to *off* in the API and *on* in the command-line tools. I think the original cause was these defaults meant the pre-BoringSSL Android/OpenSSL Chromium port wrote out Channel ID keys in this format. By now this should no longer by an issue, but it'll warrant a bit more investigation to be sure we can drop it. For now, keep this logic out of SPKIs by not calling d2i_ECParameters. d2i_ECParameters is a fairly pointless function when only named curves are allowed. In testing other implementations, none of Firefox, Safari, or IE11/Win will parse such certificates (i.e. the error is fatal and unbypassable). Likewise, because Mac and Windows' underlying libraries reject this, Chrome on Mac and Windows already rejects such things. Thus this change should be compatible. The following is the certificate and key I constructed to test with: -----BEGIN CERTIFICATE----- MIICwjCCAmqgAwIBAgIJANlMBNpJfb/rMAkGByqGSM49BAEwRTELMAkGA1UEBhMC QVUxEzARBgNVBAgMClNvbWUtU3RhdGUxITAfBgNVBAoMGEludGVybmV0IFdpZGdp dHMgUHR5IEx0ZDAeFw0xNDA0MjMyMzIxNTdaFw0xNDA1MjMyMzIxNTdaMEUxCzAJ BgNVBAYTAkFVMRMwEQYDVQQIDApTb21lLVN0YXRlMSEwHwYDVQQKDBhJbnRlcm5l dCBXaWRnaXRzIFB0eSBMdGQwggFLMIIBAwYHKoZIzj0CATCB9wIBATAsBgcqhkjO PQEBAiEA/////wAAAAEAAAAAAAAAAAAAAAD///////////////8wWwQg/////wAA AAEAAAAAAAAAAAAAAAD///////////////wEIFrGNdiqOpPns+u9VXaYhrxlHQaw zFOw9jvOPD4n0mBLAxUAxJ02CIbnBJNqZnjhE50mt4GffpAEQQRrF9Hy4SxCR/i8 5uVjpEDydwN9gS3rM6D0oTlF2JjClk/jQuL+Gn+bjufrSnwPnhYrzjNXazFezsu2 QGg3v1H1AiEA/////wAAAAD//////////7zm+q2nF56E87nKwvxjJVECAQEDQgAE 5itp4r9ln5e+Lx4NlIpM1Zdrt6keDUb73ampHp3culoB59aXqAoY+cPEox5W4nyD SNsWGhz1HX7xlC1Lz3IiwaNQME4wHQYDVR0OBBYEFKuE0qyrlfCCThZ4B1VXX+Qm jYLRMB8GA1UdIwQYMBaAFKuE0qyrlfCCThZ4B1VXX+QmjYLRMAwGA1UdEwQFMAMB Af8wCQYHKoZIzj0EAQNHADBEAiBATB6aVJxDD6YAxEM4vf6Sbg2Ty334ldXpkNwc TF+SngIgZ/f59kgDLf6YA04iLw1fUv5Wf1nLYJWwgrRFON5+zvw= -----END CERTIFICATE----- -----BEGIN EC PARAMETERS----- MIH3AgEBMCwGByqGSM49AQECIQD/////AAAAAQAAAAAAAAAAAAAAAP////////// /////zBbBCD/////AAAAAQAAAAAAAAAAAAAAAP///////////////AQgWsY12Ko6 k+ez671VdpiGvGUdBrDMU7D2O848PifSYEsDFQDEnTYIhucEk2pmeOETnSa3gZ9+ kARBBGsX0fLhLEJH+Lzm5WOkQPJ3A32BLeszoPShOUXYmMKWT+NC4v4af5uO5+tK fA+eFivOM1drMV7Oy7ZAaDe/UfUCIQD/////AAAAAP//////////vOb6racXnoTz ucrC/GMlUQIBAQ== -----END EC PARAMETERS----- -----BEGIN EC PRIVATE KEY----- MHcCAQEEIAcPCHJ61KBKnN1ZyU2JaHcItW/JXTB3DujRyc4Ki7RqoAoGCCqGSM49 AwEHoUQDQgAE5itp4r9ln5e+Lx4NlIpM1Zdrt6keDUb73ampHp3culoB59aXqAoY +cPEox5W4nyDSNsWGhz1HX7xlC1Lz3IiwQ== -----END EC PRIVATE KEY----- BUG=522228 Change-Id: I3723411a633dc07c4640027de07500293f8f7913 Reviewed-on: https://boringssl-review.googlesource.com/6853 Reviewed-by: Adam Langley <alangley@gmail.com>
2015-12-25 00:38:03 +00: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
Fix memory leak on invalid ecPublicKey parameters. One of the codepaths didn't free the group. Found by libFuzzer. BUG=chromium:603893 Change-Id: Icb81f2f89a8c1a52e29069321498986b193a0e56 Reviewed-on: https://boringssl-review.googlesource.com/7685 Reviewed-by: Steven Valdez <svaldez@google.com> Reviewed-by: Adam Langley <agl@google.com>
2016-04-15 20:34:30 +01:00
eckey = EC_KEY_new();
Decouple crypto/ec from the OID table. Instead, embed the (very short) encoding of the OID into built_in_curve. BUG=chromium:499653 Change-Id: I0db36f83c71fbd3321831f54fa5022f8304b30cd Reviewed-on: https://boringssl-review.googlesource.com/7564 Reviewed-by: Steven Valdez <svaldez@google.com> Reviewed-by: David Benjamin <davidben@google.com>
2016-03-25 22:07:15 +00:00
if (eckey == NULL || !EC_KEY_set_group(eckey, group)) {
goto err;
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
}
Decouple crypto/ec from the OID table. Instead, embed the (very short) encoding of the OID into built_in_curve. BUG=chromium:499653 Change-Id: I0db36f83c71fbd3321831f54fa5022f8304b30cd Reviewed-on: https://boringssl-review.googlesource.com/7564 Reviewed-by: Steven Valdez <svaldez@google.com> Reviewed-by: David Benjamin <davidben@google.com>
2016-03-25 22:07:15 +00:00
point = EC_POINT_new(group);
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 (point == NULL ||
Decouple crypto/ec from the OID table. Instead, embed the (very short) encoding of the OID into built_in_curve. BUG=chromium:499653 Change-Id: I0db36f83c71fbd3321831f54fa5022f8304b30cd Reviewed-on: https://boringssl-review.googlesource.com/7564 Reviewed-by: Steven Valdez <svaldez@google.com> Reviewed-by: David Benjamin <davidben@google.com>
2016-03-25 22:07:15 +00:00
!EC_POINT_oct2point(group, point, CBS_data(key), CBS_len(key), 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
!EC_KEY_set_public_key(eckey, point)) {
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
goto err;
}
Decouple crypto/ec from the OID table. Instead, embed the (very short) encoding of the OID into built_in_curve. BUG=chromium:499653 Change-Id: I0db36f83c71fbd3321831f54fa5022f8304b30cd Reviewed-on: https://boringssl-review.googlesource.com/7564 Reviewed-by: Steven Valdez <svaldez@google.com> Reviewed-by: David Benjamin <davidben@google.com>
2016-03-25 22:07:15 +00:00
EC_GROUP_free(group);
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
EC_POINT_free(point);
EVP_PKEY_assign_EC_KEY(out, eckey);
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
return 1;
err:
Decouple crypto/ec from the OID table. Instead, embed the (very short) encoding of the OID into built_in_curve. BUG=chromium:499653 Change-Id: I0db36f83c71fbd3321831f54fa5022f8304b30cd Reviewed-on: https://boringssl-review.googlesource.com/7564 Reviewed-by: Steven Valdez <svaldez@google.com> Reviewed-by: David Benjamin <davidben@google.com>
2016-03-25 22:07:15 +00:00
EC_GROUP_free(group);
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
EC_POINT_free(point);
EC_KEY_free(eckey);
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
return 0;
}
static int eckey_pub_cmp(const EVP_PKEY *a, const EVP_PKEY *b) {
int r;
const EC_GROUP *group = EC_KEY_get0_group(b->pkey.ec);
const EC_POINT *pa = EC_KEY_get0_public_key(a->pkey.ec),
*pb = EC_KEY_get0_public_key(b->pkey.ec);
r = EC_POINT_cmp(group, pa, pb, NULL);
if (r == 0) {
return 1;
} else if (r == 1) {
return 0;
} else {
return -2;
}
}
Implement new PKCS#8 parsers. As with SPKI parsers, the intent is make EVP_PKEY capture the key's constraints in full fidelity, so we'd have to add new types or store the information in the underlying key object if people introduce variant key types with weird constraints on them. Note that because PKCS#8 has a space for arbitrary attributes, this parser must admit a hole. I'm assuming for now that we don't need an API that enforces no attributes and just ignore trailing data in the structure for simplicity. BUG=499653 Change-Id: I6fc641355e87136c7220f5d7693566d1144a68e8 Reviewed-on: https://boringssl-review.googlesource.com/6866 Reviewed-by: Adam Langley <agl@google.com>
2016-01-01 06:17:30 +00:00
static int eckey_priv_decode(EVP_PKEY *out, CBS *params, CBS *key) {
/* See RFC 5915. */
EC_GROUP *group = EC_KEY_parse_parameters(params);
if (group == NULL || CBS_len(params) != 0) {
Don't allow the specifiedCurve form of ECParameters in SPKIs. Although RFC 3279 allows both, per RFC 5912, keys must use a named curve rather than spelling out the curve parameters. Although we do not allow arbitrary curves, we do have to (pretty hackishly) recognize built-in curves in ECPrivateKeys. It seems the cause of this was that OpenSSL, unless you set asn1_flag on the EC_GROUP, likes to encode keys by spelling out the parameters. This is in violation of RFC 5915, though probably not in violation of one of the other redundant ECC specifications. For more fun, it appears asn1_flag defaults to *off* in the API and *on* in the command-line tools. I think the original cause was these defaults meant the pre-BoringSSL Android/OpenSSL Chromium port wrote out Channel ID keys in this format. By now this should no longer by an issue, but it'll warrant a bit more investigation to be sure we can drop it. For now, keep this logic out of SPKIs by not calling d2i_ECParameters. d2i_ECParameters is a fairly pointless function when only named curves are allowed. In testing other implementations, none of Firefox, Safari, or IE11/Win will parse such certificates (i.e. the error is fatal and unbypassable). Likewise, because Mac and Windows' underlying libraries reject this, Chrome on Mac and Windows already rejects such things. Thus this change should be compatible. The following is the certificate and key I constructed to test with: -----BEGIN CERTIFICATE----- MIICwjCCAmqgAwIBAgIJANlMBNpJfb/rMAkGByqGSM49BAEwRTELMAkGA1UEBhMC QVUxEzARBgNVBAgMClNvbWUtU3RhdGUxITAfBgNVBAoMGEludGVybmV0IFdpZGdp dHMgUHR5IEx0ZDAeFw0xNDA0MjMyMzIxNTdaFw0xNDA1MjMyMzIxNTdaMEUxCzAJ BgNVBAYTAkFVMRMwEQYDVQQIDApTb21lLVN0YXRlMSEwHwYDVQQKDBhJbnRlcm5l dCBXaWRnaXRzIFB0eSBMdGQwggFLMIIBAwYHKoZIzj0CATCB9wIBATAsBgcqhkjO PQEBAiEA/////wAAAAEAAAAAAAAAAAAAAAD///////////////8wWwQg/////wAA AAEAAAAAAAAAAAAAAAD///////////////wEIFrGNdiqOpPns+u9VXaYhrxlHQaw zFOw9jvOPD4n0mBLAxUAxJ02CIbnBJNqZnjhE50mt4GffpAEQQRrF9Hy4SxCR/i8 5uVjpEDydwN9gS3rM6D0oTlF2JjClk/jQuL+Gn+bjufrSnwPnhYrzjNXazFezsu2 QGg3v1H1AiEA/////wAAAAD//////////7zm+q2nF56E87nKwvxjJVECAQEDQgAE 5itp4r9ln5e+Lx4NlIpM1Zdrt6keDUb73ampHp3culoB59aXqAoY+cPEox5W4nyD SNsWGhz1HX7xlC1Lz3IiwaNQME4wHQYDVR0OBBYEFKuE0qyrlfCCThZ4B1VXX+Qm jYLRMB8GA1UdIwQYMBaAFKuE0qyrlfCCThZ4B1VXX+QmjYLRMAwGA1UdEwQFMAMB Af8wCQYHKoZIzj0EAQNHADBEAiBATB6aVJxDD6YAxEM4vf6Sbg2Ty334ldXpkNwc TF+SngIgZ/f59kgDLf6YA04iLw1fUv5Wf1nLYJWwgrRFON5+zvw= -----END CERTIFICATE----- -----BEGIN EC PARAMETERS----- MIH3AgEBMCwGByqGSM49AQECIQD/////AAAAAQAAAAAAAAAAAAAAAP////////// /////zBbBCD/////AAAAAQAAAAAAAAAAAAAAAP///////////////AQgWsY12Ko6 k+ez671VdpiGvGUdBrDMU7D2O848PifSYEsDFQDEnTYIhucEk2pmeOETnSa3gZ9+ kARBBGsX0fLhLEJH+Lzm5WOkQPJ3A32BLeszoPShOUXYmMKWT+NC4v4af5uO5+tK fA+eFivOM1drMV7Oy7ZAaDe/UfUCIQD/////AAAAAP//////////vOb6racXnoTz ucrC/GMlUQIBAQ== -----END EC PARAMETERS----- -----BEGIN EC PRIVATE KEY----- MHcCAQEEIAcPCHJ61KBKnN1ZyU2JaHcItW/JXTB3DujRyc4Ki7RqoAoGCCqGSM49 AwEHoUQDQgAE5itp4r9ln5e+Lx4NlIpM1Zdrt6keDUb73ampHp3culoB59aXqAoY +cPEox5W4nyDSNsWGhz1HX7xlC1Lz3IiwQ== -----END EC PRIVATE KEY----- BUG=522228 Change-Id: I3723411a633dc07c4640027de07500293f8f7913 Reviewed-on: https://boringssl-review.googlesource.com/6853 Reviewed-by: Adam Langley <alangley@gmail.com>
2015-12-25 00:38:03 +00:00
OPENSSL_PUT_ERROR(EVP, EVP_R_DECODE_ERROR);
Implement new PKCS#8 parsers. As with SPKI parsers, the intent is make EVP_PKEY capture the key's constraints in full fidelity, so we'd have to add new types or store the information in the underlying key object if people introduce variant key types with weird constraints on them. Note that because PKCS#8 has a space for arbitrary attributes, this parser must admit a hole. I'm assuming for now that we don't need an API that enforces no attributes and just ignore trailing data in the structure for simplicity. BUG=499653 Change-Id: I6fc641355e87136c7220f5d7693566d1144a68e8 Reviewed-on: https://boringssl-review.googlesource.com/6866 Reviewed-by: Adam Langley <agl@google.com>
2016-01-01 06:17:30 +00:00
EC_GROUP_free(group);
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
return 0;
}
Implement new PKCS#8 parsers. As with SPKI parsers, the intent is make EVP_PKEY capture the key's constraints in full fidelity, so we'd have to add new types or store the information in the underlying key object if people introduce variant key types with weird constraints on them. Note that because PKCS#8 has a space for arbitrary attributes, this parser must admit a hole. I'm assuming for now that we don't need an API that enforces no attributes and just ignore trailing data in the structure for simplicity. BUG=499653 Change-Id: I6fc641355e87136c7220f5d7693566d1144a68e8 Reviewed-on: https://boringssl-review.googlesource.com/6866 Reviewed-by: Adam Langley <agl@google.com>
2016-01-01 06:17:30 +00:00
EC_KEY *ec_key = EC_KEY_parse_private_key(key, group);
EC_GROUP_free(group);
if (ec_key == NULL || CBS_len(key) != 0) {
Remove the func parameter to OPENSSL_PUT_ERROR. Much of this was done automatically with find . -name '*.c' | xargs sed -E -i '' -e 's/(OPENSSL_PUT_ERROR\([a-zA-Z_0-9]+, )[a-zA-Z_0-9]+, ([a-zA-Z_0-9]+\);)/\1\2/' find . -name '*.c' | xargs sed -E -i '' -e 's/(OPENSSL_PUT_ERROR\([a-zA-Z_0-9]+, )[a-zA-Z_0-9]+, ([a-zA-Z_0-9]+\);)/\1\2/' BUG=468039 Change-Id: I4c75fd95dff85ab1d4a546b05e6aed1aeeb499d8 Reviewed-on: https://boringssl-review.googlesource.com/5276 Reviewed-by: Adam Langley <agl@google.com>
2015-06-29 05:28:17 +01:00
OPENSSL_PUT_ERROR(EVP, EVP_R_DECODE_ERROR);
Implement new PKCS#8 parsers. As with SPKI parsers, the intent is make EVP_PKEY capture the key's constraints in full fidelity, so we'd have to add new types or store the information in the underlying key object if people introduce variant key types with weird constraints on them. Note that because PKCS#8 has a space for arbitrary attributes, this parser must admit a hole. I'm assuming for now that we don't need an API that enforces no attributes and just ignore trailing data in the structure for simplicity. BUG=499653 Change-Id: I6fc641355e87136c7220f5d7693566d1144a68e8 Reviewed-on: https://boringssl-review.googlesource.com/6866 Reviewed-by: Adam Langley <agl@google.com>
2016-01-01 06:17:30 +00:00
EC_KEY_free(ec_key);
return 0;
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
}
Implement new PKCS#8 parsers. As with SPKI parsers, the intent is make EVP_PKEY capture the key's constraints in full fidelity, so we'd have to add new types or store the information in the underlying key object if people introduce variant key types with weird constraints on them. Note that because PKCS#8 has a space for arbitrary attributes, this parser must admit a hole. I'm assuming for now that we don't need an API that enforces no attributes and just ignore trailing data in the structure for simplicity. BUG=499653 Change-Id: I6fc641355e87136c7220f5d7693566d1144a68e8 Reviewed-on: https://boringssl-review.googlesource.com/6866 Reviewed-by: Adam Langley <agl@google.com>
2016-01-01 06:17:30 +00:00
EVP_PKEY_assign_EC_KEY(out, ec_key);
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
return 1;
}
Implement new PKCS#8 parsers. As with SPKI parsers, the intent is make EVP_PKEY capture the key's constraints in full fidelity, so we'd have to add new types or store the information in the underlying key object if people introduce variant key types with weird constraints on them. Note that because PKCS#8 has a space for arbitrary attributes, this parser must admit a hole. I'm assuming for now that we don't need an API that enforces no attributes and just ignore trailing data in the structure for simplicity. BUG=499653 Change-Id: I6fc641355e87136c7220f5d7693566d1144a68e8 Reviewed-on: https://boringssl-review.googlesource.com/6866 Reviewed-by: Adam Langley <agl@google.com>
2016-01-01 06:17:30 +00:00
static int eckey_priv_encode(CBB *out, const EVP_PKEY *key) {
const EC_KEY *ec_key = key->pkey.ec;
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
Implement new PKCS#8 parsers. As with SPKI parsers, the intent is make EVP_PKEY capture the key's constraints in full fidelity, so we'd have to add new types or store the information in the underlying key object if people introduce variant key types with weird constraints on them. Note that because PKCS#8 has a space for arbitrary attributes, this parser must admit a hole. I'm assuming for now that we don't need an API that enforces no attributes and just ignore trailing data in the structure for simplicity. BUG=499653 Change-Id: I6fc641355e87136c7220f5d7693566d1144a68e8 Reviewed-on: https://boringssl-review.googlesource.com/6866 Reviewed-by: Adam Langley <agl@google.com>
2016-01-01 06:17:30 +00:00
/* Omit the redundant copy of the curve name. This contradicts RFC 5915 but
* aligns with PKCS #11. SEC 1 only says they may be omitted if known by other
* means. Both OpenSSL and NSS omit the redundant parameters, so we omit them
* as well. */
unsigned enc_flags = EC_KEY_get_enc_flags(ec_key) | EC_PKEY_NO_PARAMETERS;
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
Implement new PKCS#8 parsers. As with SPKI parsers, the intent is make EVP_PKEY capture the key's constraints in full fidelity, so we'd have to add new types or store the information in the underlying key object if people introduce variant key types with weird constraints on them. Note that because PKCS#8 has a space for arbitrary attributes, this parser must admit a hole. I'm assuming for now that we don't need an API that enforces no attributes and just ignore trailing data in the structure for simplicity. BUG=499653 Change-Id: I6fc641355e87136c7220f5d7693566d1144a68e8 Reviewed-on: https://boringssl-review.googlesource.com/6866 Reviewed-by: Adam Langley <agl@google.com>
2016-01-01 06:17:30 +00:00
/* See RFC 5915. */
Decouple crypto/evp from the OID table. BUG=chromium:499653 Change-Id: I4e8d4af3129dbf61d4a8846ec9db685e83999d5e Reviewed-on: https://boringssl-review.googlesource.com/7565 Reviewed-by: Steven Valdez <svaldez@google.com> Reviewed-by: David Benjamin <davidben@google.com>
2016-03-25 22:07:16 +00:00
CBB pkcs8, algorithm, oid, private_key;
Implement new PKCS#8 parsers. As with SPKI parsers, the intent is make EVP_PKEY capture the key's constraints in full fidelity, so we'd have to add new types or store the information in the underlying key object if people introduce variant key types with weird constraints on them. Note that because PKCS#8 has a space for arbitrary attributes, this parser must admit a hole. I'm assuming for now that we don't need an API that enforces no attributes and just ignore trailing data in the structure for simplicity. BUG=499653 Change-Id: I6fc641355e87136c7220f5d7693566d1144a68e8 Reviewed-on: https://boringssl-review.googlesource.com/6866 Reviewed-by: Adam Langley <agl@google.com>
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) ||
Decouple crypto/evp from the OID table. BUG=chromium:499653 Change-Id: I4e8d4af3129dbf61d4a8846ec9db685e83999d5e Reviewed-on: https://boringssl-review.googlesource.com/7565 Reviewed-by: Steven Valdez <svaldez@google.com> Reviewed-by: David Benjamin <davidben@google.com>
2016-03-25 22:07:16 +00:00
!CBB_add_asn1(&algorithm, &oid, CBS_ASN1_OBJECT) ||
!CBB_add_bytes(&oid, ec_asn1_meth.oid, ec_asn1_meth.oid_len) ||
Decouple crypto/ec from the OID table. Instead, embed the (very short) encoding of the OID into built_in_curve. BUG=chromium:499653 Change-Id: I0db36f83c71fbd3321831f54fa5022f8304b30cd Reviewed-on: https://boringssl-review.googlesource.com/7564 Reviewed-by: Steven Valdez <svaldez@google.com> Reviewed-by: David Benjamin <davidben@google.com>
2016-03-25 22:07:15 +00:00
!EC_KEY_marshal_curve_name(&algorithm, EC_KEY_get0_group(ec_key)) ||
Implement new PKCS#8 parsers. As with SPKI parsers, the intent is make EVP_PKEY capture the key's constraints in full fidelity, so we'd have to add new types or store the information in the underlying key object if people introduce variant key types with weird constraints on them. Note that because PKCS#8 has a space for arbitrary attributes, this parser must admit a hole. I'm assuming for now that we don't need an API that enforces no attributes and just ignore trailing data in the structure for simplicity. BUG=499653 Change-Id: I6fc641355e87136c7220f5d7693566d1144a68e8 Reviewed-on: https://boringssl-review.googlesource.com/6866 Reviewed-by: Adam Langley <agl@google.com>
2016-01-01 06:17:30 +00:00
!CBB_add_asn1(&pkcs8, &private_key, CBS_ASN1_OCTETSTRING) ||
!EC_KEY_marshal_private_key(&private_key, ec_key, enc_flags) ||
!CBB_flush(out)) {
OPENSSL_PUT_ERROR(EVP, EVP_R_ENCODE_ERROR);
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
return 0;
}
return 1;
}
static int int_ec_size(const EVP_PKEY *pkey) {
return ECDSA_size(pkey->pkey.ec);
}
static int ec_bits(const EVP_PKEY *pkey) {
Add |EC_GROUP_get0_order| to replace |EC_GROUP_get_order|. |EC_GROUP_get0_order| doesn't require any heap allocations and never fails, so it is much more convenient and more efficient for callers to call. Change-Id: Ic60f768875e7bc8e74362dacdb5cbbc6957b05a6 Reviewed-on: https://boringssl-review.googlesource.com/6532 Reviewed-by: Adam Langley <agl@google.com>
2015-11-19 03:07:14 +00:00
const EC_GROUP *group = EC_KEY_get0_group(pkey->pkey.ec);
if (group == NULL) {
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
ERR_clear_error();
return 0;
}
Add |EC_GROUP_get0_order| to replace |EC_GROUP_get_order|. |EC_GROUP_get0_order| doesn't require any heap allocations and never fails, so it is much more convenient and more efficient for callers to call. Change-Id: Ic60f768875e7bc8e74362dacdb5cbbc6957b05a6 Reviewed-on: https://boringssl-review.googlesource.com/6532 Reviewed-by: Adam Langley <agl@google.com>
2015-11-19 03:07:14 +00:00
return BN_num_bits(EC_GROUP_get0_order(group));
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
}
static int ec_missing_parameters(const EVP_PKEY *pkey) {
return EC_KEY_get0_group(pkey->pkey.ec) == NULL;
}
static int ec_copy_parameters(EVP_PKEY *to, const EVP_PKEY *from) {
EC_GROUP *group = EC_GROUP_dup(EC_KEY_get0_group(from->pkey.ec));
if (group == NULL ||
EC_KEY_set_group(to->pkey.ec, group) == 0) {
return 0;
}
EC_GROUP_free(group);
return 1;
}
static int ec_cmp_parameters(const EVP_PKEY *a, const EVP_PKEY *b) {
const EC_GROUP *group_a = EC_KEY_get0_group(a->pkey.ec),
*group_b = EC_KEY_get0_group(b->pkey.ec);
EC_GROUP_cmp should return zero if the groups match. (I got this wrong when reading the OpenSSL code.) Change-Id: Ib289ef41d0ab5a3157ad8b9454d2de96d1f86c22 Reviewed-on: https://boringssl-review.googlesource.com/3620 Reviewed-by: Adam Langley <agl@google.com>
2015-02-24 22:30:15 +00:00
if (EC_GROUP_cmp(group_a, group_b, NULL) != 0) {
/* mismatch */
return 0;
}
return 1;
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
}
static void int_ec_free(EVP_PKEY *pkey) { EC_KEY_free(pkey->pkey.ec); }
Introduce EVP_PKEY_is_opaque to replace RSA_METHOD_FLAG_NO_CHECK. Custom RSA and ECDSA keys may not expose the key material. Plumb and "opaque" bit out of the *_METHOD up to EVP_PKEY. Query that in ssl_rsa.c to skip the sanity checks for certificate and key matching. Change-Id: I362a2d5116bfd1803560dfca1d69a91153e895fc Reviewed-on: https://boringssl-review.googlesource.com/1255 Reviewed-by: Adam Langley <agl@google.com>
2014-07-18 23:39:42 +01:00
static int eckey_opaque(const EVP_PKEY *pkey) {
return EC_KEY_is_opaque(pkey->pkey.ec);
}
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
const EVP_PKEY_ASN1_METHOD ec_asn1_meth = {
EVP_PKEY_EC,
Decouple crypto/evp from the OID table. BUG=chromium:499653 Change-Id: I4e8d4af3129dbf61d4a8846ec9db685e83999d5e Reviewed-on: https://boringssl-review.googlesource.com/7565 Reviewed-by: Steven Valdez <svaldez@google.com> Reviewed-by: David Benjamin <davidben@google.com>
2016-03-25 22:07:16 +00:00
/* 1.2.840.10045.2.1 */
{0x2a, 0x86, 0x48, 0xce, 0x3d, 0x02, 0x01}, 7,
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
eckey_pub_decode,
eckey_pub_encode,
eckey_pub_cmp,
eckey_priv_decode,
eckey_priv_encode,
Introduce EVP_PKEY_is_opaque to replace RSA_METHOD_FLAG_NO_CHECK. Custom RSA and ECDSA keys may not expose the key material. Plumb and "opaque" bit out of the *_METHOD up to EVP_PKEY. Query that in ssl_rsa.c to skip the sanity checks for certificate and key matching. Change-Id: I362a2d5116bfd1803560dfca1d69a91153e895fc Reviewed-on: https://boringssl-review.googlesource.com/1255 Reviewed-by: Adam Langley <agl@google.com>
2014-07-18 23:39:42 +01:00
eckey_opaque,
Add EVP_PKEY_supports_digest. This is intended for TLS client auth with Windows CAPI- and CNG-backed keys which implement sign over sign_raw and do not support all hash functions. Only plumbed through RSA for now. Change-Id: Ica42e7fb026840f817a169da9372dda226f7d6fd Reviewed-on: https://boringssl-review.googlesource.com/2250 Reviewed-by: Adam Langley <agl@google.com>
2014-11-12 04:47:50 +00:00
0 /* pkey_supports_digest */,
Introduce EVP_PKEY_is_opaque to replace RSA_METHOD_FLAG_NO_CHECK. Custom RSA and ECDSA keys may not expose the key material. Plumb and "opaque" bit out of the *_METHOD up to EVP_PKEY. Query that in ssl_rsa.c to skip the sanity checks for certificate and key matching. Change-Id: I362a2d5116bfd1803560dfca1d69a91153e895fc Reviewed-on: https://boringssl-review.googlesource.com/1255 Reviewed-by: Adam Langley <agl@google.com>
2014-07-18 23:39:42 +01:00
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
int_ec_size,
ec_bits,
ec_missing_parameters,
ec_copy_parameters,
ec_cmp_parameters,
int_ec_free,
};
Reference in New Issue Copy Permalink