Você não pode selecionar mais de 25 tópicos Os tópicos devem começar com uma letra ou um número, podem incluir traços ('-') e podem ter até 35 caracteres.

evp_test.cc 13 KiB

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>
8 anos atrás
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>
8 anos atrás
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>
8 anos atrás
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>
8 anos atrás
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>
8 anos atrás
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>
8 anos atrás
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>
8 anos atrás
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>
8 anos atrás
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>
8 anos atrás
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>
8 anos atrás
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>
8 anos atrás
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415
  1. /*
  2. * Written by Dr Stephen N Henson (steve@openssl.org) for the OpenSSL
  3. * project.
  4. */
  5. /* ====================================================================
  6. * Copyright (c) 2015 The OpenSSL Project. All rights reserved.
  7. *
  8. * Redistribution and use in source and binary forms, with or without
  9. * modification, are permitted provided that the following conditions
  10. * are met:
  11. *
  12. * 1. Redistributions of source code must retain the above copyright
  13. * notice, this list of conditions and the following disclaimer.
  14. *
  15. * 2. Redistributions in binary form must reproduce the above copyright
  16. * notice, this list of conditions and the following disclaimer in
  17. * the documentation and/or other materials provided with the
  18. * distribution.
  19. *
  20. * 3. All advertising materials mentioning features or use of this
  21. * software must display the following acknowledgment:
  22. * "This product includes software developed by the OpenSSL Project
  23. * for use in the OpenSSL Toolkit. (http://www.OpenSSL.org/)"
  24. *
  25. * 4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to
  26. * endorse or promote products derived from this software without
  27. * prior written permission. For written permission, please contact
  28. * licensing@OpenSSL.org.
  29. *
  30. * 5. Products derived from this software may not be called "OpenSSL"
  31. * nor may "OpenSSL" appear in their names without prior written
  32. * permission of the OpenSSL Project.
  33. *
  34. * 6. Redistributions of any form whatsoever must retain the following
  35. * acknowledgment:
  36. * "This product includes software developed by the OpenSSL Project
  37. * for use in the OpenSSL Toolkit (http://www.OpenSSL.org/)"
  38. *
  39. * THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY
  40. * EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  41. * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
  42. * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR
  43. * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
  44. * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
  45. * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
  46. * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
  47. * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
  48. * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
  49. * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
  50. * OF THE POSSIBILITY OF SUCH DAMAGE.
  51. * ====================================================================
  52. */
  53. #include <openssl/evp.h>
  54. #include <stdio.h>
  55. #include <stdint.h>
  56. #include <stdlib.h>
  57. #include <string.h>
  58. OPENSSL_MSVC_PRAGMA(warning(push))
  59. OPENSSL_MSVC_PRAGMA(warning(disable: 4702))
  60. #include <map>
  61. #include <string>
  62. #include <utility>
  63. #include <vector>
  64. OPENSSL_MSVC_PRAGMA(warning(pop))
  65. #include <gtest/gtest.h>
  66. #include <openssl/buf.h>
  67. #include <openssl/bytestring.h>
  68. #include <openssl/crypto.h>
  69. #include <openssl/digest.h>
  70. #include <openssl/err.h>
  71. #include <openssl/rsa.h>
  72. #include "../test/file_test.h"
  73. #include "../test/test_util.h"
  74. // evp_test dispatches between multiple test types. PrivateKey tests take a key
  75. // name parameter and single block, decode it as a PEM private key, and save it
  76. // under that key name. Decrypt, Sign, and Verify tests take a previously
  77. // imported key name as parameter and test their respective operations.
  78. static const EVP_MD *GetDigest(FileTest *t, const std::string &name) {
  79. if (name == "MD5") {
  80. return EVP_md5();
  81. } else if (name == "SHA1") {
  82. return EVP_sha1();
  83. } else if (name == "SHA224") {
  84. return EVP_sha224();
  85. } else if (name == "SHA256") {
  86. return EVP_sha256();
  87. } else if (name == "SHA384") {
  88. return EVP_sha384();
  89. } else if (name == "SHA512") {
  90. return EVP_sha512();
  91. }
  92. ADD_FAILURE() << "Unknown digest: " << name;
  93. return nullptr;
  94. }
  95. static int GetKeyType(FileTest *t, const std::string &name) {
  96. if (name == "RSA") {
  97. return EVP_PKEY_RSA;
  98. }
  99. if (name == "EC") {
  100. return EVP_PKEY_EC;
  101. }
  102. if (name == "DSA") {
  103. return EVP_PKEY_DSA;
  104. }
  105. if (name == "Ed25519") {
  106. return EVP_PKEY_ED25519;
  107. }
  108. ADD_FAILURE() << "Unknown key type: " << name;
  109. return EVP_PKEY_NONE;
  110. }
  111. static int GetRSAPadding(FileTest *t, int *out, const std::string &name) {
  112. if (name == "PKCS1") {
  113. *out = RSA_PKCS1_PADDING;
  114. return true;
  115. }
  116. if (name == "PSS") {
  117. *out = RSA_PKCS1_PSS_PADDING;
  118. return true;
  119. }
  120. if (name == "OAEP") {
  121. *out = RSA_PKCS1_OAEP_PADDING;
  122. return true;
  123. }
  124. ADD_FAILURE() << "Unknown RSA padding mode: " << name;
  125. return false;
  126. }
  127. using KeyMap = std::map<std::string, bssl::UniquePtr<EVP_PKEY>>;
  128. static bool ImportKey(FileTest *t, KeyMap *key_map,
  129. EVP_PKEY *(*parse_func)(CBS *cbs),
  130. int (*marshal_func)(CBB *cbb, const EVP_PKEY *key)) {
  131. std::vector<uint8_t> input;
  132. if (!t->GetBytes(&input, "Input")) {
  133. return false;
  134. }
  135. CBS cbs;
  136. CBS_init(&cbs, input.data(), input.size());
  137. bssl::UniquePtr<EVP_PKEY> pkey(parse_func(&cbs));
  138. if (!pkey) {
  139. return false;
  140. }
  141. std::string key_type;
  142. if (!t->GetAttribute(&key_type, "Type")) {
  143. return false;
  144. }
  145. EXPECT_EQ(GetKeyType(t, key_type), EVP_PKEY_id(pkey.get()));
  146. // The key must re-encode correctly.
  147. bssl::ScopedCBB cbb;
  148. uint8_t *der;
  149. size_t der_len;
  150. if (!CBB_init(cbb.get(), 0) ||
  151. !marshal_func(cbb.get(), pkey.get()) ||
  152. !CBB_finish(cbb.get(), &der, &der_len)) {
  153. return false;
  154. }
  155. bssl::UniquePtr<uint8_t> free_der(der);
  156. std::vector<uint8_t> output = input;
  157. if (t->HasAttribute("Output") &&
  158. !t->GetBytes(&output, "Output")) {
  159. return false;
  160. }
  161. EXPECT_EQ(Bytes(output), Bytes(der, der_len)) << "Re-encoding the key did not match.";
  162. // Save the key for future tests.
  163. const std::string &key_name = t->GetParameter();
  164. EXPECT_EQ(0u, key_map->count(key_name)) << "Duplicate key: " << key_name;
  165. (*key_map)[key_name] = std::move(pkey);
  166. return true;
  167. }
  168. // SetupContext configures |ctx| based on attributes in |t|, with the exception
  169. // of the signing digest which must be configured externally.
  170. static bool SetupContext(FileTest *t, EVP_PKEY_CTX *ctx) {
  171. if (t->HasAttribute("RSAPadding")) {
  172. int padding;
  173. if (!GetRSAPadding(t, &padding, t->GetAttributeOrDie("RSAPadding")) ||
  174. !EVP_PKEY_CTX_set_rsa_padding(ctx, padding)) {
  175. return false;
  176. }
  177. }
  178. if (t->HasAttribute("PSSSaltLength") &&
  179. !EVP_PKEY_CTX_set_rsa_pss_saltlen(
  180. ctx, atoi(t->GetAttributeOrDie("PSSSaltLength").c_str()))) {
  181. return false;
  182. }
  183. if (t->HasAttribute("MGF1Digest")) {
  184. const EVP_MD *digest = GetDigest(t, t->GetAttributeOrDie("MGF1Digest"));
  185. if (digest == nullptr || !EVP_PKEY_CTX_set_rsa_mgf1_md(ctx, digest)) {
  186. return false;
  187. }
  188. }
  189. if (t->HasAttribute("OAEPDigest")) {
  190. const EVP_MD *digest = GetDigest(t, t->GetAttributeOrDie("OAEPDigest"));
  191. if (digest == nullptr || !EVP_PKEY_CTX_set_rsa_oaep_md(ctx, digest)) {
  192. return false;
  193. }
  194. }
  195. if (t->HasAttribute("OAEPLabel")) {
  196. std::vector<uint8_t> label;
  197. if (!t->GetBytes(&label, "OAEPLabel")) {
  198. return false;
  199. }
  200. // For historical reasons, |EVP_PKEY_CTX_set0_rsa_oaep_label| expects to be
  201. // take ownership of the input.
  202. bssl::UniquePtr<uint8_t> buf(
  203. reinterpret_cast<uint8_t *>(BUF_memdup(label.data(), label.size())));
  204. if (!buf ||
  205. !EVP_PKEY_CTX_set0_rsa_oaep_label(ctx, buf.get(), label.size())) {
  206. return false;
  207. }
  208. buf.release();
  209. }
  210. return true;
  211. }
  212. static bool TestEVP(FileTest *t, KeyMap *key_map) {
  213. if (t->GetType() == "PrivateKey") {
  214. return ImportKey(t, key_map, EVP_parse_private_key,
  215. EVP_marshal_private_key);
  216. }
  217. if (t->GetType() == "PublicKey") {
  218. return ImportKey(t, key_map, EVP_parse_public_key, EVP_marshal_public_key);
  219. }
  220. int (*key_op_init)(EVP_PKEY_CTX *ctx) = nullptr;
  221. int (*key_op)(EVP_PKEY_CTX *ctx, uint8_t *out, size_t *out_len,
  222. const uint8_t *in, size_t in_len) = nullptr;
  223. int (*md_op_init)(EVP_MD_CTX * ctx, EVP_PKEY_CTX * *pctx, const EVP_MD *type,
  224. ENGINE *e, EVP_PKEY *pkey) = nullptr;
  225. bool is_verify = false;
  226. if (t->GetType() == "Decrypt") {
  227. key_op_init = EVP_PKEY_decrypt_init;
  228. key_op = EVP_PKEY_decrypt;
  229. } else if (t->GetType() == "Sign") {
  230. key_op_init = EVP_PKEY_sign_init;
  231. key_op = EVP_PKEY_sign;
  232. } else if (t->GetType() == "Verify") {
  233. key_op_init = EVP_PKEY_verify_init;
  234. is_verify = true;
  235. } else if (t->GetType() == "SignMessage") {
  236. md_op_init = EVP_DigestSignInit;
  237. } else if (t->GetType() == "VerifyMessage") {
  238. md_op_init = EVP_DigestVerifyInit;
  239. is_verify = true;
  240. } else if (t->GetType() == "Encrypt") {
  241. key_op_init = EVP_PKEY_encrypt_init;
  242. key_op = EVP_PKEY_encrypt;
  243. } else {
  244. ADD_FAILURE() << "Unknown test " << t->GetType();
  245. return false;
  246. }
  247. // Load the key.
  248. const std::string &key_name = t->GetParameter();
  249. if (key_map->count(key_name) == 0) {
  250. ADD_FAILURE() << "Could not find key " << key_name;
  251. return false;
  252. }
  253. EVP_PKEY *key = (*key_map)[key_name].get();
  254. const EVP_MD *digest = nullptr;
  255. if (t->HasAttribute("Digest")) {
  256. digest = GetDigest(t, t->GetAttributeOrDie("Digest"));
  257. if (digest == nullptr) {
  258. return false;
  259. }
  260. }
  261. // For verify tests, the "output" is the signature. Read it now so that, for
  262. // tests which expect a failure in SetupContext, the attribute is still
  263. // consumed.
  264. std::vector<uint8_t> input, actual, output;
  265. if (!t->GetBytes(&input, "Input") ||
  266. (is_verify && !t->GetBytes(&output, "Output"))) {
  267. return false;
  268. }
  269. if (md_op_init) {
  270. bssl::ScopedEVP_MD_CTX ctx;
  271. EVP_PKEY_CTX *pctx;
  272. if (!md_op_init(ctx.get(), &pctx, digest, nullptr, key) ||
  273. !SetupContext(t, pctx)) {
  274. return false;
  275. }
  276. if (is_verify) {
  277. return !!EVP_DigestVerify(ctx.get(), output.data(), output.size(),
  278. input.data(), input.size());
  279. }
  280. size_t len;
  281. if (!EVP_DigestSign(ctx.get(), nullptr, &len, input.data(), input.size())) {
  282. return false;
  283. }
  284. actual.resize(len);
  285. if (!EVP_DigestSign(ctx.get(), actual.data(), &len, input.data(),
  286. input.size()) ||
  287. !t->GetBytes(&output, "Output")) {
  288. return false;
  289. }
  290. actual.resize(len);
  291. EXPECT_EQ(Bytes(output), Bytes(actual));
  292. return true;
  293. }
  294. bssl::UniquePtr<EVP_PKEY_CTX> ctx(EVP_PKEY_CTX_new(key, nullptr));
  295. if (!ctx ||
  296. !key_op_init(ctx.get()) ||
  297. (digest != nullptr &&
  298. !EVP_PKEY_CTX_set_signature_md(ctx.get(), digest)) ||
  299. !SetupContext(t, ctx.get())) {
  300. return false;
  301. }
  302. if (is_verify) {
  303. return !!EVP_PKEY_verify(ctx.get(), output.data(), output.size(),
  304. input.data(), input.size());
  305. }
  306. size_t len;
  307. if (!key_op(ctx.get(), nullptr, &len, input.data(), input.size())) {
  308. return false;
  309. }
  310. actual.resize(len);
  311. if (!key_op(ctx.get(), actual.data(), &len, input.data(), input.size())) {
  312. return false;
  313. }
  314. // Encryption is non-deterministic, so we check by decrypting.
  315. if (t->HasAttribute("CheckDecrypt")) {
  316. size_t plaintext_len;
  317. ctx.reset(EVP_PKEY_CTX_new(key, nullptr));
  318. if (!ctx ||
  319. !EVP_PKEY_decrypt_init(ctx.get()) ||
  320. (digest != nullptr &&
  321. !EVP_PKEY_CTX_set_signature_md(ctx.get(), digest)) ||
  322. !SetupContext(t, ctx.get()) ||
  323. !EVP_PKEY_decrypt(ctx.get(), nullptr, &plaintext_len, actual.data(),
  324. actual.size())) {
  325. return false;
  326. }
  327. output.resize(plaintext_len);
  328. if (!EVP_PKEY_decrypt(ctx.get(), output.data(), &plaintext_len,
  329. actual.data(), actual.size())) {
  330. ADD_FAILURE() << "Could not decrypt result.";
  331. return false;
  332. }
  333. output.resize(plaintext_len);
  334. EXPECT_EQ(Bytes(input), Bytes(output)) << "Decrypted result mismatch.";
  335. return true;
  336. }
  337. // Some signature schemes are non-deterministic, so we check by verifying.
  338. if (t->HasAttribute("CheckVerify")) {
  339. ctx.reset(EVP_PKEY_CTX_new(key, nullptr));
  340. if (!ctx ||
  341. !EVP_PKEY_verify_init(ctx.get()) ||
  342. (digest != nullptr &&
  343. !EVP_PKEY_CTX_set_signature_md(ctx.get(), digest)) ||
  344. !SetupContext(t, ctx.get())) {
  345. return false;
  346. }
  347. if (t->HasAttribute("VerifyPSSSaltLength") &&
  348. !EVP_PKEY_CTX_set_rsa_pss_saltlen(
  349. ctx.get(),
  350. atoi(t->GetAttributeOrDie("VerifyPSSSaltLength").c_str()))) {
  351. return false;
  352. }
  353. EXPECT_TRUE(EVP_PKEY_verify(ctx.get(), actual.data(), actual.size(),
  354. input.data(), input.size()))
  355. << "Could not verify result.";
  356. return true;
  357. }
  358. // By default, check by comparing the result against Output.
  359. if (!t->GetBytes(&output, "Output")) {
  360. return false;
  361. }
  362. actual.resize(len);
  363. EXPECT_EQ(Bytes(output), Bytes(actual));
  364. return true;
  365. }
  366. TEST(EVPTest, TestVectors) {
  367. KeyMap key_map;
  368. FileTestGTest("crypto/evp/evp_tests.txt", [&](FileTest *t) {
  369. bool result = TestEVP(t, &key_map);
  370. if (t->HasAttribute("Error")) {
  371. ASSERT_FALSE(result) << "Operation unexpectedly succeeded.";
  372. uint32_t err = ERR_peek_error();
  373. EXPECT_EQ(t->GetAttributeOrDie("Error"), ERR_reason_error_string(err));
  374. } else if (!result) {
  375. ADD_FAILURE() << "Operation unexpectedly failed.";
  376. }
  377. });
  378. }