2015-05-11 20:58:08 +01:00
|
|
|
/*
|
|
|
|
* Written by Dr Stephen N Henson (steve@openssl.org) for the OpenSSL
|
|
|
|
* project.
|
|
|
|
*/
|
|
|
|
/* ====================================================================
|
|
|
|
* Copyright (c) 2015 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.
|
|
|
|
* ====================================================================
|
|
|
|
*/
|
|
|
|
|
2016-06-09 21:48:33 +01:00
|
|
|
#include <openssl/evp.h>
|
|
|
|
|
2015-05-11 20:58:08 +01:00
|
|
|
#include <stdio.h>
|
|
|
|
#include <stdint.h>
|
|
|
|
#include <stdlib.h>
|
|
|
|
#include <string.h>
|
|
|
|
|
2016-06-09 21:48:33 +01:00
|
|
|
OPENSSL_MSVC_PRAGMA(warning(push))
|
|
|
|
OPENSSL_MSVC_PRAGMA(warning(disable: 4702))
|
2015-07-22 02:46:20 +01:00
|
|
|
|
2015-05-11 20:58:08 +01:00
|
|
|
#include <map>
|
|
|
|
#include <string>
|
2015-11-21 08:00:50 +00:00
|
|
|
#include <utility>
|
2015-05-11 20:58:08 +01:00
|
|
|
#include <vector>
|
|
|
|
|
2016-06-09 21:48:33 +01:00
|
|
|
OPENSSL_MSVC_PRAGMA(warning(pop))
|
2015-07-22 02:46:20 +01:00
|
|
|
|
2017-06-08 21:00:10 +01:00
|
|
|
#include <gtest/gtest.h>
|
|
|
|
|
2017-09-03 04:25:01 +01:00
|
|
|
#include <openssl/buf.h>
|
2016-09-06 23:10:19 +01:00
|
|
|
#include <openssl/bytestring.h>
|
2015-05-11 20:58:08 +01:00
|
|
|
#include <openssl/crypto.h>
|
|
|
|
#include <openssl/digest.h>
|
|
|
|
#include <openssl/err.h>
|
2016-12-14 17:34:08 +00:00
|
|
|
#include <openssl/rsa.h>
|
2015-05-11 20:58:08 +01:00
|
|
|
|
|
|
|
#include "../test/file_test.h"
|
2017-06-08 21:00:10 +01:00
|
|
|
#include "../test/test_util.h"
|
2015-05-11 20:58:08 +01:00
|
|
|
|
|
|
|
|
2015-06-15 20:51:19 +01:00
|
|
|
// evp_test dispatches between multiple test types. PrivateKey tests take a key
|
|
|
|
// name parameter and single block, decode it as a PEM private key, and save it
|
|
|
|
// under that key name. Decrypt, Sign, and Verify tests take a previously
|
|
|
|
// imported key name as parameter and test their respective operations.
|
2015-05-11 20:58:08 +01:00
|
|
|
|
|
|
|
static const EVP_MD *GetDigest(FileTest *t, const std::string &name) {
|
|
|
|
if (name == "MD5") {
|
|
|
|
return EVP_md5();
|
|
|
|
} else if (name == "SHA1") {
|
|
|
|
return EVP_sha1();
|
|
|
|
} else if (name == "SHA224") {
|
|
|
|
return EVP_sha224();
|
|
|
|
} else if (name == "SHA256") {
|
|
|
|
return EVP_sha256();
|
|
|
|
} else if (name == "SHA384") {
|
|
|
|
return EVP_sha384();
|
|
|
|
} else if (name == "SHA512") {
|
|
|
|
return EVP_sha512();
|
|
|
|
}
|
2017-06-08 21:00:10 +01:00
|
|
|
ADD_FAILURE() << "Unknown digest: " << name;
|
2015-05-11 20:58:08 +01:00
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
|
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 GetKeyType(FileTest *t, const std::string &name) {
|
|
|
|
if (name == "RSA") {
|
|
|
|
return EVP_PKEY_RSA;
|
|
|
|
}
|
|
|
|
if (name == "EC") {
|
|
|
|
return EVP_PKEY_EC;
|
|
|
|
}
|
|
|
|
if (name == "DSA") {
|
|
|
|
return EVP_PKEY_DSA;
|
|
|
|
}
|
2017-03-28 03:55:52 +01:00
|
|
|
if (name == "Ed25519") {
|
|
|
|
return EVP_PKEY_ED25519;
|
|
|
|
}
|
2017-06-08 21:00:10 +01:00
|
|
|
ADD_FAILURE() << "Unknown key type: " << name;
|
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 EVP_PKEY_NONE;
|
|
|
|
}
|
|
|
|
|
2016-12-14 17:34:08 +00:00
|
|
|
static int GetRSAPadding(FileTest *t, int *out, const std::string &name) {
|
|
|
|
if (name == "PKCS1") {
|
|
|
|
*out = RSA_PKCS1_PADDING;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
if (name == "PSS") {
|
|
|
|
*out = RSA_PKCS1_PSS_PADDING;
|
|
|
|
return true;
|
|
|
|
}
|
2017-01-01 21:03:24 +00:00
|
|
|
if (name == "OAEP") {
|
|
|
|
*out = RSA_PKCS1_OAEP_PADDING;
|
|
|
|
return true;
|
|
|
|
}
|
2017-06-08 21:00:10 +01:00
|
|
|
ADD_FAILURE() << "Unknown RSA padding mode: " << name;
|
2016-12-14 17:34:08 +00:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2016-08-18 04:10:28 +01:00
|
|
|
using KeyMap = std::map<std::string, bssl::UniquePtr<EVP_PKEY>>;
|
2015-05-11 20:58:08 +01:00
|
|
|
|
2016-01-01 06:17:30 +00:00
|
|
|
static bool ImportKey(FileTest *t, KeyMap *key_map,
|
|
|
|
EVP_PKEY *(*parse_func)(CBS *cbs),
|
|
|
|
int (*marshal_func)(CBB *cbb, const EVP_PKEY *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
|
|
|
std::vector<uint8_t> input;
|
|
|
|
if (!t->GetBytes(&input, "Input")) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
CBS cbs;
|
|
|
|
CBS_init(&cbs, input.data(), input.size());
|
2016-08-18 04:10:28 +01:00
|
|
|
bssl::UniquePtr<EVP_PKEY> pkey(parse_func(&cbs));
|
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 (!pkey) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
std::string key_type;
|
|
|
|
if (!t->GetAttribute(&key_type, "Type")) {
|
|
|
|
return false;
|
|
|
|
}
|
2017-06-08 21:00:10 +01:00
|
|
|
EXPECT_EQ(GetKeyType(t, key_type), EVP_PKEY_id(pkey.get()));
|
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
|
|
|
|
2016-01-01 06:17:30 +00:00
|
|
|
// The key must re-encode correctly.
|
2016-12-07 03:35:41 +00:00
|
|
|
bssl::ScopedCBB cbb;
|
2016-01-01 06:17:30 +00:00
|
|
|
uint8_t *der;
|
|
|
|
size_t der_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
|
|
|
if (!CBB_init(cbb.get(), 0) ||
|
2016-01-01 06:17:30 +00:00
|
|
|
!marshal_func(cbb.get(), pkey.get()) ||
|
|
|
|
!CBB_finish(cbb.get(), &der, &der_len)) {
|
|
|
|
return false;
|
|
|
|
}
|
2016-08-18 04:10:28 +01:00
|
|
|
bssl::UniquePtr<uint8_t> free_der(der);
|
2016-01-01 06:17:30 +00:00
|
|
|
|
|
|
|
std::vector<uint8_t> output = input;
|
|
|
|
if (t->HasAttribute("Output") &&
|
|
|
|
!t->GetBytes(&output, "Output")) {
|
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 false;
|
|
|
|
}
|
2017-06-08 21:00:10 +01:00
|
|
|
EXPECT_EQ(Bytes(output), Bytes(der, der_len)) << "Re-encoding the key did not match.";
|
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
|
|
|
|
|
|
|
// Save the key for future tests.
|
|
|
|
const std::string &key_name = t->GetParameter();
|
2017-06-08 21:00:10 +01:00
|
|
|
EXPECT_EQ(0u, key_map->count(key_name)) << "Duplicate key: " << key_name;
|
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
|
|
|
(*key_map)[key_name] = std::move(pkey);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2017-06-01 00:07:31 +01:00
|
|
|
// SetupContext configures |ctx| based on attributes in |t|, with the exception
|
|
|
|
// of the signing digest which must be configured externally.
|
|
|
|
static bool SetupContext(FileTest *t, EVP_PKEY_CTX *ctx) {
|
|
|
|
if (t->HasAttribute("RSAPadding")) {
|
|
|
|
int padding;
|
|
|
|
if (!GetRSAPadding(t, &padding, t->GetAttributeOrDie("RSAPadding")) ||
|
|
|
|
!EVP_PKEY_CTX_set_rsa_padding(ctx, padding)) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (t->HasAttribute("PSSSaltLength") &&
|
|
|
|
!EVP_PKEY_CTX_set_rsa_pss_saltlen(
|
|
|
|
ctx, atoi(t->GetAttributeOrDie("PSSSaltLength").c_str()))) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
if (t->HasAttribute("MGF1Digest")) {
|
|
|
|
const EVP_MD *digest = GetDigest(t, t->GetAttributeOrDie("MGF1Digest"));
|
|
|
|
if (digest == nullptr || !EVP_PKEY_CTX_set_rsa_mgf1_md(ctx, digest)) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
2017-09-03 04:25:01 +01:00
|
|
|
if (t->HasAttribute("OAEPDigest")) {
|
|
|
|
const EVP_MD *digest = GetDigest(t, t->GetAttributeOrDie("OAEPDigest"));
|
|
|
|
if (digest == nullptr || !EVP_PKEY_CTX_set_rsa_oaep_md(ctx, digest)) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (t->HasAttribute("OAEPLabel")) {
|
|
|
|
std::vector<uint8_t> label;
|
|
|
|
if (!t->GetBytes(&label, "OAEPLabel")) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
// For historical reasons, |EVP_PKEY_CTX_set0_rsa_oaep_label| expects to be
|
|
|
|
// take ownership of the input.
|
|
|
|
bssl::UniquePtr<uint8_t> buf(
|
|
|
|
reinterpret_cast<uint8_t *>(BUF_memdup(label.data(), label.size())));
|
|
|
|
if (!buf ||
|
|
|
|
!EVP_PKEY_CTX_set0_rsa_oaep_label(ctx, buf.get(), label.size())) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
buf.release();
|
|
|
|
}
|
2017-06-01 00:07:31 +01:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2017-06-08 21:00:10 +01:00
|
|
|
static bool TestEVP(FileTest *t, KeyMap *key_map) {
|
2015-05-11 20:58:08 +01:00
|
|
|
if (t->GetType() == "PrivateKey") {
|
2016-01-01 06:17:30 +00:00
|
|
|
return ImportKey(t, key_map, EVP_parse_private_key,
|
|
|
|
EVP_marshal_private_key);
|
2015-05-11 20:58:08 +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
|
|
|
if (t->GetType() == "PublicKey") {
|
2016-01-01 06:17:30 +00:00
|
|
|
return ImportKey(t, key_map, EVP_parse_public_key, EVP_marshal_public_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
|
|
|
}
|
|
|
|
|
2017-06-01 00:07:31 +01:00
|
|
|
int (*key_op_init)(EVP_PKEY_CTX *ctx) = nullptr;
|
2015-05-11 20:58:08 +01:00
|
|
|
int (*key_op)(EVP_PKEY_CTX *ctx, uint8_t *out, size_t *out_len,
|
2017-03-28 19:54:06 +01:00
|
|
|
const uint8_t *in, size_t in_len) = nullptr;
|
2017-06-01 00:07:31 +01:00
|
|
|
int (*md_op_init)(EVP_MD_CTX * ctx, EVP_PKEY_CTX * *pctx, const EVP_MD *type,
|
|
|
|
ENGINE *e, EVP_PKEY *pkey) = nullptr;
|
|
|
|
bool is_verify = false;
|
2015-05-11 20:58:08 +01:00
|
|
|
if (t->GetType() == "Decrypt") {
|
|
|
|
key_op_init = EVP_PKEY_decrypt_init;
|
|
|
|
key_op = EVP_PKEY_decrypt;
|
|
|
|
} else if (t->GetType() == "Sign") {
|
|
|
|
key_op_init = EVP_PKEY_sign_init;
|
|
|
|
key_op = EVP_PKEY_sign;
|
|
|
|
} else if (t->GetType() == "Verify") {
|
|
|
|
key_op_init = EVP_PKEY_verify_init;
|
2017-06-01 00:07:31 +01:00
|
|
|
is_verify = true;
|
|
|
|
} else if (t->GetType() == "SignMessage") {
|
|
|
|
md_op_init = EVP_DigestSignInit;
|
2017-03-28 19:54:06 +01:00
|
|
|
} else if (t->GetType() == "VerifyMessage") {
|
2017-06-01 00:07:31 +01:00
|
|
|
md_op_init = EVP_DigestVerifyInit;
|
|
|
|
is_verify = true;
|
2017-09-03 17:56:14 +01:00
|
|
|
} else if (t->GetType() == "Encrypt") {
|
|
|
|
key_op_init = EVP_PKEY_encrypt_init;
|
|
|
|
key_op = EVP_PKEY_encrypt;
|
2015-05-11 20:58:08 +01:00
|
|
|
} else {
|
2017-06-08 21:00:10 +01:00
|
|
|
ADD_FAILURE() << "Unknown test " << t->GetType();
|
2015-05-11 20:58:08 +01:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Load the key.
|
|
|
|
const std::string &key_name = t->GetParameter();
|
|
|
|
if (key_map->count(key_name) == 0) {
|
2017-06-08 21:00:10 +01:00
|
|
|
ADD_FAILURE() << "Could not find key " << key_name;
|
2015-05-11 20:58:08 +01:00
|
|
|
return false;
|
|
|
|
}
|
2015-11-21 08:00:50 +00:00
|
|
|
EVP_PKEY *key = (*key_map)[key_name].get();
|
2015-05-11 20:58:08 +01:00
|
|
|
|
2017-06-01 00:07:31 +01:00
|
|
|
const EVP_MD *digest = nullptr;
|
2015-05-11 20:58:08 +01:00
|
|
|
if (t->HasAttribute("Digest")) {
|
2017-06-01 00:07:31 +01:00
|
|
|
digest = GetDigest(t, t->GetAttributeOrDie("Digest"));
|
|
|
|
if (digest == nullptr) {
|
2016-12-14 17:34:08 +00:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
2017-06-01 00:07:31 +01:00
|
|
|
|
|
|
|
// For verify tests, the "output" is the signature. Read it now so that, for
|
|
|
|
// tests which expect a failure in SetupContext, the attribute is still
|
|
|
|
// consumed.
|
|
|
|
std::vector<uint8_t> input, actual, output;
|
|
|
|
if (!t->GetBytes(&input, "Input") ||
|
|
|
|
(is_verify && !t->GetBytes(&output, "Output"))) {
|
2016-12-14 17:34:08 +00:00
|
|
|
return false;
|
|
|
|
}
|
2017-06-01 00:07:31 +01:00
|
|
|
|
|
|
|
if (md_op_init) {
|
|
|
|
bssl::ScopedEVP_MD_CTX ctx;
|
|
|
|
EVP_PKEY_CTX *pctx;
|
|
|
|
if (!md_op_init(ctx.get(), &pctx, digest, nullptr, key) ||
|
|
|
|
!SetupContext(t, pctx)) {
|
2016-12-14 17:34:08 +00:00
|
|
|
return false;
|
2015-05-11 20:58:08 +01:00
|
|
|
}
|
|
|
|
|
2017-06-01 00:07:31 +01:00
|
|
|
if (is_verify) {
|
|
|
|
return !!EVP_DigestVerify(ctx.get(), output.data(), output.size(),
|
|
|
|
input.data(), input.size());
|
|
|
|
}
|
|
|
|
|
|
|
|
size_t len;
|
|
|
|
if (!EVP_DigestSign(ctx.get(), nullptr, &len, input.data(), input.size())) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
actual.resize(len);
|
|
|
|
if (!EVP_DigestSign(ctx.get(), actual.data(), &len, input.data(),
|
|
|
|
input.size()) ||
|
|
|
|
!t->GetBytes(&output, "Output")) {
|
2015-05-11 20:58:08 +01:00
|
|
|
return false;
|
|
|
|
}
|
2017-06-01 00:07:31 +01:00
|
|
|
actual.resize(len);
|
|
|
|
EXPECT_EQ(Bytes(output), Bytes(actual));
|
2015-05-11 20:58:08 +01:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2017-06-01 00:07:31 +01:00
|
|
|
bssl::UniquePtr<EVP_PKEY_CTX> ctx(EVP_PKEY_CTX_new(key, nullptr));
|
|
|
|
if (!ctx ||
|
|
|
|
!key_op_init(ctx.get()) ||
|
|
|
|
(digest != nullptr &&
|
|
|
|
!EVP_PKEY_CTX_set_signature_md(ctx.get(), digest)) ||
|
|
|
|
!SetupContext(t, ctx.get())) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (is_verify) {
|
|
|
|
return !!EVP_PKEY_verify(ctx.get(), output.data(), output.size(),
|
|
|
|
input.data(), input.size());
|
|
|
|
}
|
|
|
|
|
2015-05-11 20:58:08 +01:00
|
|
|
size_t len;
|
2015-11-11 22:01:27 +00:00
|
|
|
if (!key_op(ctx.get(), nullptr, &len, input.data(), input.size())) {
|
2015-05-11 20:58:08 +01:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
actual.resize(len);
|
2017-09-03 17:56:14 +01:00
|
|
|
if (!key_op(ctx.get(), actual.data(), &len, input.data(), input.size())) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Encryption is non-deterministic, so we check by decrypting.
|
|
|
|
if (t->HasAttribute("CheckDecrypt")) {
|
|
|
|
size_t plaintext_len;
|
|
|
|
ctx.reset(EVP_PKEY_CTX_new(key, nullptr));
|
|
|
|
if (!ctx ||
|
|
|
|
!EVP_PKEY_decrypt_init(ctx.get()) ||
|
|
|
|
(digest != nullptr &&
|
|
|
|
!EVP_PKEY_CTX_set_signature_md(ctx.get(), digest)) ||
|
|
|
|
!SetupContext(t, ctx.get()) ||
|
|
|
|
!EVP_PKEY_decrypt(ctx.get(), nullptr, &plaintext_len, actual.data(),
|
|
|
|
actual.size())) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
output.resize(plaintext_len);
|
|
|
|
if (!EVP_PKEY_decrypt(ctx.get(), output.data(), &plaintext_len,
|
|
|
|
actual.data(), actual.size())) {
|
|
|
|
ADD_FAILURE() << "Could not decrypt result.";
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
output.resize(plaintext_len);
|
|
|
|
EXPECT_EQ(Bytes(input), Bytes(output)) << "Decrypted result mismatch.";
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Some signature schemes are non-deterministic, so we check by verifying.
|
|
|
|
if (t->HasAttribute("CheckVerify")) {
|
|
|
|
ctx.reset(EVP_PKEY_CTX_new(key, nullptr));
|
|
|
|
if (!ctx ||
|
|
|
|
!EVP_PKEY_verify_init(ctx.get()) ||
|
|
|
|
(digest != nullptr &&
|
|
|
|
!EVP_PKEY_CTX_set_signature_md(ctx.get(), digest)) ||
|
|
|
|
!SetupContext(t, ctx.get())) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
if (t->HasAttribute("VerifyPSSSaltLength") &&
|
|
|
|
!EVP_PKEY_CTX_set_rsa_pss_saltlen(
|
|
|
|
ctx.get(),
|
|
|
|
atoi(t->GetAttributeOrDie("VerifyPSSSaltLength").c_str()))) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
EXPECT_TRUE(EVP_PKEY_verify(ctx.get(), actual.data(), actual.size(),
|
|
|
|
input.data(), input.size()))
|
|
|
|
<< "Could not verify result.";
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
// By default, check by comparing the result against Output.
|
|
|
|
if (!t->GetBytes(&output, "Output")) {
|
2015-05-11 20:58:08 +01:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
actual.resize(len);
|
2017-06-08 21:00:10 +01:00
|
|
|
EXPECT_EQ(Bytes(output), Bytes(actual));
|
2015-05-11 20:58:08 +01:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2017-06-08 21:00:10 +01:00
|
|
|
TEST(EVPTest, TestVectors) {
|
|
|
|
KeyMap key_map;
|
|
|
|
FileTestGTest("crypto/evp/evp_tests.txt", [&](FileTest *t) {
|
|
|
|
bool result = TestEVP(t, &key_map);
|
|
|
|
if (t->HasAttribute("Error")) {
|
|
|
|
ASSERT_FALSE(result) << "Operation unexpectedly succeeded.";
|
|
|
|
uint32_t err = ERR_peek_error();
|
|
|
|
EXPECT_EQ(t->GetAttributeOrDie("Error"), ERR_reason_error_string(err));
|
2017-06-01 00:07:31 +01:00
|
|
|
} else if (!result) {
|
|
|
|
ADD_FAILURE() << "Operation unexpectedly failed.";
|
2017-06-08 21:00:10 +01:00
|
|
|
}
|
|
|
|
});
|
2015-05-11 20:58:08 +01:00
|
|
|
}
|