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
|
|
|
|
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>
|
|
|
|
|
|
|
|
#include "../test/file_test.h"
|
|
|
|
|
|
|
|
|
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();
|
|
|
|
}
|
|
|
|
t->PrintLine("Unknown digest: '%s'", name.c_str());
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
t->PrintLine("Unknown key type: '%s'", name.c_str());
|
|
|
|
return EVP_PKEY_NONE;
|
|
|
|
}
|
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
if (EVP_PKEY_id(pkey.get()) != GetKeyType(t, key_type)) {
|
|
|
|
t->PrintLine("Bad key type.");
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
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;
|
|
|
|
}
|
2016-01-01 06:17:30 +00:00
|
|
|
if (!t->ExpectBytesEqual(output.data(), output.size(), der, der_len)) {
|
|
|
|
t->PrintLine("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
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Save the key for future tests.
|
|
|
|
const std::string &key_name = t->GetParameter();
|
|
|
|
if (key_map->count(key_name) > 0) {
|
|
|
|
t->PrintLine("Duplicate key '%s'.", key_name.c_str());
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
(*key_map)[key_name] = std::move(pkey);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2015-05-11 20:58:08 +01:00
|
|
|
static bool TestEVP(FileTest *t, void *arg) {
|
|
|
|
KeyMap *key_map = reinterpret_cast<KeyMap*>(arg);
|
|
|
|
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
|
|
|
}
|
|
|
|
|
2015-05-11 20:58:08 +01:00
|
|
|
int (*key_op_init)(EVP_PKEY_CTX *ctx);
|
|
|
|
int (*key_op)(EVP_PKEY_CTX *ctx, uint8_t *out, size_t *out_len,
|
|
|
|
const uint8_t *in, size_t in_len);
|
|
|
|
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;
|
|
|
|
key_op = nullptr; // EVP_PKEY_verify is handled differently.
|
|
|
|
} else {
|
|
|
|
t->PrintLine("Unknown test '%s'", t->GetType().c_str());
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Load the key.
|
|
|
|
const std::string &key_name = t->GetParameter();
|
|
|
|
if (key_map->count(key_name) == 0) {
|
|
|
|
t->PrintLine("Could not find key '%s'.", key_name.c_str());
|
|
|
|
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
|
|
|
|
|
|
|
std::vector<uint8_t> input, output;
|
|
|
|
if (!t->GetBytes(&input, "Input") ||
|
|
|
|
!t->GetBytes(&output, "Output")) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Set up the EVP_PKEY_CTX.
|
2016-08-18 04:10:28 +01:00
|
|
|
bssl::UniquePtr<EVP_PKEY_CTX> ctx(EVP_PKEY_CTX_new(key, nullptr));
|
2015-05-11 20:58:08 +01:00
|
|
|
if (!ctx || !key_op_init(ctx.get())) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
if (t->HasAttribute("Digest")) {
|
|
|
|
const EVP_MD *digest = GetDigest(t, t->GetAttributeOrDie("Digest"));
|
|
|
|
if (digest == nullptr ||
|
|
|
|
!EVP_PKEY_CTX_set_signature_md(ctx.get(), digest)) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (t->GetType() == "Verify") {
|
2015-11-11 22:01:27 +00:00
|
|
|
if (!EVP_PKEY_verify(ctx.get(), output.data(), output.size(), input.data(),
|
|
|
|
input.size())) {
|
2015-05-11 20:58:08 +01:00
|
|
|
// ECDSA sometimes doesn't push an error code. Push one on the error queue
|
|
|
|
// so it's distinguishable from other errors.
|
2015-06-29 05:28:17 +01:00
|
|
|
OPENSSL_PUT_ERROR(USER, ERR_R_EVP_LIB);
|
2015-05-11 20:58:08 +01:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
size_t len;
|
|
|
|
std::vector<uint8_t> actual;
|
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);
|
2015-11-11 22:01:27 +00:00
|
|
|
if (!key_op(ctx.get(), actual.data(), &len, input.data(), input.size())) {
|
2015-05-11 20:58:08 +01:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
actual.resize(len);
|
2015-11-11 22:01:27 +00:00
|
|
|
if (!t->ExpectBytesEqual(output.data(), output.size(), actual.data(), len)) {
|
2015-05-11 20:58:08 +01:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2016-12-07 03:35:41 +00:00
|
|
|
int main(int argc, char *argv[]) {
|
2015-05-11 20:58:08 +01:00
|
|
|
CRYPTO_library_init();
|
|
|
|
if (argc != 2) {
|
|
|
|
fprintf(stderr, "%s <test file.txt>\n", argv[0]);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2016-07-12 16:09:33 +01:00
|
|
|
KeyMap map;
|
|
|
|
return FileTestMain(TestEVP, &map, argv[1]);
|
2015-05-11 20:58:08 +01:00
|
|
|
}
|