kris/boringssl
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
20422539b5
boringssl/crypto/evp/p_dsa_asn1.c

269 lines
7.7 KiB
C
Raw Normal View History

Add DSA support to EVP. Sadly, it turns out that we have need of this, at least for now. The code is taken from upstream and changed only as much as needed. This only imports keys and doesn't know how to actually perform operations on them for now. Change-Id: I0db70fb938186cb7a91d03f068b386c59ed90b84
2015-01-30 01:25:29 +00:00
/* Written by Dr Stephen N Henson (steve@openssl.org) for the OpenSSL project
* 2006.
*/
/* ====================================================================
* Copyright (c) 2006 The OpenSSL Project. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in
* the documentation and/or other materials provided with the
* distribution.
*
* 3. All advertising materials mentioning features or use of this
* software must display the following acknowledgment:
* "This product includes software developed by the OpenSSL Project
* for use in the OpenSSL Toolkit. (http://www.OpenSSL.org/)"
*
* 4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to
* endorse or promote products derived from this software without
* prior written permission. For written permission, please contact
* licensing@OpenSSL.org.
*
* 5. Products derived from this software may not be called "OpenSSL"
* nor may "OpenSSL" appear in their names without prior written
* permission of the OpenSSL Project.
*
* 6. Redistributions of any form whatsoever must retain the following
* acknowledgment:
* "This product includes software developed by the OpenSSL Project
* for use in the OpenSSL Toolkit (http://www.OpenSSL.org/)"
*
* THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY
* EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
* PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
* NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
* LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
* STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
* OF THE POSSIBILITY OF SUCH DAMAGE.
* ====================================================================
*
* This product includes cryptographic software written by Eric Young
* (eay@cryptsoft.com). This product includes software written by Tim
* Hudson (tjh@cryptsoft.com). */
#include <openssl/evp.h>
#include <openssl/digest.h>
Implement new PKCS#8 parsers. As with SPKI parsers, the intent is make EVP_PKEY capture the key's constraints in full fidelity, so we'd have to add new types or store the information in the underlying key object if people introduce variant key types with weird constraints on them. Note that because PKCS#8 has a space for arbitrary attributes, this parser must admit a hole. I'm assuming for now that we don't need an API that enforces no attributes and just ignore trailing data in the structure for simplicity. BUG=499653 Change-Id: I6fc641355e87136c7220f5d7693566d1144a68e8 Reviewed-on: https://boringssl-review.googlesource.com/6866 Reviewed-by: Adam Langley <agl@google.com>
2016-01-01 06:17:30 +00:00
#include <openssl/bn.h>
#include <openssl/bytestring.h>
Add DSA support to EVP. Sadly, it turns out that we have need of this, at least for now. The code is taken from upstream and changed only as much as needed. This only imports keys and doesn't know how to actually perform operations on them for now. Change-Id: I0db70fb938186cb7a91d03f068b386c59ed90b84
2015-01-30 01:25:29 +00:00
#include <openssl/dsa.h>
#include <openssl/err.h>
#include "internal.h"
Implement new SPKI parsers. Many consumers need SPKI support (X.509, TLS, QUIC, WebCrypto), each with different ways to set signature parameters. SPKIs themselves can get complex with id-RSASSA-PSS keys which come with various constraints in the key parameters. This suggests we want a common in-library representation of an SPKI. This adds two new functions EVP_parse_public_key and EVP_marshal_public_key which converts EVP_PKEY to and from SPKI and implements X509_PUBKEY functions with them. EVP_PKEY seems to have been intended to be able to express the supported SPKI types with full-fidelity, so these APIs will continue this. This means future support for id-RSASSA-PSS would *not* repurpose EVP_PKEY_RSA. I'm worried about code assuming EVP_PKEY_RSA implies acting on the RSA* is legal. Instead, it'd add an EVP_PKEY_RSA_PSS and the data pointer would be some (exposed, so the caller may still check key size, etc.) RSA_PSS_KEY struct. Internally, the EVP_PKEY_CTX implementation would enforce the key constraints. If RSA_PSS_KEY would later need its own API, that code would move there, but that seems unlikely. Ideally we'd have a 1:1 correspondence with key OID, although we may have to fudge things if mistakes happen in standardization. (Whether or not X.509 reuses id-ecPublicKey for Ed25519, we'll give it a separate EVP_PKEY type.) DSA parsing hooks are still implemented, missing parameters and all for now. This isn't any worse than before. Decoupling from the giant crypto/obj OID table will be a later task. BUG=522228 Change-Id: I0e3964edf20cb795a18b0991d17e5ca8bce3e28c Reviewed-on: https://boringssl-review.googlesource.com/6861 Reviewed-by: Adam Langley <agl@google.com>
2015-12-31 02:40:40 +00:00
static int dsa_pub_decode(EVP_PKEY *out, CBS *params, CBS *key) {
/* See RFC 3279, section 2.3.2. */
Add DSA support to EVP. Sadly, it turns out that we have need of this, at least for now. The code is taken from upstream and changed only as much as needed. This only imports keys and doesn't know how to actually perform operations on them for now. Change-Id: I0db70fb938186cb7a91d03f068b386c59ed90b84
2015-01-30 01:25:29 +00:00
Implement new SPKI parsers. Many consumers need SPKI support (X.509, TLS, QUIC, WebCrypto), each with different ways to set signature parameters. SPKIs themselves can get complex with id-RSASSA-PSS keys which come with various constraints in the key parameters. This suggests we want a common in-library representation of an SPKI. This adds two new functions EVP_parse_public_key and EVP_marshal_public_key which converts EVP_PKEY to and from SPKI and implements X509_PUBKEY functions with them. EVP_PKEY seems to have been intended to be able to express the supported SPKI types with full-fidelity, so these APIs will continue this. This means future support for id-RSASSA-PSS would *not* repurpose EVP_PKEY_RSA. I'm worried about code assuming EVP_PKEY_RSA implies acting on the RSA* is legal. Instead, it'd add an EVP_PKEY_RSA_PSS and the data pointer would be some (exposed, so the caller may still check key size, etc.) RSA_PSS_KEY struct. Internally, the EVP_PKEY_CTX implementation would enforce the key constraints. If RSA_PSS_KEY would later need its own API, that code would move there, but that seems unlikely. Ideally we'd have a 1:1 correspondence with key OID, although we may have to fudge things if mistakes happen in standardization. (Whether or not X.509 reuses id-ecPublicKey for Ed25519, we'll give it a separate EVP_PKEY type.) DSA parsing hooks are still implemented, missing parameters and all for now. This isn't any worse than before. Decoupling from the giant crypto/obj OID table will be a later task. BUG=522228 Change-Id: I0e3964edf20cb795a18b0991d17e5ca8bce3e28c Reviewed-on: https://boringssl-review.googlesource.com/6861 Reviewed-by: Adam Langley <agl@google.com>
2015-12-31 02:40:40 +00:00
/* Parameters may or may not be present. */
DSA *dsa;
if (CBS_len(params) == 0) {
Add DSA support to EVP. Sadly, it turns out that we have need of this, at least for now. The code is taken from upstream and changed only as much as needed. This only imports keys and doesn't know how to actually perform operations on them for now. Change-Id: I0db70fb938186cb7a91d03f068b386c59ed90b84
2015-01-30 01:25:29 +00:00
dsa = DSA_new();
if (dsa == NULL) {
Implement new SPKI parsers. Many consumers need SPKI support (X.509, TLS, QUIC, WebCrypto), each with different ways to set signature parameters. SPKIs themselves can get complex with id-RSASSA-PSS keys which come with various constraints in the key parameters. This suggests we want a common in-library representation of an SPKI. This adds two new functions EVP_parse_public_key and EVP_marshal_public_key which converts EVP_PKEY to and from SPKI and implements X509_PUBKEY functions with them. EVP_PKEY seems to have been intended to be able to express the supported SPKI types with full-fidelity, so these APIs will continue this. This means future support for id-RSASSA-PSS would *not* repurpose EVP_PKEY_RSA. I'm worried about code assuming EVP_PKEY_RSA implies acting on the RSA* is legal. Instead, it'd add an EVP_PKEY_RSA_PSS and the data pointer would be some (exposed, so the caller may still check key size, etc.) RSA_PSS_KEY struct. Internally, the EVP_PKEY_CTX implementation would enforce the key constraints. If RSA_PSS_KEY would later need its own API, that code would move there, but that seems unlikely. Ideally we'd have a 1:1 correspondence with key OID, although we may have to fudge things if mistakes happen in standardization. (Whether or not X.509 reuses id-ecPublicKey for Ed25519, we'll give it a separate EVP_PKEY type.) DSA parsing hooks are still implemented, missing parameters and all for now. This isn't any worse than before. Decoupling from the giant crypto/obj OID table will be a later task. BUG=522228 Change-Id: I0e3964edf20cb795a18b0991d17e5ca8bce3e28c Reviewed-on: https://boringssl-review.googlesource.com/6861 Reviewed-by: Adam Langley <agl@google.com>
2015-12-31 02:40:40 +00:00
return 0;
Add DSA support to EVP. Sadly, it turns out that we have need of this, at least for now. The code is taken from upstream and changed only as much as needed. This only imports keys and doesn't know how to actually perform operations on them for now. Change-Id: I0db70fb938186cb7a91d03f068b386c59ed90b84
2015-01-30 01:25:29 +00:00
}
} else {
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
dsa = DSA_parse_parameters(params);
if (dsa == NULL || CBS_len(params) != 0) {
OPENSSL_PUT_ERROR(EVP, EVP_R_DECODE_ERROR);
goto err;
}
Add DSA support to EVP. Sadly, it turns out that we have need of this, at least for now. The code is taken from upstream and changed only as much as needed. This only imports keys and doesn't know how to actually perform operations on them for now. Change-Id: I0db70fb938186cb7a91d03f068b386c59ed90b84
2015-01-30 01:25:29 +00:00
}
Implement new SPKI parsers. Many consumers need SPKI support (X.509, TLS, QUIC, WebCrypto), each with different ways to set signature parameters. SPKIs themselves can get complex with id-RSASSA-PSS keys which come with various constraints in the key parameters. This suggests we want a common in-library representation of an SPKI. This adds two new functions EVP_parse_public_key and EVP_marshal_public_key which converts EVP_PKEY to and from SPKI and implements X509_PUBKEY functions with them. EVP_PKEY seems to have been intended to be able to express the supported SPKI types with full-fidelity, so these APIs will continue this. This means future support for id-RSASSA-PSS would *not* repurpose EVP_PKEY_RSA. I'm worried about code assuming EVP_PKEY_RSA implies acting on the RSA* is legal. Instead, it'd add an EVP_PKEY_RSA_PSS and the data pointer would be some (exposed, so the caller may still check key size, etc.) RSA_PSS_KEY struct. Internally, the EVP_PKEY_CTX implementation would enforce the key constraints. If RSA_PSS_KEY would later need its own API, that code would move there, but that seems unlikely. Ideally we'd have a 1:1 correspondence with key OID, although we may have to fudge things if mistakes happen in standardization. (Whether or not X.509 reuses id-ecPublicKey for Ed25519, we'll give it a separate EVP_PKEY type.) DSA parsing hooks are still implemented, missing parameters and all for now. This isn't any worse than before. Decoupling from the giant crypto/obj OID table will be a later task. BUG=522228 Change-Id: I0e3964edf20cb795a18b0991d17e5ca8bce3e28c Reviewed-on: https://boringssl-review.googlesource.com/6861 Reviewed-by: Adam Langley <agl@google.com>
2015-12-31 02:40:40 +00:00
dsa->pub_key = BN_new();
if (dsa->pub_key == NULL) {
Add DSA support to EVP. Sadly, it turns out that we have need of this, at least for now. The code is taken from upstream and changed only as much as needed. This only imports keys and doesn't know how to actually perform operations on them for now. Change-Id: I0db70fb938186cb7a91d03f068b386c59ed90b84
2015-01-30 01:25:29 +00:00
goto err;
}
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 (!BN_parse_asn1_unsigned(key, dsa->pub_key) ||
CBS_len(key) != 0) {
OPENSSL_PUT_ERROR(EVP, EVP_R_DECODE_ERROR);
Add DSA support to EVP. Sadly, it turns out that we have need of this, at least for now. The code is taken from upstream and changed only as much as needed. This only imports keys and doesn't know how to actually perform operations on them for now. Change-Id: I0db70fb938186cb7a91d03f068b386c59ed90b84
2015-01-30 01:25:29 +00:00
goto err;
}
Implement new SPKI parsers. Many consumers need SPKI support (X.509, TLS, QUIC, WebCrypto), each with different ways to set signature parameters. SPKIs themselves can get complex with id-RSASSA-PSS keys which come with various constraints in the key parameters. This suggests we want a common in-library representation of an SPKI. This adds two new functions EVP_parse_public_key and EVP_marshal_public_key which converts EVP_PKEY to and from SPKI and implements X509_PUBKEY functions with them. EVP_PKEY seems to have been intended to be able to express the supported SPKI types with full-fidelity, so these APIs will continue this. This means future support for id-RSASSA-PSS would *not* repurpose EVP_PKEY_RSA. I'm worried about code assuming EVP_PKEY_RSA implies acting on the RSA* is legal. Instead, it'd add an EVP_PKEY_RSA_PSS and the data pointer would be some (exposed, so the caller may still check key size, etc.) RSA_PSS_KEY struct. Internally, the EVP_PKEY_CTX implementation would enforce the key constraints. If RSA_PSS_KEY would later need its own API, that code would move there, but that seems unlikely. Ideally we'd have a 1:1 correspondence with key OID, although we may have to fudge things if mistakes happen in standardization. (Whether or not X.509 reuses id-ecPublicKey for Ed25519, we'll give it a separate EVP_PKEY type.) DSA parsing hooks are still implemented, missing parameters and all for now. This isn't any worse than before. Decoupling from the giant crypto/obj OID table will be a later task. BUG=522228 Change-Id: I0e3964edf20cb795a18b0991d17e5ca8bce3e28c Reviewed-on: https://boringssl-review.googlesource.com/6861 Reviewed-by: Adam Langley <agl@google.com>
2015-12-31 02:40:40 +00:00
EVP_PKEY_assign_DSA(out, dsa);
Add DSA support to EVP. Sadly, it turns out that we have need of this, at least for now. The code is taken from upstream and changed only as much as needed. This only imports keys and doesn't know how to actually perform operations on them for now. Change-Id: I0db70fb938186cb7a91d03f068b386c59ed90b84
2015-01-30 01:25:29 +00:00
return 1;
err:
Remove unnecessary NULL checks, part 3. Finish up the e's. Change-Id: Iabb8da000fbca6efee541edb469b90896f60d54b Reviewed-on: https://boringssl-review.googlesource.com/4516 Reviewed-by: Adam Langley <agl@google.com>
2015-04-22 20:49:27 +01:00
DSA_free(dsa);
Add DSA support to EVP. Sadly, it turns out that we have need of this, at least for now. The code is taken from upstream and changed only as much as needed. This only imports keys and doesn't know how to actually perform operations on them for now. Change-Id: I0db70fb938186cb7a91d03f068b386c59ed90b84
2015-01-30 01:25:29 +00:00
return 0;
}
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 dsa_pub_encode(CBB *out, const EVP_PKEY *key) {
const DSA *dsa = key->pkey.dsa;
const int has_params = dsa->p != NULL && dsa->q != NULL && dsa->g != NULL;
/* See RFC 5480, section 2. */
Decouple crypto/evp from the OID table. BUG=chromium:499653 Change-Id: I4e8d4af3129dbf61d4a8846ec9db685e83999d5e Reviewed-on: https://boringssl-review.googlesource.com/7565 Reviewed-by: Steven Valdez <svaldez@google.com> Reviewed-by: David Benjamin <davidben@google.com>
2016-03-25 22:07:16 +00:00
CBB spki, algorithm, oid, key_bitstring;
Implement new SPKI parsers. Many consumers need SPKI support (X.509, TLS, QUIC, WebCrypto), each with different ways to set signature parameters. SPKIs themselves can get complex with id-RSASSA-PSS keys which come with various constraints in the key parameters. This suggests we want a common in-library representation of an SPKI. This adds two new functions EVP_parse_public_key and EVP_marshal_public_key which converts EVP_PKEY to and from SPKI and implements X509_PUBKEY functions with them. EVP_PKEY seems to have been intended to be able to express the supported SPKI types with full-fidelity, so these APIs will continue this. This means future support for id-RSASSA-PSS would *not* repurpose EVP_PKEY_RSA. I'm worried about code assuming EVP_PKEY_RSA implies acting on the RSA* is legal. Instead, it'd add an EVP_PKEY_RSA_PSS and the data pointer would be some (exposed, so the caller may still check key size, etc.) RSA_PSS_KEY struct. Internally, the EVP_PKEY_CTX implementation would enforce the key constraints. If RSA_PSS_KEY would later need its own API, that code would move there, but that seems unlikely. Ideally we'd have a 1:1 correspondence with key OID, although we may have to fudge things if mistakes happen in standardization. (Whether or not X.509 reuses id-ecPublicKey for Ed25519, we'll give it a separate EVP_PKEY type.) DSA parsing hooks are still implemented, missing parameters and all for now. This isn't any worse than before. Decoupling from the giant crypto/obj OID table will be a later task. BUG=522228 Change-Id: I0e3964edf20cb795a18b0991d17e5ca8bce3e28c Reviewed-on: https://boringssl-review.googlesource.com/6861 Reviewed-by: Adam Langley <agl@google.com>
2015-12-31 02:40:40 +00:00
if (!CBB_add_asn1(out, &spki, CBS_ASN1_SEQUENCE) ||
!CBB_add_asn1(&spki, &algorithm, CBS_ASN1_SEQUENCE) ||
Decouple crypto/evp from the OID table. BUG=chromium:499653 Change-Id: I4e8d4af3129dbf61d4a8846ec9db685e83999d5e Reviewed-on: https://boringssl-review.googlesource.com/7565 Reviewed-by: Steven Valdez <svaldez@google.com> Reviewed-by: David Benjamin <davidben@google.com>
2016-03-25 22:07:16 +00:00
!CBB_add_asn1(&algorithm, &oid, CBS_ASN1_OBJECT) ||
!CBB_add_bytes(&oid, dsa_asn1_meth.oid, dsa_asn1_meth.oid_len) ||
Implement new SPKI parsers. Many consumers need SPKI support (X.509, TLS, QUIC, WebCrypto), each with different ways to set signature parameters. SPKIs themselves can get complex with id-RSASSA-PSS keys which come with various constraints in the key parameters. This suggests we want a common in-library representation of an SPKI. This adds two new functions EVP_parse_public_key and EVP_marshal_public_key which converts EVP_PKEY to and from SPKI and implements X509_PUBKEY functions with them. EVP_PKEY seems to have been intended to be able to express the supported SPKI types with full-fidelity, so these APIs will continue this. This means future support for id-RSASSA-PSS would *not* repurpose EVP_PKEY_RSA. I'm worried about code assuming EVP_PKEY_RSA implies acting on the RSA* is legal. Instead, it'd add an EVP_PKEY_RSA_PSS and the data pointer would be some (exposed, so the caller may still check key size, etc.) RSA_PSS_KEY struct. Internally, the EVP_PKEY_CTX implementation would enforce the key constraints. If RSA_PSS_KEY would later need its own API, that code would move there, but that seems unlikely. Ideally we'd have a 1:1 correspondence with key OID, although we may have to fudge things if mistakes happen in standardization. (Whether or not X.509 reuses id-ecPublicKey for Ed25519, we'll give it a separate EVP_PKEY type.) DSA parsing hooks are still implemented, missing parameters and all for now. This isn't any worse than before. Decoupling from the giant crypto/obj OID table will be a later task. BUG=522228 Change-Id: I0e3964edf20cb795a18b0991d17e5ca8bce3e28c Reviewed-on: https://boringssl-review.googlesource.com/6861 Reviewed-by: Adam Langley <agl@google.com>
2015-12-31 02:40:40 +00:00
(has_params &&
!DSA_marshal_parameters(&algorithm, dsa)) ||
!CBB_add_asn1(&spki, &key_bitstring, CBS_ASN1_BITSTRING) ||
!CBB_add_u8(&key_bitstring, 0 /* padding */) ||
!BN_marshal_asn1(&key_bitstring, dsa->pub_key) ||
!CBB_flush(out)) {
OPENSSL_PUT_ERROR(EVP, EVP_R_ENCODE_ERROR);
return 0;
Add DSA support to EVP. Sadly, it turns out that we have need of this, at least for now. The code is taken from upstream and changed only as much as needed. This only imports keys and doesn't know how to actually perform operations on them for now. Change-Id: I0db70fb938186cb7a91d03f068b386c59ed90b84
2015-01-30 01:25:29 +00:00
}
Implement new SPKI parsers. Many consumers need SPKI support (X.509, TLS, QUIC, WebCrypto), each with different ways to set signature parameters. SPKIs themselves can get complex with id-RSASSA-PSS keys which come with various constraints in the key parameters. This suggests we want a common in-library representation of an SPKI. This adds two new functions EVP_parse_public_key and EVP_marshal_public_key which converts EVP_PKEY to and from SPKI and implements X509_PUBKEY functions with them. EVP_PKEY seems to have been intended to be able to express the supported SPKI types with full-fidelity, so these APIs will continue this. This means future support for id-RSASSA-PSS would *not* repurpose EVP_PKEY_RSA. I'm worried about code assuming EVP_PKEY_RSA implies acting on the RSA* is legal. Instead, it'd add an EVP_PKEY_RSA_PSS and the data pointer would be some (exposed, so the caller may still check key size, etc.) RSA_PSS_KEY struct. Internally, the EVP_PKEY_CTX implementation would enforce the key constraints. If RSA_PSS_KEY would later need its own API, that code would move there, but that seems unlikely. Ideally we'd have a 1:1 correspondence with key OID, although we may have to fudge things if mistakes happen in standardization. (Whether or not X.509 reuses id-ecPublicKey for Ed25519, we'll give it a separate EVP_PKEY type.) DSA parsing hooks are still implemented, missing parameters and all for now. This isn't any worse than before. Decoupling from the giant crypto/obj OID table will be a later task. BUG=522228 Change-Id: I0e3964edf20cb795a18b0991d17e5ca8bce3e28c Reviewed-on: https://boringssl-review.googlesource.com/6861 Reviewed-by: Adam Langley <agl@google.com>
2015-12-31 02:40:40 +00:00
return 1;
Add DSA support to EVP. Sadly, it turns out that we have need of this, at least for now. The code is taken from upstream and changed only as much as needed. This only imports keys and doesn't know how to actually perform operations on them for now. Change-Id: I0db70fb938186cb7a91d03f068b386c59ed90b84
2015-01-30 01:25:29 +00:00
}
Implement new PKCS#8 parsers. As with SPKI parsers, the intent is make EVP_PKEY capture the key's constraints in full fidelity, so we'd have to add new types or store the information in the underlying key object if people introduce variant key types with weird constraints on them. Note that because PKCS#8 has a space for arbitrary attributes, this parser must admit a hole. I'm assuming for now that we don't need an API that enforces no attributes and just ignore trailing data in the structure for simplicity. BUG=499653 Change-Id: I6fc641355e87136c7220f5d7693566d1144a68e8 Reviewed-on: https://boringssl-review.googlesource.com/6866 Reviewed-by: Adam Langley <agl@google.com>
2016-01-01 06:17:30 +00:00
static int dsa_priv_decode(EVP_PKEY *out, CBS *params, CBS *key) {
/* See PKCS#11, v2.40, section 2.5. */
Add DSA support to EVP. Sadly, it turns out that we have need of this, at least for now. The code is taken from upstream and changed only as much as needed. This only imports keys and doesn't know how to actually perform operations on them for now. Change-Id: I0db70fb938186cb7a91d03f068b386c59ed90b84
2015-01-30 01:25:29 +00:00
Implement new PKCS#8 parsers. As with SPKI parsers, the intent is make EVP_PKEY capture the key's constraints in full fidelity, so we'd have to add new types or store the information in the underlying key object if people introduce variant key types with weird constraints on them. Note that because PKCS#8 has a space for arbitrary attributes, this parser must admit a hole. I'm assuming for now that we don't need an API that enforces no attributes and just ignore trailing data in the structure for simplicity. BUG=499653 Change-Id: I6fc641355e87136c7220f5d7693566d1144a68e8 Reviewed-on: https://boringssl-review.googlesource.com/6866 Reviewed-by: Adam Langley <agl@google.com>
2016-01-01 06:17:30 +00:00
/* Decode parameters. */
BN_CTX *ctx = NULL;
DSA *dsa = DSA_parse_parameters(params);
if (dsa == NULL || CBS_len(params) != 0) {
OPENSSL_PUT_ERROR(EVP, EVP_R_DECODE_ERROR);
goto err;
Add DSA support to EVP. Sadly, it turns out that we have need of this, at least for now. The code is taken from upstream and changed only as much as needed. This only imports keys and doesn't know how to actually perform operations on them for now. Change-Id: I0db70fb938186cb7a91d03f068b386c59ed90b84
2015-01-30 01:25:29 +00:00
}
Implement new PKCS#8 parsers. As with SPKI parsers, the intent is make EVP_PKEY capture the key's constraints in full fidelity, so we'd have to add new types or store the information in the underlying key object if people introduce variant key types with weird constraints on them. Note that because PKCS#8 has a space for arbitrary attributes, this parser must admit a hole. I'm assuming for now that we don't need an API that enforces no attributes and just ignore trailing data in the structure for simplicity. BUG=499653 Change-Id: I6fc641355e87136c7220f5d7693566d1144a68e8 Reviewed-on: https://boringssl-review.googlesource.com/6866 Reviewed-by: Adam Langley <agl@google.com>
2016-01-01 06:17:30 +00:00
dsa->priv_key = BN_new();
Add DSA support to EVP. Sadly, it turns out that we have need of this, at least for now. The code is taken from upstream and changed only as much as needed. This only imports keys and doesn't know how to actually perform operations on them for now. Change-Id: I0db70fb938186cb7a91d03f068b386c59ed90b84
2015-01-30 01:25:29 +00:00
dsa->pub_key = BN_new();
Implement new PKCS#8 parsers. As with SPKI parsers, the intent is make EVP_PKEY capture the key's constraints in full fidelity, so we'd have to add new types or store the information in the underlying key object if people introduce variant key types with weird constraints on them. Note that because PKCS#8 has a space for arbitrary attributes, this parser must admit a hole. I'm assuming for now that we don't need an API that enforces no attributes and just ignore trailing data in the structure for simplicity. BUG=499653 Change-Id: I6fc641355e87136c7220f5d7693566d1144a68e8 Reviewed-on: https://boringssl-review.googlesource.com/6866 Reviewed-by: Adam Langley <agl@google.com>
2016-01-01 06:17:30 +00:00
if (dsa->priv_key == NULL || dsa->pub_key == NULL) {
goto err;
Add DSA support to EVP. Sadly, it turns out that we have need of this, at least for now. The code is taken from upstream and changed only as much as needed. This only imports keys and doesn't know how to actually perform operations on them for now. Change-Id: I0db70fb938186cb7a91d03f068b386c59ed90b84
2015-01-30 01:25:29 +00:00
}
Implement new PKCS#8 parsers. As with SPKI parsers, the intent is make EVP_PKEY capture the key's constraints in full fidelity, so we'd have to add new types or store the information in the underlying key object if people introduce variant key types with weird constraints on them. Note that because PKCS#8 has a space for arbitrary attributes, this parser must admit a hole. I'm assuming for now that we don't need an API that enforces no attributes and just ignore trailing data in the structure for simplicity. BUG=499653 Change-Id: I6fc641355e87136c7220f5d7693566d1144a68e8 Reviewed-on: https://boringssl-review.googlesource.com/6866 Reviewed-by: Adam Langley <agl@google.com>
2016-01-01 06:17:30 +00:00
/* Decode the key. */
if (!BN_parse_asn1_unsigned(key, dsa->priv_key) ||
CBS_len(key) != 0) {
OPENSSL_PUT_ERROR(EVP, EVP_R_DECODE_ERROR);
goto err;
Add DSA support to EVP. Sadly, it turns out that we have need of this, at least for now. The code is taken from upstream and changed only as much as needed. This only imports keys and doesn't know how to actually perform operations on them for now. Change-Id: I0db70fb938186cb7a91d03f068b386c59ed90b84
2015-01-30 01:25:29 +00:00
}
Implement new PKCS#8 parsers. As with SPKI parsers, the intent is make EVP_PKEY capture the key's constraints in full fidelity, so we'd have to add new types or store the information in the underlying key object if people introduce variant key types with weird constraints on them. Note that because PKCS#8 has a space for arbitrary attributes, this parser must admit a hole. I'm assuming for now that we don't need an API that enforces no attributes and just ignore trailing data in the structure for simplicity. BUG=499653 Change-Id: I6fc641355e87136c7220f5d7693566d1144a68e8 Reviewed-on: https://boringssl-review.googlesource.com/6866 Reviewed-by: Adam Langley <agl@google.com>
2016-01-01 06:17:30 +00:00
/* Calculate the public key. */
ctx = BN_CTX_new();
if (ctx == NULL ||
Remove direct calls to BN_mod_exp. Within the library, we never need to exponentiate modulo an even number. In fact, all the remaining BN_mod_exp calls are modulo an odd prime. This extends 617804adc5cd6760a3febcd9d4408fbfc6ebcd0c to the rest of the library. Change-Id: I4273439faa6a516c99673b28f8ae38ddfff7e42d Reviewed-on: https://boringssl-review.googlesource.com/14024 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
2017-02-28 01:27:58 +00:00
!BN_mod_exp_mont(dsa->pub_key, dsa->g, dsa->priv_key, dsa->p, ctx,
NULL)) {
Implement new PKCS#8 parsers. As with SPKI parsers, the intent is make EVP_PKEY capture the key's constraints in full fidelity, so we'd have to add new types or store the information in the underlying key object if people introduce variant key types with weird constraints on them. Note that because PKCS#8 has a space for arbitrary attributes, this parser must admit a hole. I'm assuming for now that we don't need an API that enforces no attributes and just ignore trailing data in the structure for simplicity. BUG=499653 Change-Id: I6fc641355e87136c7220f5d7693566d1144a68e8 Reviewed-on: https://boringssl-review.googlesource.com/6866 Reviewed-by: Adam Langley <agl@google.com>
2016-01-01 06:17:30 +00:00
goto err;
Add DSA support to EVP. Sadly, it turns out that we have need of this, at least for now. The code is taken from upstream and changed only as much as needed. This only imports keys and doesn't know how to actually perform operations on them for now. Change-Id: I0db70fb938186cb7a91d03f068b386c59ed90b84
2015-01-30 01:25:29 +00:00
}
BN_CTX_free(ctx);
Implement new PKCS#8 parsers. As with SPKI parsers, the intent is make EVP_PKEY capture the key's constraints in full fidelity, so we'd have to add new types or store the information in the underlying key object if people introduce variant key types with weird constraints on them. Note that because PKCS#8 has a space for arbitrary attributes, this parser must admit a hole. I'm assuming for now that we don't need an API that enforces no attributes and just ignore trailing data in the structure for simplicity. BUG=499653 Change-Id: I6fc641355e87136c7220f5d7693566d1144a68e8 Reviewed-on: https://boringssl-review.googlesource.com/6866 Reviewed-by: Adam Langley <agl@google.com>
2016-01-01 06:17:30 +00:00
EVP_PKEY_assign_DSA(out, dsa);
Add DSA support to EVP. Sadly, it turns out that we have need of this, at least for now. The code is taken from upstream and changed only as much as needed. This only imports keys and doesn't know how to actually perform operations on them for now. Change-Id: I0db70fb938186cb7a91d03f068b386c59ed90b84
2015-01-30 01:25:29 +00:00
return 1;
Implement new PKCS#8 parsers. As with SPKI parsers, the intent is make EVP_PKEY capture the key's constraints in full fidelity, so we'd have to add new types or store the information in the underlying key object if people introduce variant key types with weird constraints on them. Note that because PKCS#8 has a space for arbitrary attributes, this parser must admit a hole. I'm assuming for now that we don't need an API that enforces no attributes and just ignore trailing data in the structure for simplicity. BUG=499653 Change-Id: I6fc641355e87136c7220f5d7693566d1144a68e8 Reviewed-on: https://boringssl-review.googlesource.com/6866 Reviewed-by: Adam Langley <agl@google.com>
2016-01-01 06:17:30 +00:00
err:
Add DSA support to EVP. Sadly, it turns out that we have need of this, at least for now. The code is taken from upstream and changed only as much as needed. This only imports keys and doesn't know how to actually perform operations on them for now. Change-Id: I0db70fb938186cb7a91d03f068b386c59ed90b84
2015-01-30 01:25:29 +00:00
BN_CTX_free(ctx);
DSA_free(dsa);
return 0;
}
Implement new PKCS#8 parsers. As with SPKI parsers, the intent is make EVP_PKEY capture the key's constraints in full fidelity, so we'd have to add new types or store the information in the underlying key object if people introduce variant key types with weird constraints on them. Note that because PKCS#8 has a space for arbitrary attributes, this parser must admit a hole. I'm assuming for now that we don't need an API that enforces no attributes and just ignore trailing data in the structure for simplicity. BUG=499653 Change-Id: I6fc641355e87136c7220f5d7693566d1144a68e8 Reviewed-on: https://boringssl-review.googlesource.com/6866 Reviewed-by: Adam Langley <agl@google.com>
2016-01-01 06:17:30 +00:00
static int dsa_priv_encode(CBB *out, const EVP_PKEY *key) {
const DSA *dsa = key->pkey.dsa;
if (dsa == NULL || dsa->priv_key == NULL) {
Remove the func parameter to OPENSSL_PUT_ERROR. Much of this was done automatically with find . -name '*.c' | xargs sed -E -i '' -e 's/(OPENSSL_PUT_ERROR\([a-zA-Z_0-9]+, )[a-zA-Z_0-9]+, ([a-zA-Z_0-9]+\);)/\1\2/' find . -name '*.c' | xargs sed -E -i '' -e 's/(OPENSSL_PUT_ERROR\([a-zA-Z_0-9]+, )[a-zA-Z_0-9]+, ([a-zA-Z_0-9]+\);)/\1\2/' BUG=468039 Change-Id: I4c75fd95dff85ab1d4a546b05e6aed1aeeb499d8 Reviewed-on: https://boringssl-review.googlesource.com/5276 Reviewed-by: Adam Langley <agl@google.com>
2015-06-29 05:28:17 +01:00
OPENSSL_PUT_ERROR(EVP, EVP_R_MISSING_PARAMETERS);
Implement new PKCS#8 parsers. As with SPKI parsers, the intent is make EVP_PKEY capture the key's constraints in full fidelity, so we'd have to add new types or store the information in the underlying key object if people introduce variant key types with weird constraints on them. Note that because PKCS#8 has a space for arbitrary attributes, this parser must admit a hole. I'm assuming for now that we don't need an API that enforces no attributes and just ignore trailing data in the structure for simplicity. BUG=499653 Change-Id: I6fc641355e87136c7220f5d7693566d1144a68e8 Reviewed-on: https://boringssl-review.googlesource.com/6866 Reviewed-by: Adam Langley <agl@google.com>
2016-01-01 06:17:30 +00:00
return 0;
Add DSA support to EVP. Sadly, it turns out that we have need of this, at least for now. The code is taken from upstream and changed only as much as needed. This only imports keys and doesn't know how to actually perform operations on them for now. Change-Id: I0db70fb938186cb7a91d03f068b386c59ed90b84
2015-01-30 01:25:29 +00:00
}
Implement new PKCS#8 parsers. As with SPKI parsers, the intent is make EVP_PKEY capture the key's constraints in full fidelity, so we'd have to add new types or store the information in the underlying key object if people introduce variant key types with weird constraints on them. Note that because PKCS#8 has a space for arbitrary attributes, this parser must admit a hole. I'm assuming for now that we don't need an API that enforces no attributes and just ignore trailing data in the structure for simplicity. BUG=499653 Change-Id: I6fc641355e87136c7220f5d7693566d1144a68e8 Reviewed-on: https://boringssl-review.googlesource.com/6866 Reviewed-by: Adam Langley <agl@google.com>
2016-01-01 06:17:30 +00:00
/* See PKCS#11, v2.40, section 2.5. */
Decouple crypto/evp from the OID table. BUG=chromium:499653 Change-Id: I4e8d4af3129dbf61d4a8846ec9db685e83999d5e Reviewed-on: https://boringssl-review.googlesource.com/7565 Reviewed-by: Steven Valdez <svaldez@google.com> Reviewed-by: David Benjamin <davidben@google.com>
2016-03-25 22:07:16 +00:00
CBB pkcs8, algorithm, oid, private_key;
Implement new PKCS#8 parsers. As with SPKI parsers, the intent is make EVP_PKEY capture the key's constraints in full fidelity, so we'd have to add new types or store the information in the underlying key object if people introduce variant key types with weird constraints on them. Note that because PKCS#8 has a space for arbitrary attributes, this parser must admit a hole. I'm assuming for now that we don't need an API that enforces no attributes and just ignore trailing data in the structure for simplicity. BUG=499653 Change-Id: I6fc641355e87136c7220f5d7693566d1144a68e8 Reviewed-on: https://boringssl-review.googlesource.com/6866 Reviewed-by: Adam Langley <agl@google.com>
2016-01-01 06:17:30 +00:00
if (!CBB_add_asn1(out, &pkcs8, CBS_ASN1_SEQUENCE) ||
!CBB_add_asn1_uint64(&pkcs8, 0 /* version */) ||
!CBB_add_asn1(&pkcs8, &algorithm, CBS_ASN1_SEQUENCE) ||
Decouple crypto/evp from the OID table. BUG=chromium:499653 Change-Id: I4e8d4af3129dbf61d4a8846ec9db685e83999d5e Reviewed-on: https://boringssl-review.googlesource.com/7565 Reviewed-by: Steven Valdez <svaldez@google.com> Reviewed-by: David Benjamin <davidben@google.com>
2016-03-25 22:07:16 +00:00
!CBB_add_asn1(&algorithm, &oid, CBS_ASN1_OBJECT) ||
!CBB_add_bytes(&oid, dsa_asn1_meth.oid, dsa_asn1_meth.oid_len) ||
Implement new PKCS#8 parsers. As with SPKI parsers, the intent is make EVP_PKEY capture the key's constraints in full fidelity, so we'd have to add new types or store the information in the underlying key object if people introduce variant key types with weird constraints on them. Note that because PKCS#8 has a space for arbitrary attributes, this parser must admit a hole. I'm assuming for now that we don't need an API that enforces no attributes and just ignore trailing data in the structure for simplicity. BUG=499653 Change-Id: I6fc641355e87136c7220f5d7693566d1144a68e8 Reviewed-on: https://boringssl-review.googlesource.com/6866 Reviewed-by: Adam Langley <agl@google.com>
2016-01-01 06:17:30 +00:00
!DSA_marshal_parameters(&algorithm, dsa) ||
!CBB_add_asn1(&pkcs8, &private_key, CBS_ASN1_OCTETSTRING) ||
!BN_marshal_asn1(&private_key, dsa->priv_key) ||
!CBB_flush(out)) {
OPENSSL_PUT_ERROR(EVP, EVP_R_ENCODE_ERROR);
return 0;
Add DSA support to EVP. Sadly, it turns out that we have need of this, at least for now. The code is taken from upstream and changed only as much as needed. This only imports keys and doesn't know how to actually perform operations on them for now. Change-Id: I0db70fb938186cb7a91d03f068b386c59ed90b84
2015-01-30 01:25:29 +00:00
}
return 1;
}
static int int_dsa_size(const EVP_PKEY *pkey) {
return DSA_size(pkey->pkey.dsa);
}
static int dsa_bits(const EVP_PKEY *pkey) {
return BN_num_bits(pkey->pkey.dsa->p);
}
static int dsa_missing_parameters(const EVP_PKEY *pkey) {
DSA *dsa;
dsa = pkey->pkey.dsa;
if (dsa->p == NULL || dsa->q == NULL || dsa->g == NULL) {
return 1;
}
return 0;
}
static int dup_bn_into(BIGNUM **out, BIGNUM *src) {
BIGNUM *a;
a = BN_dup(src);
if (a == NULL) {
return 0;
}
Remove unnecessary NULL checks, part 3. Finish up the e's. Change-Id: Iabb8da000fbca6efee541edb469b90896f60d54b Reviewed-on: https://boringssl-review.googlesource.com/4516 Reviewed-by: Adam Langley <agl@google.com>
2015-04-22 20:49:27 +01:00
BN_free(*out);
Add DSA support to EVP. Sadly, it turns out that we have need of this, at least for now. The code is taken from upstream and changed only as much as needed. This only imports keys and doesn't know how to actually perform operations on them for now. Change-Id: I0db70fb938186cb7a91d03f068b386c59ed90b84
2015-01-30 01:25:29 +00:00
*out = a;
return 1;
}
static int dsa_copy_parameters(EVP_PKEY *to, const EVP_PKEY *from) {
if (!dup_bn_into(&to->pkey.dsa->p, from->pkey.dsa->p) ||
!dup_bn_into(&to->pkey.dsa->q, from->pkey.dsa->q) ||
!dup_bn_into(&to->pkey.dsa->g, from->pkey.dsa->g)) {
return 0;
}
return 1;
}
static int dsa_cmp_parameters(const EVP_PKEY *a, const EVP_PKEY *b) {
return BN_cmp(a->pkey.dsa->p, b->pkey.dsa->p) == 0 &&
BN_cmp(a->pkey.dsa->q, b->pkey.dsa->q) == 0 &&
BN_cmp(a->pkey.dsa->g, b->pkey.dsa->g) == 0;
}
static int dsa_pub_cmp(const EVP_PKEY *a, const EVP_PKEY *b) {
return BN_cmp(b->pkey.dsa->pub_key, a->pkey.dsa->pub_key) == 0;
}
static void int_dsa_free(EVP_PKEY *pkey) { DSA_free(pkey->pkey.dsa); }
const EVP_PKEY_ASN1_METHOD dsa_asn1_meth = {
EVP_PKEY_DSA,
Decouple crypto/evp from the OID table. BUG=chromium:499653 Change-Id: I4e8d4af3129dbf61d4a8846ec9db685e83999d5e Reviewed-on: https://boringssl-review.googlesource.com/7565 Reviewed-by: Steven Valdez <svaldez@google.com> Reviewed-by: David Benjamin <davidben@google.com>
2016-03-25 22:07:16 +00:00
/* 1.2.840.10040.4.1 */
{0x2a, 0x86, 0x48, 0xce, 0x38, 0x04, 0x01}, 7,
Add DSA support to EVP. Sadly, it turns out that we have need of this, at least for now. The code is taken from upstream and changed only as much as needed. This only imports keys and doesn't know how to actually perform operations on them for now. Change-Id: I0db70fb938186cb7a91d03f068b386c59ed90b84
2015-01-30 01:25:29 +00:00
dsa_pub_decode,
dsa_pub_encode,
dsa_pub_cmp,
dsa_priv_decode,
dsa_priv_encode,
NULL /* pkey_opaque */,
int_dsa_size,
dsa_bits,
dsa_missing_parameters,
dsa_copy_parameters,
dsa_cmp_parameters,
int_dsa_free,
};
Reference in New Issue Copy Permalink