2015-01-22 11:40:55 +08:00
|
|
|
/*
|
2023-09-07 16:59:15 +08:00
|
|
|
* Copyright 2005-2023 The OpenSSL Project Authors. All Rights Reserved.
|
2005-05-29 04:44:37 +08:00
|
|
|
*
|
2018-12-06 20:54:02 +08:00
|
|
|
* Licensed under the Apache License 2.0 (the "License"). You may not use
|
2016-05-18 02:51:34 +08:00
|
|
|
* this file except in compliance with the License. You can obtain a copy
|
|
|
|
* in the file LICENSE in the source distribution or at
|
|
|
|
* https://www.openssl.org/source/license.html
|
2005-05-29 04:44:37 +08:00
|
|
|
*/
|
|
|
|
|
2020-02-12 13:03:51 +08:00
|
|
|
/*
|
|
|
|
* RSA low level APIs are deprecated for public use, but still ok for
|
|
|
|
* internal use.
|
|
|
|
*/
|
|
|
|
#include "internal/deprecated.h"
|
|
|
|
|
2005-05-29 04:44:37 +08:00
|
|
|
#include <stdio.h>
|
2015-05-14 22:56:48 +08:00
|
|
|
#include "internal/cryptlib.h"
|
2005-05-29 04:44:37 +08:00
|
|
|
#include <openssl/bn.h>
|
|
|
|
#include <openssl/rsa.h>
|
|
|
|
#include <openssl/evp.h>
|
|
|
|
#include <openssl/rand.h>
|
|
|
|
#include <openssl/sha.h>
|
2019-09-28 06:45:40 +08:00
|
|
|
#include "rsa_local.h"
|
2005-05-29 04:44:37 +08:00
|
|
|
|
2015-01-22 11:40:55 +08:00
|
|
|
static const unsigned char zeroes[] = { 0, 0, 0, 0, 0, 0, 0, 0 };
|
2005-05-29 04:44:37 +08:00
|
|
|
|
2005-08-08 06:21:49 +08:00
|
|
|
#if defined(_MSC_VER) && defined(_ARM_)
|
2015-01-22 11:40:55 +08:00
|
|
|
# pragma optimize("g", off)
|
2005-08-08 06:21:49 +08:00
|
|
|
#endif
|
|
|
|
|
2005-05-29 04:44:37 +08:00
|
|
|
int RSA_verify_PKCS1_PSS(RSA *rsa, const unsigned char *mHash,
|
2015-01-22 11:40:55 +08:00
|
|
|
const EVP_MD *Hash, const unsigned char *EM,
|
|
|
|
int sLen)
|
|
|
|
{
|
|
|
|
return RSA_verify_PKCS1_PSS_mgf1(rsa, mHash, Hash, NULL, EM, sLen);
|
|
|
|
}
|
2010-03-11 21:40:42 +08:00
|
|
|
|
|
|
|
int RSA_verify_PKCS1_PSS_mgf1(RSA *rsa, const unsigned char *mHash,
|
2015-01-22 11:40:55 +08:00
|
|
|
const EVP_MD *Hash, const EVP_MD *mgf1Hash,
|
|
|
|
const unsigned char *EM, int sLen)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
int ret = 0;
|
|
|
|
int hLen, maskedDBLen, MSBits, emLen;
|
|
|
|
const unsigned char *H;
|
|
|
|
unsigned char *DB = NULL;
|
2015-12-02 07:49:35 +08:00
|
|
|
EVP_MD_CTX *ctx = EVP_MD_CTX_new();
|
2015-01-22 11:40:55 +08:00
|
|
|
unsigned char H_[EVP_MAX_MD_SIZE];
|
2015-11-27 21:02:12 +08:00
|
|
|
|
|
|
|
if (ctx == NULL)
|
|
|
|
goto err;
|
2005-06-03 02:25:36 +08:00
|
|
|
|
2015-01-22 11:40:55 +08:00
|
|
|
if (mgf1Hash == NULL)
|
|
|
|
mgf1Hash = Hash;
|
2010-03-11 21:40:42 +08:00
|
|
|
|
Rename all getters to use get/get0 in name
For functions that exist in 1.1.1 provide a simple aliases via #define.
Fixes #15236
Functions with OSSL_DECODER_, OSSL_ENCODER_, OSSL_STORE_LOADER_,
EVP_KEYEXCH_, EVP_KEM_, EVP_ASYM_CIPHER_, EVP_SIGNATURE_,
EVP_KEYMGMT_, EVP_RAND_, EVP_MAC_, EVP_KDF_, EVP_PKEY_,
EVP_MD_, and EVP_CIPHER_ prefixes are renamed.
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15405)
2021-05-21 22:58:08 +08:00
|
|
|
hLen = EVP_MD_get_size(Hash);
|
2015-01-22 11:40:55 +08:00
|
|
|
if (hLen < 0)
|
|
|
|
goto err;
|
2015-01-05 19:30:03 +08:00
|
|
|
/*-
|
|
|
|
* Negative sLen has special meanings:
|
|
|
|
* -1 sLen == hLen
|
|
|
|
* -2 salt length is autorecovered from signature
|
2017-02-27 19:40:35 +08:00
|
|
|
* -3 salt length is maximized
|
signature: Clamp PSS salt len to MD len
FIPS 186-4 section 5 "The RSA Digital Signature Algorithm", subsection
5.5 "PKCS #1" says: "For RSASSA-PSS […] the length (in bytes) of the
salt (sLen) shall satisfy 0 <= sLen <= hLen, where hLen is the length of
the hash function output block (in bytes)."
Introduce a new option RSA_PSS_SALTLEN_AUTO_DIGEST_MAX and make it the
default. The new value will behave like RSA_PSS_SALTLEN_AUTO, but will
not use more than the digest length when signing, so that FIPS 186-4 is
not violated. This value has two advantages when compared with
RSA_PSS_SALTLEN_DIGEST: (1) It will continue to do auto-detection when
verifying signatures for maximum compatibility, where
RSA_PSS_SALTLEN_DIGEST would fail for other digest sizes. (2) It will
work for combinations where the maximum salt length is smaller than the
digest size, which typically happens with large digest sizes (e.g.,
SHA-512) and small RSA keys.
J.-S. Coron shows in "Optimal Security Proofs for PSS and Other
Signature Schemes. Advances in Cryptology – Eurocrypt 2002, volume 2332
of Lecture Notes in Computer Science, pp. 272 – 287. Springer Verlag,
2002." that longer salts than the output size of modern hash functions
do not increase security: "For example,for an application in which at
most one billion signatures will be generated, k0 = 30 bits of random
salt are actually sufficient to guarantee the same level of security as
RSA, and taking a larger salt does not increase the security level."
Signed-off-by: Clemens Lang <cllang@redhat.com>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19724)
2022-11-18 19:35:33 +08:00
|
|
|
* -4 salt length is autorecovered from signature
|
2015-01-05 19:30:03 +08:00
|
|
|
* -N reserved
|
|
|
|
*/
|
2017-08-23 01:36:49 +08:00
|
|
|
if (sLen == RSA_PSS_SALTLEN_DIGEST) {
|
2015-01-22 11:40:55 +08:00
|
|
|
sLen = hLen;
|
signature: Clamp PSS salt len to MD len
FIPS 186-4 section 5 "The RSA Digital Signature Algorithm", subsection
5.5 "PKCS #1" says: "For RSASSA-PSS […] the length (in bytes) of the
salt (sLen) shall satisfy 0 <= sLen <= hLen, where hLen is the length of
the hash function output block (in bytes)."
Introduce a new option RSA_PSS_SALTLEN_AUTO_DIGEST_MAX and make it the
default. The new value will behave like RSA_PSS_SALTLEN_AUTO, but will
not use more than the digest length when signing, so that FIPS 186-4 is
not violated. This value has two advantages when compared with
RSA_PSS_SALTLEN_DIGEST: (1) It will continue to do auto-detection when
verifying signatures for maximum compatibility, where
RSA_PSS_SALTLEN_DIGEST would fail for other digest sizes. (2) It will
work for combinations where the maximum salt length is smaller than the
digest size, which typically happens with large digest sizes (e.g.,
SHA-512) and small RSA keys.
J.-S. Coron shows in "Optimal Security Proofs for PSS and Other
Signature Schemes. Advances in Cryptology – Eurocrypt 2002, volume 2332
of Lecture Notes in Computer Science, pp. 272 – 287. Springer Verlag,
2002." that longer salts than the output size of modern hash functions
do not increase security: "For example,for an application in which at
most one billion signatures will be generated, k0 = 30 bits of random
salt are actually sufficient to guarantee the same level of security as
RSA, and taking a larger salt does not increase the security level."
Signed-off-by: Clemens Lang <cllang@redhat.com>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19724)
2022-11-18 19:35:33 +08:00
|
|
|
} else if (sLen < RSA_PSS_SALTLEN_AUTO_DIGEST_MAX) {
|
2020-11-04 19:23:19 +08:00
|
|
|
ERR_raise(ERR_LIB_RSA, RSA_R_SLEN_CHECK_FAILED);
|
2015-01-22 11:40:55 +08:00
|
|
|
goto err;
|
|
|
|
}
|
2005-06-03 02:25:36 +08:00
|
|
|
|
2015-01-22 11:40:55 +08:00
|
|
|
MSBits = (BN_num_bits(rsa->n) - 1) & 0x7;
|
|
|
|
emLen = RSA_size(rsa);
|
|
|
|
if (EM[0] & (0xFF << MSBits)) {
|
2020-11-04 19:23:19 +08:00
|
|
|
ERR_raise(ERR_LIB_RSA, RSA_R_FIRST_OCTET_INVALID);
|
2015-01-22 11:40:55 +08:00
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
if (MSBits == 0) {
|
|
|
|
EM++;
|
|
|
|
emLen--;
|
|
|
|
}
|
2017-02-27 19:40:35 +08:00
|
|
|
if (emLen < hLen + 2) {
|
2020-11-04 19:23:19 +08:00
|
|
|
ERR_raise(ERR_LIB_RSA, RSA_R_DATA_TOO_LARGE);
|
2017-02-27 19:40:35 +08:00
|
|
|
goto err;
|
|
|
|
}
|
2017-01-18 01:51:24 +08:00
|
|
|
if (sLen == RSA_PSS_SALTLEN_MAX) {
|
|
|
|
sLen = emLen - hLen - 2;
|
2017-02-27 19:40:35 +08:00
|
|
|
} else if (sLen > emLen - hLen - 2) { /* sLen can be small negative */
|
2020-11-04 19:23:19 +08:00
|
|
|
ERR_raise(ERR_LIB_RSA, RSA_R_DATA_TOO_LARGE);
|
2015-01-22 11:40:55 +08:00
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
if (EM[emLen - 1] != 0xbc) {
|
2020-11-04 19:23:19 +08:00
|
|
|
ERR_raise(ERR_LIB_RSA, RSA_R_LAST_OCTET_INVALID);
|
2015-01-22 11:40:55 +08:00
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
maskedDBLen = emLen - hLen - 1;
|
|
|
|
H = EM + maskedDBLen;
|
|
|
|
DB = OPENSSL_malloc(maskedDBLen);
|
2022-09-29 19:57:34 +08:00
|
|
|
if (DB == NULL)
|
2015-01-22 11:40:55 +08:00
|
|
|
goto err;
|
|
|
|
if (PKCS1_MGF1(DB, maskedDBLen, H, hLen, mgf1Hash) < 0)
|
|
|
|
goto err;
|
|
|
|
for (i = 0; i < maskedDBLen; i++)
|
|
|
|
DB[i] ^= EM[i];
|
|
|
|
if (MSBits)
|
|
|
|
DB[0] &= 0xFF >> (8 - MSBits);
|
|
|
|
for (i = 0; DB[i] == 0 && i < (maskedDBLen - 1); i++) ;
|
|
|
|
if (DB[i++] != 0x1) {
|
2020-11-04 19:23:19 +08:00
|
|
|
ERR_raise(ERR_LIB_RSA, RSA_R_SLEN_RECOVERY_FAILED);
|
2015-01-22 11:40:55 +08:00
|
|
|
goto err;
|
|
|
|
}
|
signature: Clamp PSS salt len to MD len
FIPS 186-4 section 5 "The RSA Digital Signature Algorithm", subsection
5.5 "PKCS #1" says: "For RSASSA-PSS […] the length (in bytes) of the
salt (sLen) shall satisfy 0 <= sLen <= hLen, where hLen is the length of
the hash function output block (in bytes)."
Introduce a new option RSA_PSS_SALTLEN_AUTO_DIGEST_MAX and make it the
default. The new value will behave like RSA_PSS_SALTLEN_AUTO, but will
not use more than the digest length when signing, so that FIPS 186-4 is
not violated. This value has two advantages when compared with
RSA_PSS_SALTLEN_DIGEST: (1) It will continue to do auto-detection when
verifying signatures for maximum compatibility, where
RSA_PSS_SALTLEN_DIGEST would fail for other digest sizes. (2) It will
work for combinations where the maximum salt length is smaller than the
digest size, which typically happens with large digest sizes (e.g.,
SHA-512) and small RSA keys.
J.-S. Coron shows in "Optimal Security Proofs for PSS and Other
Signature Schemes. Advances in Cryptology – Eurocrypt 2002, volume 2332
of Lecture Notes in Computer Science, pp. 272 – 287. Springer Verlag,
2002." that longer salts than the output size of modern hash functions
do not increase security: "For example,for an application in which at
most one billion signatures will be generated, k0 = 30 bits of random
salt are actually sufficient to guarantee the same level of security as
RSA, and taking a larger salt does not increase the security level."
Signed-off-by: Clemens Lang <cllang@redhat.com>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19724)
2022-11-18 19:35:33 +08:00
|
|
|
if (sLen != RSA_PSS_SALTLEN_AUTO
|
|
|
|
&& sLen != RSA_PSS_SALTLEN_AUTO_DIGEST_MAX
|
|
|
|
&& (maskedDBLen - i) != sLen) {
|
2021-01-30 00:02:32 +08:00
|
|
|
ERR_raise_data(ERR_LIB_RSA, RSA_R_SLEN_CHECK_FAILED,
|
|
|
|
"expected: %d retrieved: %d", sLen,
|
|
|
|
maskedDBLen - i);
|
2015-01-22 11:40:55 +08:00
|
|
|
goto err;
|
|
|
|
}
|
2015-11-27 21:02:12 +08:00
|
|
|
if (!EVP_DigestInit_ex(ctx, Hash, NULL)
|
2017-12-08 02:39:34 +08:00
|
|
|
|| !EVP_DigestUpdate(ctx, zeroes, sizeof(zeroes))
|
2015-11-27 21:02:12 +08:00
|
|
|
|| !EVP_DigestUpdate(ctx, mHash, hLen))
|
2015-01-22 11:40:55 +08:00
|
|
|
goto err;
|
|
|
|
if (maskedDBLen - i) {
|
2015-11-27 21:02:12 +08:00
|
|
|
if (!EVP_DigestUpdate(ctx, DB + i, maskedDBLen - i))
|
2015-01-22 11:40:55 +08:00
|
|
|
goto err;
|
|
|
|
}
|
2015-11-27 21:02:12 +08:00
|
|
|
if (!EVP_DigestFinal_ex(ctx, H_, NULL))
|
2015-01-22 11:40:55 +08:00
|
|
|
goto err;
|
|
|
|
if (memcmp(H_, H, hLen)) {
|
2020-11-04 19:23:19 +08:00
|
|
|
ERR_raise(ERR_LIB_RSA, RSA_R_BAD_SIGNATURE);
|
2015-01-22 11:40:55 +08:00
|
|
|
ret = 0;
|
2017-08-23 01:36:49 +08:00
|
|
|
} else {
|
2015-01-22 11:40:55 +08:00
|
|
|
ret = 1;
|
2017-08-23 01:36:49 +08:00
|
|
|
}
|
2005-05-29 04:44:37 +08:00
|
|
|
|
2015-01-22 11:40:55 +08:00
|
|
|
err:
|
2015-05-01 22:02:07 +08:00
|
|
|
OPENSSL_free(DB);
|
2015-12-02 07:49:35 +08:00
|
|
|
EVP_MD_CTX_free(ctx);
|
2005-05-29 04:44:37 +08:00
|
|
|
|
2015-01-22 11:40:55 +08:00
|
|
|
return ret;
|
2005-05-29 04:44:37 +08:00
|
|
|
|
2015-01-22 11:40:55 +08:00
|
|
|
}
|
2005-05-29 04:44:37 +08:00
|
|
|
|
|
|
|
int RSA_padding_add_PKCS1_PSS(RSA *rsa, unsigned char *EM,
|
2015-01-22 11:40:55 +08:00
|
|
|
const unsigned char *mHash,
|
|
|
|
const EVP_MD *Hash, int sLen)
|
|
|
|
{
|
|
|
|
return RSA_padding_add_PKCS1_PSS_mgf1(rsa, EM, mHash, Hash, NULL, sLen);
|
|
|
|
}
|
2010-03-11 21:40:42 +08:00
|
|
|
|
|
|
|
int RSA_padding_add_PKCS1_PSS_mgf1(RSA *rsa, unsigned char *EM,
|
2015-01-22 11:40:55 +08:00
|
|
|
const unsigned char *mHash,
|
|
|
|
const EVP_MD *Hash, const EVP_MD *mgf1Hash,
|
|
|
|
int sLen)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
int ret = 0;
|
|
|
|
int hLen, maskedDBLen, MSBits, emLen;
|
|
|
|
unsigned char *H, *salt = NULL, *p;
|
2015-11-27 21:02:12 +08:00
|
|
|
EVP_MD_CTX *ctx = NULL;
|
signature: Clamp PSS salt len to MD len
FIPS 186-4 section 5 "The RSA Digital Signature Algorithm", subsection
5.5 "PKCS #1" says: "For RSASSA-PSS […] the length (in bytes) of the
salt (sLen) shall satisfy 0 <= sLen <= hLen, where hLen is the length of
the hash function output block (in bytes)."
Introduce a new option RSA_PSS_SALTLEN_AUTO_DIGEST_MAX and make it the
default. The new value will behave like RSA_PSS_SALTLEN_AUTO, but will
not use more than the digest length when signing, so that FIPS 186-4 is
not violated. This value has two advantages when compared with
RSA_PSS_SALTLEN_DIGEST: (1) It will continue to do auto-detection when
verifying signatures for maximum compatibility, where
RSA_PSS_SALTLEN_DIGEST would fail for other digest sizes. (2) It will
work for combinations where the maximum salt length is smaller than the
digest size, which typically happens with large digest sizes (e.g.,
SHA-512) and small RSA keys.
J.-S. Coron shows in "Optimal Security Proofs for PSS and Other
Signature Schemes. Advances in Cryptology – Eurocrypt 2002, volume 2332
of Lecture Notes in Computer Science, pp. 272 – 287. Springer Verlag,
2002." that longer salts than the output size of modern hash functions
do not increase security: "For example,for an application in which at
most one billion signatures will be generated, k0 = 30 bits of random
salt are actually sufficient to guarantee the same level of security as
RSA, and taking a larger salt does not increase the security level."
Signed-off-by: Clemens Lang <cllang@redhat.com>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19724)
2022-11-18 19:35:33 +08:00
|
|
|
int sLenMax = -1;
|
2005-06-03 02:25:36 +08:00
|
|
|
|
2015-01-22 11:40:55 +08:00
|
|
|
if (mgf1Hash == NULL)
|
|
|
|
mgf1Hash = Hash;
|
2010-03-11 21:40:42 +08:00
|
|
|
|
Rename all getters to use get/get0 in name
For functions that exist in 1.1.1 provide a simple aliases via #define.
Fixes #15236
Functions with OSSL_DECODER_, OSSL_ENCODER_, OSSL_STORE_LOADER_,
EVP_KEYEXCH_, EVP_KEM_, EVP_ASYM_CIPHER_, EVP_SIGNATURE_,
EVP_KEYMGMT_, EVP_RAND_, EVP_MAC_, EVP_KDF_, EVP_PKEY_,
EVP_MD_, and EVP_CIPHER_ prefixes are renamed.
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15405)
2021-05-21 22:58:08 +08:00
|
|
|
hLen = EVP_MD_get_size(Hash);
|
2015-01-22 11:40:55 +08:00
|
|
|
if (hLen < 0)
|
|
|
|
goto err;
|
2015-01-05 19:30:03 +08:00
|
|
|
/*-
|
|
|
|
* Negative sLen has special meanings:
|
|
|
|
* -1 sLen == hLen
|
|
|
|
* -2 salt length is maximized
|
2017-02-27 19:40:35 +08:00
|
|
|
* -3 same as above (on signing)
|
signature: Clamp PSS salt len to MD len
FIPS 186-4 section 5 "The RSA Digital Signature Algorithm", subsection
5.5 "PKCS #1" says: "For RSASSA-PSS […] the length (in bytes) of the
salt (sLen) shall satisfy 0 <= sLen <= hLen, where hLen is the length of
the hash function output block (in bytes)."
Introduce a new option RSA_PSS_SALTLEN_AUTO_DIGEST_MAX and make it the
default. The new value will behave like RSA_PSS_SALTLEN_AUTO, but will
not use more than the digest length when signing, so that FIPS 186-4 is
not violated. This value has two advantages when compared with
RSA_PSS_SALTLEN_DIGEST: (1) It will continue to do auto-detection when
verifying signatures for maximum compatibility, where
RSA_PSS_SALTLEN_DIGEST would fail for other digest sizes. (2) It will
work for combinations where the maximum salt length is smaller than the
digest size, which typically happens with large digest sizes (e.g.,
SHA-512) and small RSA keys.
J.-S. Coron shows in "Optimal Security Proofs for PSS and Other
Signature Schemes. Advances in Cryptology – Eurocrypt 2002, volume 2332
of Lecture Notes in Computer Science, pp. 272 – 287. Springer Verlag,
2002." that longer salts than the output size of modern hash functions
do not increase security: "For example,for an application in which at
most one billion signatures will be generated, k0 = 30 bits of random
salt are actually sufficient to guarantee the same level of security as
RSA, and taking a larger salt does not increase the security level."
Signed-off-by: Clemens Lang <cllang@redhat.com>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19724)
2022-11-18 19:35:33 +08:00
|
|
|
* -4 salt length is min(hLen, maximum salt length)
|
2015-01-05 19:30:03 +08:00
|
|
|
* -N reserved
|
|
|
|
*/
|
signature: Clamp PSS salt len to MD len
FIPS 186-4 section 5 "The RSA Digital Signature Algorithm", subsection
5.5 "PKCS #1" says: "For RSASSA-PSS […] the length (in bytes) of the
salt (sLen) shall satisfy 0 <= sLen <= hLen, where hLen is the length of
the hash function output block (in bytes)."
Introduce a new option RSA_PSS_SALTLEN_AUTO_DIGEST_MAX and make it the
default. The new value will behave like RSA_PSS_SALTLEN_AUTO, but will
not use more than the digest length when signing, so that FIPS 186-4 is
not violated. This value has two advantages when compared with
RSA_PSS_SALTLEN_DIGEST: (1) It will continue to do auto-detection when
verifying signatures for maximum compatibility, where
RSA_PSS_SALTLEN_DIGEST would fail for other digest sizes. (2) It will
work for combinations where the maximum salt length is smaller than the
digest size, which typically happens with large digest sizes (e.g.,
SHA-512) and small RSA keys.
J.-S. Coron shows in "Optimal Security Proofs for PSS and Other
Signature Schemes. Advances in Cryptology – Eurocrypt 2002, volume 2332
of Lecture Notes in Computer Science, pp. 272 – 287. Springer Verlag,
2002." that longer salts than the output size of modern hash functions
do not increase security: "For example,for an application in which at
most one billion signatures will be generated, k0 = 30 bits of random
salt are actually sufficient to guarantee the same level of security as
RSA, and taking a larger salt does not increase the security level."
Signed-off-by: Clemens Lang <cllang@redhat.com>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19724)
2022-11-18 19:35:33 +08:00
|
|
|
/* FIPS 186-4 section 5 "The RSA Digital Signature Algorithm", subsection
|
|
|
|
* 5.5 "PKCS #1" says: "For RSASSA-PSS […] the length (in bytes) of the
|
|
|
|
* salt (sLen) shall satisfy 0 <= sLen <= hLen, where hLen is the length of
|
|
|
|
* the hash function output block (in bytes)."
|
|
|
|
*
|
|
|
|
* Provide a way to use at most the digest length, so that the default does
|
|
|
|
* not violate FIPS 186-4. */
|
2017-08-23 01:36:49 +08:00
|
|
|
if (sLen == RSA_PSS_SALTLEN_DIGEST) {
|
2015-01-22 11:40:55 +08:00
|
|
|
sLen = hLen;
|
signature: Clamp PSS salt len to MD len
FIPS 186-4 section 5 "The RSA Digital Signature Algorithm", subsection
5.5 "PKCS #1" says: "For RSASSA-PSS […] the length (in bytes) of the
salt (sLen) shall satisfy 0 <= sLen <= hLen, where hLen is the length of
the hash function output block (in bytes)."
Introduce a new option RSA_PSS_SALTLEN_AUTO_DIGEST_MAX and make it the
default. The new value will behave like RSA_PSS_SALTLEN_AUTO, but will
not use more than the digest length when signing, so that FIPS 186-4 is
not violated. This value has two advantages when compared with
RSA_PSS_SALTLEN_DIGEST: (1) It will continue to do auto-detection when
verifying signatures for maximum compatibility, where
RSA_PSS_SALTLEN_DIGEST would fail for other digest sizes. (2) It will
work for combinations where the maximum salt length is smaller than the
digest size, which typically happens with large digest sizes (e.g.,
SHA-512) and small RSA keys.
J.-S. Coron shows in "Optimal Security Proofs for PSS and Other
Signature Schemes. Advances in Cryptology – Eurocrypt 2002, volume 2332
of Lecture Notes in Computer Science, pp. 272 – 287. Springer Verlag,
2002." that longer salts than the output size of modern hash functions
do not increase security: "For example,for an application in which at
most one billion signatures will be generated, k0 = 30 bits of random
salt are actually sufficient to guarantee the same level of security as
RSA, and taking a larger salt does not increase the security level."
Signed-off-by: Clemens Lang <cllang@redhat.com>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19724)
2022-11-18 19:35:33 +08:00
|
|
|
} else if (sLen == RSA_PSS_SALTLEN_MAX_SIGN
|
|
|
|
|| sLen == RSA_PSS_SALTLEN_AUTO) {
|
2017-01-18 01:51:24 +08:00
|
|
|
sLen = RSA_PSS_SALTLEN_MAX;
|
signature: Clamp PSS salt len to MD len
FIPS 186-4 section 5 "The RSA Digital Signature Algorithm", subsection
5.5 "PKCS #1" says: "For RSASSA-PSS […] the length (in bytes) of the
salt (sLen) shall satisfy 0 <= sLen <= hLen, where hLen is the length of
the hash function output block (in bytes)."
Introduce a new option RSA_PSS_SALTLEN_AUTO_DIGEST_MAX and make it the
default. The new value will behave like RSA_PSS_SALTLEN_AUTO, but will
not use more than the digest length when signing, so that FIPS 186-4 is
not violated. This value has two advantages when compared with
RSA_PSS_SALTLEN_DIGEST: (1) It will continue to do auto-detection when
verifying signatures for maximum compatibility, where
RSA_PSS_SALTLEN_DIGEST would fail for other digest sizes. (2) It will
work for combinations where the maximum salt length is smaller than the
digest size, which typically happens with large digest sizes (e.g.,
SHA-512) and small RSA keys.
J.-S. Coron shows in "Optimal Security Proofs for PSS and Other
Signature Schemes. Advances in Cryptology – Eurocrypt 2002, volume 2332
of Lecture Notes in Computer Science, pp. 272 – 287. Springer Verlag,
2002." that longer salts than the output size of modern hash functions
do not increase security: "For example,for an application in which at
most one billion signatures will be generated, k0 = 30 bits of random
salt are actually sufficient to guarantee the same level of security as
RSA, and taking a larger salt does not increase the security level."
Signed-off-by: Clemens Lang <cllang@redhat.com>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19724)
2022-11-18 19:35:33 +08:00
|
|
|
} else if (sLen == RSA_PSS_SALTLEN_AUTO_DIGEST_MAX) {
|
|
|
|
sLen = RSA_PSS_SALTLEN_MAX;
|
|
|
|
sLenMax = hLen;
|
|
|
|
} else if (sLen < RSA_PSS_SALTLEN_AUTO_DIGEST_MAX) {
|
2020-11-04 19:23:19 +08:00
|
|
|
ERR_raise(ERR_LIB_RSA, RSA_R_SLEN_CHECK_FAILED);
|
2015-01-22 11:40:55 +08:00
|
|
|
goto err;
|
|
|
|
}
|
2005-06-03 02:25:36 +08:00
|
|
|
|
2015-01-22 11:40:55 +08:00
|
|
|
MSBits = (BN_num_bits(rsa->n) - 1) & 0x7;
|
|
|
|
emLen = RSA_size(rsa);
|
|
|
|
if (MSBits == 0) {
|
|
|
|
*EM++ = 0;
|
|
|
|
emLen--;
|
|
|
|
}
|
2017-02-27 19:40:35 +08:00
|
|
|
if (emLen < hLen + 2) {
|
2020-11-04 19:23:19 +08:00
|
|
|
ERR_raise(ERR_LIB_RSA, RSA_R_DATA_TOO_LARGE_FOR_KEY_SIZE);
|
2017-02-27 19:40:35 +08:00
|
|
|
goto err;
|
|
|
|
}
|
2017-01-18 01:51:24 +08:00
|
|
|
if (sLen == RSA_PSS_SALTLEN_MAX) {
|
2015-01-22 11:40:55 +08:00
|
|
|
sLen = emLen - hLen - 2;
|
signature: Clamp PSS salt len to MD len
FIPS 186-4 section 5 "The RSA Digital Signature Algorithm", subsection
5.5 "PKCS #1" says: "For RSASSA-PSS […] the length (in bytes) of the
salt (sLen) shall satisfy 0 <= sLen <= hLen, where hLen is the length of
the hash function output block (in bytes)."
Introduce a new option RSA_PSS_SALTLEN_AUTO_DIGEST_MAX and make it the
default. The new value will behave like RSA_PSS_SALTLEN_AUTO, but will
not use more than the digest length when signing, so that FIPS 186-4 is
not violated. This value has two advantages when compared with
RSA_PSS_SALTLEN_DIGEST: (1) It will continue to do auto-detection when
verifying signatures for maximum compatibility, where
RSA_PSS_SALTLEN_DIGEST would fail for other digest sizes. (2) It will
work for combinations where the maximum salt length is smaller than the
digest size, which typically happens with large digest sizes (e.g.,
SHA-512) and small RSA keys.
J.-S. Coron shows in "Optimal Security Proofs for PSS and Other
Signature Schemes. Advances in Cryptology – Eurocrypt 2002, volume 2332
of Lecture Notes in Computer Science, pp. 272 – 287. Springer Verlag,
2002." that longer salts than the output size of modern hash functions
do not increase security: "For example,for an application in which at
most one billion signatures will be generated, k0 = 30 bits of random
salt are actually sufficient to guarantee the same level of security as
RSA, and taking a larger salt does not increase the security level."
Signed-off-by: Clemens Lang <cllang@redhat.com>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19724)
2022-11-18 19:35:33 +08:00
|
|
|
if (sLenMax >= 0 && sLen > sLenMax)
|
|
|
|
sLen = sLenMax;
|
2017-02-27 19:40:35 +08:00
|
|
|
} else if (sLen > emLen - hLen - 2) {
|
2020-11-04 19:23:19 +08:00
|
|
|
ERR_raise(ERR_LIB_RSA, RSA_R_DATA_TOO_LARGE_FOR_KEY_SIZE);
|
2015-01-22 11:40:55 +08:00
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
if (sLen > 0) {
|
|
|
|
salt = OPENSSL_malloc(sLen);
|
2022-09-29 19:57:34 +08:00
|
|
|
if (salt == NULL)
|
2015-01-22 11:40:55 +08:00
|
|
|
goto err;
|
2021-05-28 12:46:40 +08:00
|
|
|
if (RAND_bytes_ex(rsa->libctx, salt, sLen, 0) <= 0)
|
2015-01-22 11:40:55 +08:00
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
maskedDBLen = emLen - hLen - 1;
|
|
|
|
H = EM + maskedDBLen;
|
2015-12-02 07:49:35 +08:00
|
|
|
ctx = EVP_MD_CTX_new();
|
2015-11-27 21:02:12 +08:00
|
|
|
if (ctx == NULL)
|
|
|
|
goto err;
|
|
|
|
if (!EVP_DigestInit_ex(ctx, Hash, NULL)
|
2017-12-08 02:39:34 +08:00
|
|
|
|| !EVP_DigestUpdate(ctx, zeroes, sizeof(zeroes))
|
2015-11-27 21:02:12 +08:00
|
|
|
|| !EVP_DigestUpdate(ctx, mHash, hLen))
|
2015-01-22 11:40:55 +08:00
|
|
|
goto err;
|
2015-11-27 21:02:12 +08:00
|
|
|
if (sLen && !EVP_DigestUpdate(ctx, salt, sLen))
|
2015-01-22 11:40:55 +08:00
|
|
|
goto err;
|
2015-11-27 21:02:12 +08:00
|
|
|
if (!EVP_DigestFinal_ex(ctx, H, NULL))
|
2015-01-22 11:40:55 +08:00
|
|
|
goto err;
|
2005-05-29 04:44:37 +08:00
|
|
|
|
2015-01-22 11:40:55 +08:00
|
|
|
/* Generate dbMask in place then perform XOR on it */
|
|
|
|
if (PKCS1_MGF1(EM, maskedDBLen, H, hLen, mgf1Hash))
|
|
|
|
goto err;
|
2005-05-29 04:44:37 +08:00
|
|
|
|
2015-01-22 11:40:55 +08:00
|
|
|
p = EM;
|
2005-05-29 04:44:37 +08:00
|
|
|
|
2015-01-22 11:40:55 +08:00
|
|
|
/*
|
|
|
|
* Initial PS XORs with all zeroes which is a NOP so just update pointer.
|
|
|
|
* Note from a test above this value is guaranteed to be non-negative.
|
|
|
|
*/
|
|
|
|
p += emLen - sLen - hLen - 2;
|
|
|
|
*p++ ^= 0x1;
|
|
|
|
if (sLen > 0) {
|
|
|
|
for (i = 0; i < sLen; i++)
|
|
|
|
*p++ ^= salt[i];
|
|
|
|
}
|
|
|
|
if (MSBits)
|
|
|
|
EM[0] &= 0xFF >> (8 - MSBits);
|
2005-05-29 04:44:37 +08:00
|
|
|
|
2015-01-22 11:40:55 +08:00
|
|
|
/* H is already in place so just set final 0xbc */
|
2005-05-29 04:44:37 +08:00
|
|
|
|
2015-01-22 11:40:55 +08:00
|
|
|
EM[emLen - 1] = 0xbc;
|
2005-05-29 04:44:37 +08:00
|
|
|
|
2015-01-22 11:40:55 +08:00
|
|
|
ret = 1;
|
2005-05-29 04:44:37 +08:00
|
|
|
|
2015-01-22 11:40:55 +08:00
|
|
|
err:
|
2015-12-02 07:49:35 +08:00
|
|
|
EVP_MD_CTX_free(ctx);
|
2018-09-09 22:33:12 +08:00
|
|
|
OPENSSL_clear_free(salt, (size_t)sLen); /* salt != NULL implies sLen > 0 */
|
2005-05-29 04:44:37 +08:00
|
|
|
|
2015-01-22 11:40:55 +08:00
|
|
|
return ret;
|
2005-05-29 04:44:37 +08:00
|
|
|
|
2015-01-22 11:40:55 +08:00
|
|
|
}
|
2005-08-08 06:21:49 +08:00
|
|
|
|
RSA: Add a less loaded PSS-parameter structure
RSA_PSS_PARAMS carries with it a lot of baggage in form of X509_ALGOR
and ASN1_INTEGER, which we would rather avoid in our providers.
Therefore, we create a parallell structure - RSA_PSS_PARAMS_30 - that
contains the same information, but uses numeric identities (*) and C
integers (**). This makes it simpler to handle.
Note that neither this structure nor its contents are passed between
libcrypto and the providers. Instead, the numeric identities are
translated to and from names, which are then passed over that
boundary.
For future considerations, we might consider dropping RSA_PSS_PARAMS
entirely. For now, it's still reserved for EVP_PKEY_ASN1_METHOD code,
which RSA_PSS_PARAMS_30 is (almost entirely) reserved for use in our
providers.
(*) We use NIDs in this case, because we already have them and because
only algorithms that libcrypto knows about are permitted in PSS
restrictions. We could use any number series we want, as long as we
know for sure what they represent.
(**) That's for saltlen and for trailerfield, which are never expect
to surpass the set of numbers that fit in a regular 'int'.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/11710)
2020-05-02 18:46:55 +08:00
|
|
|
/*
|
|
|
|
* The defaults for PSS restrictions are defined in RFC 8017, A.2.3 RSASSA-PSS
|
|
|
|
* (https://tools.ietf.org/html/rfc8017#appendix-A.2.3):
|
|
|
|
*
|
|
|
|
* If the default values of the hashAlgorithm, maskGenAlgorithm, and
|
|
|
|
* trailerField fields of RSASSA-PSS-params are used, then the algorithm
|
|
|
|
* identifier will have the following value:
|
|
|
|
*
|
|
|
|
* rSASSA-PSS-Default-Identifier RSASSA-AlgorithmIdentifier ::= {
|
|
|
|
* algorithm id-RSASSA-PSS,
|
|
|
|
* parameters RSASSA-PSS-params : {
|
|
|
|
* hashAlgorithm sha1,
|
|
|
|
* maskGenAlgorithm mgf1SHA1,
|
|
|
|
* saltLength 20,
|
|
|
|
* trailerField trailerFieldBC
|
|
|
|
* }
|
|
|
|
* }
|
|
|
|
*
|
|
|
|
* RSASSA-AlgorithmIdentifier ::= AlgorithmIdentifier {
|
|
|
|
* {PKCS1Algorithms}
|
|
|
|
* }
|
|
|
|
*/
|
|
|
|
static const RSA_PSS_PARAMS_30 default_RSASSA_PSS_params = {
|
|
|
|
NID_sha1, /* default hashAlgorithm */
|
|
|
|
{
|
|
|
|
NID_mgf1, /* default maskGenAlgorithm */
|
|
|
|
NID_sha1 /* default MGF1 hash */
|
|
|
|
},
|
|
|
|
20, /* default saltLength */
|
|
|
|
1 /* default trailerField (0xBC) */
|
|
|
|
};
|
|
|
|
|
rsa: add ossl_ prefix to internal rsa_ calls.
The functions being:
rsa_check_crt_components, rsa_check_key, rsa_check_pminusq_diff,
rsa_check_prime_factor, rsa_check_prime_factor_range,
rsa_check_private_exponent, rsa_check_public_exponent,
rsa_digestinfo_encoding, rsa_fips186_4_gen_prob_primes, rsa_fromdata,
rsa_get0_all_params, rsa_get0_libctx, rsa_get0_pss_params_30,
rsa_get_lcm, rsa_mgf_nid2name, rsa_mp_coeff_names, rsa_mp_exp_names,
rsa_mp_factor_names, rsa_new_with_ctx, rsa_oaeppss_md2nid,
rsa_oaeppss_nid2name, rsa_padding_add_PKCS1_OAEP_mgf1_with_libctx,
rsa_padding_add_PKCS1_type_2_with_libctx,
rsa_padding_add_SSLv23_with_libctx, rsa_padding_check_PKCS1_type_2_TLS,
rsa_pkey_method, rsa_pss_params_30_copy, rsa_pss_params_30_fromdata,
rsa_pss_params_30_hashalg, rsa_pss_params_30_is_unrestricted,
rsa_pss_params_30_maskgenalg, rsa_pss_params_30_maskgenhashalg,
rsa_pss_params_30_saltlen, rsa_pss_params_30_set_defaults,
rsa_pss_params_30_set_hashalg, rsa_pss_params_30_set_maskgenalg,
rsa_pss_params_30_set_maskgenhashalg, rsa_pss_params_30_set_saltlen,
rsa_pss_params_30_set_trailerfield, rsa_pss_params_30_todata,
rsa_pss_params_30_trailerfield, rsa_pss_pkey_method, rsa_set0_all_params,
rsa_sp800_56b_check_keypair, rsa_sp800_56b_check_private,
rsa_sp800_56b_check_public, rsa_sp800_56b_derive_params_from_pq,
rsa_sp800_56b_generate_key, rsa_sp800_56b_pairwise_test,
rsa_sp800_56b_validate_strength, rsa_todata, rsa_validate_pairwise,
rsa_validate_private and rsa_validate_public.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13040)
2020-09-30 12:20:14 +08:00
|
|
|
int ossl_rsa_pss_params_30_set_defaults(RSA_PSS_PARAMS_30 *rsa_pss_params)
|
RSA: Add a less loaded PSS-parameter structure
RSA_PSS_PARAMS carries with it a lot of baggage in form of X509_ALGOR
and ASN1_INTEGER, which we would rather avoid in our providers.
Therefore, we create a parallell structure - RSA_PSS_PARAMS_30 - that
contains the same information, but uses numeric identities (*) and C
integers (**). This makes it simpler to handle.
Note that neither this structure nor its contents are passed between
libcrypto and the providers. Instead, the numeric identities are
translated to and from names, which are then passed over that
boundary.
For future considerations, we might consider dropping RSA_PSS_PARAMS
entirely. For now, it's still reserved for EVP_PKEY_ASN1_METHOD code,
which RSA_PSS_PARAMS_30 is (almost entirely) reserved for use in our
providers.
(*) We use NIDs in this case, because we already have them and because
only algorithms that libcrypto knows about are permitted in PSS
restrictions. We could use any number series we want, as long as we
know for sure what they represent.
(**) That's for saltlen and for trailerfield, which are never expect
to surpass the set of numbers that fit in a regular 'int'.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/11710)
2020-05-02 18:46:55 +08:00
|
|
|
{
|
|
|
|
if (rsa_pss_params == NULL)
|
|
|
|
return 0;
|
|
|
|
*rsa_pss_params = default_RSASSA_PSS_params;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
rsa: add ossl_ prefix to internal rsa_ calls.
The functions being:
rsa_check_crt_components, rsa_check_key, rsa_check_pminusq_diff,
rsa_check_prime_factor, rsa_check_prime_factor_range,
rsa_check_private_exponent, rsa_check_public_exponent,
rsa_digestinfo_encoding, rsa_fips186_4_gen_prob_primes, rsa_fromdata,
rsa_get0_all_params, rsa_get0_libctx, rsa_get0_pss_params_30,
rsa_get_lcm, rsa_mgf_nid2name, rsa_mp_coeff_names, rsa_mp_exp_names,
rsa_mp_factor_names, rsa_new_with_ctx, rsa_oaeppss_md2nid,
rsa_oaeppss_nid2name, rsa_padding_add_PKCS1_OAEP_mgf1_with_libctx,
rsa_padding_add_PKCS1_type_2_with_libctx,
rsa_padding_add_SSLv23_with_libctx, rsa_padding_check_PKCS1_type_2_TLS,
rsa_pkey_method, rsa_pss_params_30_copy, rsa_pss_params_30_fromdata,
rsa_pss_params_30_hashalg, rsa_pss_params_30_is_unrestricted,
rsa_pss_params_30_maskgenalg, rsa_pss_params_30_maskgenhashalg,
rsa_pss_params_30_saltlen, rsa_pss_params_30_set_defaults,
rsa_pss_params_30_set_hashalg, rsa_pss_params_30_set_maskgenalg,
rsa_pss_params_30_set_maskgenhashalg, rsa_pss_params_30_set_saltlen,
rsa_pss_params_30_set_trailerfield, rsa_pss_params_30_todata,
rsa_pss_params_30_trailerfield, rsa_pss_pkey_method, rsa_set0_all_params,
rsa_sp800_56b_check_keypair, rsa_sp800_56b_check_private,
rsa_sp800_56b_check_public, rsa_sp800_56b_derive_params_from_pq,
rsa_sp800_56b_generate_key, rsa_sp800_56b_pairwise_test,
rsa_sp800_56b_validate_strength, rsa_todata, rsa_validate_pairwise,
rsa_validate_private and rsa_validate_public.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13040)
2020-09-30 12:20:14 +08:00
|
|
|
int ossl_rsa_pss_params_30_is_unrestricted(const RSA_PSS_PARAMS_30 *rsa_pss_params)
|
RSA: Add a less loaded PSS-parameter structure
RSA_PSS_PARAMS carries with it a lot of baggage in form of X509_ALGOR
and ASN1_INTEGER, which we would rather avoid in our providers.
Therefore, we create a parallell structure - RSA_PSS_PARAMS_30 - that
contains the same information, but uses numeric identities (*) and C
integers (**). This makes it simpler to handle.
Note that neither this structure nor its contents are passed between
libcrypto and the providers. Instead, the numeric identities are
translated to and from names, which are then passed over that
boundary.
For future considerations, we might consider dropping RSA_PSS_PARAMS
entirely. For now, it's still reserved for EVP_PKEY_ASN1_METHOD code,
which RSA_PSS_PARAMS_30 is (almost entirely) reserved for use in our
providers.
(*) We use NIDs in this case, because we already have them and because
only algorithms that libcrypto knows about are permitted in PSS
restrictions. We could use any number series we want, as long as we
know for sure what they represent.
(**) That's for saltlen and for trailerfield, which are never expect
to surpass the set of numbers that fit in a regular 'int'.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/11710)
2020-05-02 18:46:55 +08:00
|
|
|
{
|
|
|
|
static RSA_PSS_PARAMS_30 pss_params_cmp = { 0, };
|
|
|
|
|
|
|
|
return rsa_pss_params == NULL
|
|
|
|
|| memcmp(rsa_pss_params, &pss_params_cmp,
|
|
|
|
sizeof(*rsa_pss_params)) == 0;
|
|
|
|
}
|
|
|
|
|
rsa: add ossl_ prefix to internal rsa_ calls.
The functions being:
rsa_check_crt_components, rsa_check_key, rsa_check_pminusq_diff,
rsa_check_prime_factor, rsa_check_prime_factor_range,
rsa_check_private_exponent, rsa_check_public_exponent,
rsa_digestinfo_encoding, rsa_fips186_4_gen_prob_primes, rsa_fromdata,
rsa_get0_all_params, rsa_get0_libctx, rsa_get0_pss_params_30,
rsa_get_lcm, rsa_mgf_nid2name, rsa_mp_coeff_names, rsa_mp_exp_names,
rsa_mp_factor_names, rsa_new_with_ctx, rsa_oaeppss_md2nid,
rsa_oaeppss_nid2name, rsa_padding_add_PKCS1_OAEP_mgf1_with_libctx,
rsa_padding_add_PKCS1_type_2_with_libctx,
rsa_padding_add_SSLv23_with_libctx, rsa_padding_check_PKCS1_type_2_TLS,
rsa_pkey_method, rsa_pss_params_30_copy, rsa_pss_params_30_fromdata,
rsa_pss_params_30_hashalg, rsa_pss_params_30_is_unrestricted,
rsa_pss_params_30_maskgenalg, rsa_pss_params_30_maskgenhashalg,
rsa_pss_params_30_saltlen, rsa_pss_params_30_set_defaults,
rsa_pss_params_30_set_hashalg, rsa_pss_params_30_set_maskgenalg,
rsa_pss_params_30_set_maskgenhashalg, rsa_pss_params_30_set_saltlen,
rsa_pss_params_30_set_trailerfield, rsa_pss_params_30_todata,
rsa_pss_params_30_trailerfield, rsa_pss_pkey_method, rsa_set0_all_params,
rsa_sp800_56b_check_keypair, rsa_sp800_56b_check_private,
rsa_sp800_56b_check_public, rsa_sp800_56b_derive_params_from_pq,
rsa_sp800_56b_generate_key, rsa_sp800_56b_pairwise_test,
rsa_sp800_56b_validate_strength, rsa_todata, rsa_validate_pairwise,
rsa_validate_private and rsa_validate_public.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13040)
2020-09-30 12:20:14 +08:00
|
|
|
int ossl_rsa_pss_params_30_copy(RSA_PSS_PARAMS_30 *to,
|
|
|
|
const RSA_PSS_PARAMS_30 *from)
|
RSA: Add a less loaded PSS-parameter structure
RSA_PSS_PARAMS carries with it a lot of baggage in form of X509_ALGOR
and ASN1_INTEGER, which we would rather avoid in our providers.
Therefore, we create a parallell structure - RSA_PSS_PARAMS_30 - that
contains the same information, but uses numeric identities (*) and C
integers (**). This makes it simpler to handle.
Note that neither this structure nor its contents are passed between
libcrypto and the providers. Instead, the numeric identities are
translated to and from names, which are then passed over that
boundary.
For future considerations, we might consider dropping RSA_PSS_PARAMS
entirely. For now, it's still reserved for EVP_PKEY_ASN1_METHOD code,
which RSA_PSS_PARAMS_30 is (almost entirely) reserved for use in our
providers.
(*) We use NIDs in this case, because we already have them and because
only algorithms that libcrypto knows about are permitted in PSS
restrictions. We could use any number series we want, as long as we
know for sure what they represent.
(**) That's for saltlen and for trailerfield, which are never expect
to surpass the set of numbers that fit in a regular 'int'.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/11710)
2020-05-02 18:46:55 +08:00
|
|
|
{
|
|
|
|
memcpy(to, from, sizeof(*to));
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
rsa: add ossl_ prefix to internal rsa_ calls.
The functions being:
rsa_check_crt_components, rsa_check_key, rsa_check_pminusq_diff,
rsa_check_prime_factor, rsa_check_prime_factor_range,
rsa_check_private_exponent, rsa_check_public_exponent,
rsa_digestinfo_encoding, rsa_fips186_4_gen_prob_primes, rsa_fromdata,
rsa_get0_all_params, rsa_get0_libctx, rsa_get0_pss_params_30,
rsa_get_lcm, rsa_mgf_nid2name, rsa_mp_coeff_names, rsa_mp_exp_names,
rsa_mp_factor_names, rsa_new_with_ctx, rsa_oaeppss_md2nid,
rsa_oaeppss_nid2name, rsa_padding_add_PKCS1_OAEP_mgf1_with_libctx,
rsa_padding_add_PKCS1_type_2_with_libctx,
rsa_padding_add_SSLv23_with_libctx, rsa_padding_check_PKCS1_type_2_TLS,
rsa_pkey_method, rsa_pss_params_30_copy, rsa_pss_params_30_fromdata,
rsa_pss_params_30_hashalg, rsa_pss_params_30_is_unrestricted,
rsa_pss_params_30_maskgenalg, rsa_pss_params_30_maskgenhashalg,
rsa_pss_params_30_saltlen, rsa_pss_params_30_set_defaults,
rsa_pss_params_30_set_hashalg, rsa_pss_params_30_set_maskgenalg,
rsa_pss_params_30_set_maskgenhashalg, rsa_pss_params_30_set_saltlen,
rsa_pss_params_30_set_trailerfield, rsa_pss_params_30_todata,
rsa_pss_params_30_trailerfield, rsa_pss_pkey_method, rsa_set0_all_params,
rsa_sp800_56b_check_keypair, rsa_sp800_56b_check_private,
rsa_sp800_56b_check_public, rsa_sp800_56b_derive_params_from_pq,
rsa_sp800_56b_generate_key, rsa_sp800_56b_pairwise_test,
rsa_sp800_56b_validate_strength, rsa_todata, rsa_validate_pairwise,
rsa_validate_private and rsa_validate_public.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13040)
2020-09-30 12:20:14 +08:00
|
|
|
int ossl_rsa_pss_params_30_set_hashalg(RSA_PSS_PARAMS_30 *rsa_pss_params,
|
|
|
|
int hashalg_nid)
|
RSA: Add a less loaded PSS-parameter structure
RSA_PSS_PARAMS carries with it a lot of baggage in form of X509_ALGOR
and ASN1_INTEGER, which we would rather avoid in our providers.
Therefore, we create a parallell structure - RSA_PSS_PARAMS_30 - that
contains the same information, but uses numeric identities (*) and C
integers (**). This makes it simpler to handle.
Note that neither this structure nor its contents are passed between
libcrypto and the providers. Instead, the numeric identities are
translated to and from names, which are then passed over that
boundary.
For future considerations, we might consider dropping RSA_PSS_PARAMS
entirely. For now, it's still reserved for EVP_PKEY_ASN1_METHOD code,
which RSA_PSS_PARAMS_30 is (almost entirely) reserved for use in our
providers.
(*) We use NIDs in this case, because we already have them and because
only algorithms that libcrypto knows about are permitted in PSS
restrictions. We could use any number series we want, as long as we
know for sure what they represent.
(**) That's for saltlen and for trailerfield, which are never expect
to surpass the set of numbers that fit in a regular 'int'.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/11710)
2020-05-02 18:46:55 +08:00
|
|
|
{
|
|
|
|
if (rsa_pss_params == NULL)
|
|
|
|
return 0;
|
|
|
|
rsa_pss_params->hash_algorithm_nid = hashalg_nid;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
rsa: add ossl_ prefix to internal rsa_ calls.
The functions being:
rsa_check_crt_components, rsa_check_key, rsa_check_pminusq_diff,
rsa_check_prime_factor, rsa_check_prime_factor_range,
rsa_check_private_exponent, rsa_check_public_exponent,
rsa_digestinfo_encoding, rsa_fips186_4_gen_prob_primes, rsa_fromdata,
rsa_get0_all_params, rsa_get0_libctx, rsa_get0_pss_params_30,
rsa_get_lcm, rsa_mgf_nid2name, rsa_mp_coeff_names, rsa_mp_exp_names,
rsa_mp_factor_names, rsa_new_with_ctx, rsa_oaeppss_md2nid,
rsa_oaeppss_nid2name, rsa_padding_add_PKCS1_OAEP_mgf1_with_libctx,
rsa_padding_add_PKCS1_type_2_with_libctx,
rsa_padding_add_SSLv23_with_libctx, rsa_padding_check_PKCS1_type_2_TLS,
rsa_pkey_method, rsa_pss_params_30_copy, rsa_pss_params_30_fromdata,
rsa_pss_params_30_hashalg, rsa_pss_params_30_is_unrestricted,
rsa_pss_params_30_maskgenalg, rsa_pss_params_30_maskgenhashalg,
rsa_pss_params_30_saltlen, rsa_pss_params_30_set_defaults,
rsa_pss_params_30_set_hashalg, rsa_pss_params_30_set_maskgenalg,
rsa_pss_params_30_set_maskgenhashalg, rsa_pss_params_30_set_saltlen,
rsa_pss_params_30_set_trailerfield, rsa_pss_params_30_todata,
rsa_pss_params_30_trailerfield, rsa_pss_pkey_method, rsa_set0_all_params,
rsa_sp800_56b_check_keypair, rsa_sp800_56b_check_private,
rsa_sp800_56b_check_public, rsa_sp800_56b_derive_params_from_pq,
rsa_sp800_56b_generate_key, rsa_sp800_56b_pairwise_test,
rsa_sp800_56b_validate_strength, rsa_todata, rsa_validate_pairwise,
rsa_validate_private and rsa_validate_public.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13040)
2020-09-30 12:20:14 +08:00
|
|
|
int ossl_rsa_pss_params_30_set_maskgenhashalg(RSA_PSS_PARAMS_30 *rsa_pss_params,
|
|
|
|
int maskgenhashalg_nid)
|
RSA: Add a less loaded PSS-parameter structure
RSA_PSS_PARAMS carries with it a lot of baggage in form of X509_ALGOR
and ASN1_INTEGER, which we would rather avoid in our providers.
Therefore, we create a parallell structure - RSA_PSS_PARAMS_30 - that
contains the same information, but uses numeric identities (*) and C
integers (**). This makes it simpler to handle.
Note that neither this structure nor its contents are passed between
libcrypto and the providers. Instead, the numeric identities are
translated to and from names, which are then passed over that
boundary.
For future considerations, we might consider dropping RSA_PSS_PARAMS
entirely. For now, it's still reserved for EVP_PKEY_ASN1_METHOD code,
which RSA_PSS_PARAMS_30 is (almost entirely) reserved for use in our
providers.
(*) We use NIDs in this case, because we already have them and because
only algorithms that libcrypto knows about are permitted in PSS
restrictions. We could use any number series we want, as long as we
know for sure what they represent.
(**) That's for saltlen and for trailerfield, which are never expect
to surpass the set of numbers that fit in a regular 'int'.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/11710)
2020-05-02 18:46:55 +08:00
|
|
|
{
|
|
|
|
if (rsa_pss_params == NULL)
|
|
|
|
return 0;
|
|
|
|
rsa_pss_params->mask_gen.hash_algorithm_nid = maskgenhashalg_nid;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
rsa: add ossl_ prefix to internal rsa_ calls.
The functions being:
rsa_check_crt_components, rsa_check_key, rsa_check_pminusq_diff,
rsa_check_prime_factor, rsa_check_prime_factor_range,
rsa_check_private_exponent, rsa_check_public_exponent,
rsa_digestinfo_encoding, rsa_fips186_4_gen_prob_primes, rsa_fromdata,
rsa_get0_all_params, rsa_get0_libctx, rsa_get0_pss_params_30,
rsa_get_lcm, rsa_mgf_nid2name, rsa_mp_coeff_names, rsa_mp_exp_names,
rsa_mp_factor_names, rsa_new_with_ctx, rsa_oaeppss_md2nid,
rsa_oaeppss_nid2name, rsa_padding_add_PKCS1_OAEP_mgf1_with_libctx,
rsa_padding_add_PKCS1_type_2_with_libctx,
rsa_padding_add_SSLv23_with_libctx, rsa_padding_check_PKCS1_type_2_TLS,
rsa_pkey_method, rsa_pss_params_30_copy, rsa_pss_params_30_fromdata,
rsa_pss_params_30_hashalg, rsa_pss_params_30_is_unrestricted,
rsa_pss_params_30_maskgenalg, rsa_pss_params_30_maskgenhashalg,
rsa_pss_params_30_saltlen, rsa_pss_params_30_set_defaults,
rsa_pss_params_30_set_hashalg, rsa_pss_params_30_set_maskgenalg,
rsa_pss_params_30_set_maskgenhashalg, rsa_pss_params_30_set_saltlen,
rsa_pss_params_30_set_trailerfield, rsa_pss_params_30_todata,
rsa_pss_params_30_trailerfield, rsa_pss_pkey_method, rsa_set0_all_params,
rsa_sp800_56b_check_keypair, rsa_sp800_56b_check_private,
rsa_sp800_56b_check_public, rsa_sp800_56b_derive_params_from_pq,
rsa_sp800_56b_generate_key, rsa_sp800_56b_pairwise_test,
rsa_sp800_56b_validate_strength, rsa_todata, rsa_validate_pairwise,
rsa_validate_private and rsa_validate_public.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13040)
2020-09-30 12:20:14 +08:00
|
|
|
int ossl_rsa_pss_params_30_set_saltlen(RSA_PSS_PARAMS_30 *rsa_pss_params,
|
|
|
|
int saltlen)
|
RSA: Add a less loaded PSS-parameter structure
RSA_PSS_PARAMS carries with it a lot of baggage in form of X509_ALGOR
and ASN1_INTEGER, which we would rather avoid in our providers.
Therefore, we create a parallell structure - RSA_PSS_PARAMS_30 - that
contains the same information, but uses numeric identities (*) and C
integers (**). This makes it simpler to handle.
Note that neither this structure nor its contents are passed between
libcrypto and the providers. Instead, the numeric identities are
translated to and from names, which are then passed over that
boundary.
For future considerations, we might consider dropping RSA_PSS_PARAMS
entirely. For now, it's still reserved for EVP_PKEY_ASN1_METHOD code,
which RSA_PSS_PARAMS_30 is (almost entirely) reserved for use in our
providers.
(*) We use NIDs in this case, because we already have them and because
only algorithms that libcrypto knows about are permitted in PSS
restrictions. We could use any number series we want, as long as we
know for sure what they represent.
(**) That's for saltlen and for trailerfield, which are never expect
to surpass the set of numbers that fit in a regular 'int'.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/11710)
2020-05-02 18:46:55 +08:00
|
|
|
{
|
|
|
|
if (rsa_pss_params == NULL)
|
|
|
|
return 0;
|
|
|
|
rsa_pss_params->salt_len = saltlen;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
rsa: add ossl_ prefix to internal rsa_ calls.
The functions being:
rsa_check_crt_components, rsa_check_key, rsa_check_pminusq_diff,
rsa_check_prime_factor, rsa_check_prime_factor_range,
rsa_check_private_exponent, rsa_check_public_exponent,
rsa_digestinfo_encoding, rsa_fips186_4_gen_prob_primes, rsa_fromdata,
rsa_get0_all_params, rsa_get0_libctx, rsa_get0_pss_params_30,
rsa_get_lcm, rsa_mgf_nid2name, rsa_mp_coeff_names, rsa_mp_exp_names,
rsa_mp_factor_names, rsa_new_with_ctx, rsa_oaeppss_md2nid,
rsa_oaeppss_nid2name, rsa_padding_add_PKCS1_OAEP_mgf1_with_libctx,
rsa_padding_add_PKCS1_type_2_with_libctx,
rsa_padding_add_SSLv23_with_libctx, rsa_padding_check_PKCS1_type_2_TLS,
rsa_pkey_method, rsa_pss_params_30_copy, rsa_pss_params_30_fromdata,
rsa_pss_params_30_hashalg, rsa_pss_params_30_is_unrestricted,
rsa_pss_params_30_maskgenalg, rsa_pss_params_30_maskgenhashalg,
rsa_pss_params_30_saltlen, rsa_pss_params_30_set_defaults,
rsa_pss_params_30_set_hashalg, rsa_pss_params_30_set_maskgenalg,
rsa_pss_params_30_set_maskgenhashalg, rsa_pss_params_30_set_saltlen,
rsa_pss_params_30_set_trailerfield, rsa_pss_params_30_todata,
rsa_pss_params_30_trailerfield, rsa_pss_pkey_method, rsa_set0_all_params,
rsa_sp800_56b_check_keypair, rsa_sp800_56b_check_private,
rsa_sp800_56b_check_public, rsa_sp800_56b_derive_params_from_pq,
rsa_sp800_56b_generate_key, rsa_sp800_56b_pairwise_test,
rsa_sp800_56b_validate_strength, rsa_todata, rsa_validate_pairwise,
rsa_validate_private and rsa_validate_public.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13040)
2020-09-30 12:20:14 +08:00
|
|
|
int ossl_rsa_pss_params_30_set_trailerfield(RSA_PSS_PARAMS_30 *rsa_pss_params,
|
|
|
|
int trailerfield)
|
RSA: Add a less loaded PSS-parameter structure
RSA_PSS_PARAMS carries with it a lot of baggage in form of X509_ALGOR
and ASN1_INTEGER, which we would rather avoid in our providers.
Therefore, we create a parallell structure - RSA_PSS_PARAMS_30 - that
contains the same information, but uses numeric identities (*) and C
integers (**). This makes it simpler to handle.
Note that neither this structure nor its contents are passed between
libcrypto and the providers. Instead, the numeric identities are
translated to and from names, which are then passed over that
boundary.
For future considerations, we might consider dropping RSA_PSS_PARAMS
entirely. For now, it's still reserved for EVP_PKEY_ASN1_METHOD code,
which RSA_PSS_PARAMS_30 is (almost entirely) reserved for use in our
providers.
(*) We use NIDs in this case, because we already have them and because
only algorithms that libcrypto knows about are permitted in PSS
restrictions. We could use any number series we want, as long as we
know for sure what they represent.
(**) That's for saltlen and for trailerfield, which are never expect
to surpass the set of numbers that fit in a regular 'int'.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/11710)
2020-05-02 18:46:55 +08:00
|
|
|
{
|
|
|
|
if (rsa_pss_params == NULL)
|
|
|
|
return 0;
|
|
|
|
rsa_pss_params->trailer_field = trailerfield;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
rsa: add ossl_ prefix to internal rsa_ calls.
The functions being:
rsa_check_crt_components, rsa_check_key, rsa_check_pminusq_diff,
rsa_check_prime_factor, rsa_check_prime_factor_range,
rsa_check_private_exponent, rsa_check_public_exponent,
rsa_digestinfo_encoding, rsa_fips186_4_gen_prob_primes, rsa_fromdata,
rsa_get0_all_params, rsa_get0_libctx, rsa_get0_pss_params_30,
rsa_get_lcm, rsa_mgf_nid2name, rsa_mp_coeff_names, rsa_mp_exp_names,
rsa_mp_factor_names, rsa_new_with_ctx, rsa_oaeppss_md2nid,
rsa_oaeppss_nid2name, rsa_padding_add_PKCS1_OAEP_mgf1_with_libctx,
rsa_padding_add_PKCS1_type_2_with_libctx,
rsa_padding_add_SSLv23_with_libctx, rsa_padding_check_PKCS1_type_2_TLS,
rsa_pkey_method, rsa_pss_params_30_copy, rsa_pss_params_30_fromdata,
rsa_pss_params_30_hashalg, rsa_pss_params_30_is_unrestricted,
rsa_pss_params_30_maskgenalg, rsa_pss_params_30_maskgenhashalg,
rsa_pss_params_30_saltlen, rsa_pss_params_30_set_defaults,
rsa_pss_params_30_set_hashalg, rsa_pss_params_30_set_maskgenalg,
rsa_pss_params_30_set_maskgenhashalg, rsa_pss_params_30_set_saltlen,
rsa_pss_params_30_set_trailerfield, rsa_pss_params_30_todata,
rsa_pss_params_30_trailerfield, rsa_pss_pkey_method, rsa_set0_all_params,
rsa_sp800_56b_check_keypair, rsa_sp800_56b_check_private,
rsa_sp800_56b_check_public, rsa_sp800_56b_derive_params_from_pq,
rsa_sp800_56b_generate_key, rsa_sp800_56b_pairwise_test,
rsa_sp800_56b_validate_strength, rsa_todata, rsa_validate_pairwise,
rsa_validate_private and rsa_validate_public.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13040)
2020-09-30 12:20:14 +08:00
|
|
|
int ossl_rsa_pss_params_30_hashalg(const RSA_PSS_PARAMS_30 *rsa_pss_params)
|
RSA: Add a less loaded PSS-parameter structure
RSA_PSS_PARAMS carries with it a lot of baggage in form of X509_ALGOR
and ASN1_INTEGER, which we would rather avoid in our providers.
Therefore, we create a parallell structure - RSA_PSS_PARAMS_30 - that
contains the same information, but uses numeric identities (*) and C
integers (**). This makes it simpler to handle.
Note that neither this structure nor its contents are passed between
libcrypto and the providers. Instead, the numeric identities are
translated to and from names, which are then passed over that
boundary.
For future considerations, we might consider dropping RSA_PSS_PARAMS
entirely. For now, it's still reserved for EVP_PKEY_ASN1_METHOD code,
which RSA_PSS_PARAMS_30 is (almost entirely) reserved for use in our
providers.
(*) We use NIDs in this case, because we already have them and because
only algorithms that libcrypto knows about are permitted in PSS
restrictions. We could use any number series we want, as long as we
know for sure what they represent.
(**) That's for saltlen and for trailerfield, which are never expect
to surpass the set of numbers that fit in a regular 'int'.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/11710)
2020-05-02 18:46:55 +08:00
|
|
|
{
|
|
|
|
if (rsa_pss_params == NULL)
|
|
|
|
return default_RSASSA_PSS_params.hash_algorithm_nid;
|
|
|
|
return rsa_pss_params->hash_algorithm_nid;
|
|
|
|
}
|
|
|
|
|
rsa: add ossl_ prefix to internal rsa_ calls.
The functions being:
rsa_check_crt_components, rsa_check_key, rsa_check_pminusq_diff,
rsa_check_prime_factor, rsa_check_prime_factor_range,
rsa_check_private_exponent, rsa_check_public_exponent,
rsa_digestinfo_encoding, rsa_fips186_4_gen_prob_primes, rsa_fromdata,
rsa_get0_all_params, rsa_get0_libctx, rsa_get0_pss_params_30,
rsa_get_lcm, rsa_mgf_nid2name, rsa_mp_coeff_names, rsa_mp_exp_names,
rsa_mp_factor_names, rsa_new_with_ctx, rsa_oaeppss_md2nid,
rsa_oaeppss_nid2name, rsa_padding_add_PKCS1_OAEP_mgf1_with_libctx,
rsa_padding_add_PKCS1_type_2_with_libctx,
rsa_padding_add_SSLv23_with_libctx, rsa_padding_check_PKCS1_type_2_TLS,
rsa_pkey_method, rsa_pss_params_30_copy, rsa_pss_params_30_fromdata,
rsa_pss_params_30_hashalg, rsa_pss_params_30_is_unrestricted,
rsa_pss_params_30_maskgenalg, rsa_pss_params_30_maskgenhashalg,
rsa_pss_params_30_saltlen, rsa_pss_params_30_set_defaults,
rsa_pss_params_30_set_hashalg, rsa_pss_params_30_set_maskgenalg,
rsa_pss_params_30_set_maskgenhashalg, rsa_pss_params_30_set_saltlen,
rsa_pss_params_30_set_trailerfield, rsa_pss_params_30_todata,
rsa_pss_params_30_trailerfield, rsa_pss_pkey_method, rsa_set0_all_params,
rsa_sp800_56b_check_keypair, rsa_sp800_56b_check_private,
rsa_sp800_56b_check_public, rsa_sp800_56b_derive_params_from_pq,
rsa_sp800_56b_generate_key, rsa_sp800_56b_pairwise_test,
rsa_sp800_56b_validate_strength, rsa_todata, rsa_validate_pairwise,
rsa_validate_private and rsa_validate_public.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13040)
2020-09-30 12:20:14 +08:00
|
|
|
int ossl_rsa_pss_params_30_maskgenalg(const RSA_PSS_PARAMS_30 *rsa_pss_params)
|
RSA: Add a less loaded PSS-parameter structure
RSA_PSS_PARAMS carries with it a lot of baggage in form of X509_ALGOR
and ASN1_INTEGER, which we would rather avoid in our providers.
Therefore, we create a parallell structure - RSA_PSS_PARAMS_30 - that
contains the same information, but uses numeric identities (*) and C
integers (**). This makes it simpler to handle.
Note that neither this structure nor its contents are passed between
libcrypto and the providers. Instead, the numeric identities are
translated to and from names, which are then passed over that
boundary.
For future considerations, we might consider dropping RSA_PSS_PARAMS
entirely. For now, it's still reserved for EVP_PKEY_ASN1_METHOD code,
which RSA_PSS_PARAMS_30 is (almost entirely) reserved for use in our
providers.
(*) We use NIDs in this case, because we already have them and because
only algorithms that libcrypto knows about are permitted in PSS
restrictions. We could use any number series we want, as long as we
know for sure what they represent.
(**) That's for saltlen and for trailerfield, which are never expect
to surpass the set of numbers that fit in a regular 'int'.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/11710)
2020-05-02 18:46:55 +08:00
|
|
|
{
|
|
|
|
if (rsa_pss_params == NULL)
|
|
|
|
return default_RSASSA_PSS_params.mask_gen.algorithm_nid;
|
|
|
|
return rsa_pss_params->mask_gen.algorithm_nid;
|
|
|
|
}
|
|
|
|
|
rsa: add ossl_ prefix to internal rsa_ calls.
The functions being:
rsa_check_crt_components, rsa_check_key, rsa_check_pminusq_diff,
rsa_check_prime_factor, rsa_check_prime_factor_range,
rsa_check_private_exponent, rsa_check_public_exponent,
rsa_digestinfo_encoding, rsa_fips186_4_gen_prob_primes, rsa_fromdata,
rsa_get0_all_params, rsa_get0_libctx, rsa_get0_pss_params_30,
rsa_get_lcm, rsa_mgf_nid2name, rsa_mp_coeff_names, rsa_mp_exp_names,
rsa_mp_factor_names, rsa_new_with_ctx, rsa_oaeppss_md2nid,
rsa_oaeppss_nid2name, rsa_padding_add_PKCS1_OAEP_mgf1_with_libctx,
rsa_padding_add_PKCS1_type_2_with_libctx,
rsa_padding_add_SSLv23_with_libctx, rsa_padding_check_PKCS1_type_2_TLS,
rsa_pkey_method, rsa_pss_params_30_copy, rsa_pss_params_30_fromdata,
rsa_pss_params_30_hashalg, rsa_pss_params_30_is_unrestricted,
rsa_pss_params_30_maskgenalg, rsa_pss_params_30_maskgenhashalg,
rsa_pss_params_30_saltlen, rsa_pss_params_30_set_defaults,
rsa_pss_params_30_set_hashalg, rsa_pss_params_30_set_maskgenalg,
rsa_pss_params_30_set_maskgenhashalg, rsa_pss_params_30_set_saltlen,
rsa_pss_params_30_set_trailerfield, rsa_pss_params_30_todata,
rsa_pss_params_30_trailerfield, rsa_pss_pkey_method, rsa_set0_all_params,
rsa_sp800_56b_check_keypair, rsa_sp800_56b_check_private,
rsa_sp800_56b_check_public, rsa_sp800_56b_derive_params_from_pq,
rsa_sp800_56b_generate_key, rsa_sp800_56b_pairwise_test,
rsa_sp800_56b_validate_strength, rsa_todata, rsa_validate_pairwise,
rsa_validate_private and rsa_validate_public.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13040)
2020-09-30 12:20:14 +08:00
|
|
|
int ossl_rsa_pss_params_30_maskgenhashalg(const RSA_PSS_PARAMS_30 *rsa_pss_params)
|
RSA: Add a less loaded PSS-parameter structure
RSA_PSS_PARAMS carries with it a lot of baggage in form of X509_ALGOR
and ASN1_INTEGER, which we would rather avoid in our providers.
Therefore, we create a parallell structure - RSA_PSS_PARAMS_30 - that
contains the same information, but uses numeric identities (*) and C
integers (**). This makes it simpler to handle.
Note that neither this structure nor its contents are passed between
libcrypto and the providers. Instead, the numeric identities are
translated to and from names, which are then passed over that
boundary.
For future considerations, we might consider dropping RSA_PSS_PARAMS
entirely. For now, it's still reserved for EVP_PKEY_ASN1_METHOD code,
which RSA_PSS_PARAMS_30 is (almost entirely) reserved for use in our
providers.
(*) We use NIDs in this case, because we already have them and because
only algorithms that libcrypto knows about are permitted in PSS
restrictions. We could use any number series we want, as long as we
know for sure what they represent.
(**) That's for saltlen and for trailerfield, which are never expect
to surpass the set of numbers that fit in a regular 'int'.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/11710)
2020-05-02 18:46:55 +08:00
|
|
|
{
|
|
|
|
if (rsa_pss_params == NULL)
|
|
|
|
return default_RSASSA_PSS_params.hash_algorithm_nid;
|
|
|
|
return rsa_pss_params->mask_gen.hash_algorithm_nid;
|
|
|
|
}
|
|
|
|
|
rsa: add ossl_ prefix to internal rsa_ calls.
The functions being:
rsa_check_crt_components, rsa_check_key, rsa_check_pminusq_diff,
rsa_check_prime_factor, rsa_check_prime_factor_range,
rsa_check_private_exponent, rsa_check_public_exponent,
rsa_digestinfo_encoding, rsa_fips186_4_gen_prob_primes, rsa_fromdata,
rsa_get0_all_params, rsa_get0_libctx, rsa_get0_pss_params_30,
rsa_get_lcm, rsa_mgf_nid2name, rsa_mp_coeff_names, rsa_mp_exp_names,
rsa_mp_factor_names, rsa_new_with_ctx, rsa_oaeppss_md2nid,
rsa_oaeppss_nid2name, rsa_padding_add_PKCS1_OAEP_mgf1_with_libctx,
rsa_padding_add_PKCS1_type_2_with_libctx,
rsa_padding_add_SSLv23_with_libctx, rsa_padding_check_PKCS1_type_2_TLS,
rsa_pkey_method, rsa_pss_params_30_copy, rsa_pss_params_30_fromdata,
rsa_pss_params_30_hashalg, rsa_pss_params_30_is_unrestricted,
rsa_pss_params_30_maskgenalg, rsa_pss_params_30_maskgenhashalg,
rsa_pss_params_30_saltlen, rsa_pss_params_30_set_defaults,
rsa_pss_params_30_set_hashalg, rsa_pss_params_30_set_maskgenalg,
rsa_pss_params_30_set_maskgenhashalg, rsa_pss_params_30_set_saltlen,
rsa_pss_params_30_set_trailerfield, rsa_pss_params_30_todata,
rsa_pss_params_30_trailerfield, rsa_pss_pkey_method, rsa_set0_all_params,
rsa_sp800_56b_check_keypair, rsa_sp800_56b_check_private,
rsa_sp800_56b_check_public, rsa_sp800_56b_derive_params_from_pq,
rsa_sp800_56b_generate_key, rsa_sp800_56b_pairwise_test,
rsa_sp800_56b_validate_strength, rsa_todata, rsa_validate_pairwise,
rsa_validate_private and rsa_validate_public.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13040)
2020-09-30 12:20:14 +08:00
|
|
|
int ossl_rsa_pss_params_30_saltlen(const RSA_PSS_PARAMS_30 *rsa_pss_params)
|
RSA: Add a less loaded PSS-parameter structure
RSA_PSS_PARAMS carries with it a lot of baggage in form of X509_ALGOR
and ASN1_INTEGER, which we would rather avoid in our providers.
Therefore, we create a parallell structure - RSA_PSS_PARAMS_30 - that
contains the same information, but uses numeric identities (*) and C
integers (**). This makes it simpler to handle.
Note that neither this structure nor its contents are passed between
libcrypto and the providers. Instead, the numeric identities are
translated to and from names, which are then passed over that
boundary.
For future considerations, we might consider dropping RSA_PSS_PARAMS
entirely. For now, it's still reserved for EVP_PKEY_ASN1_METHOD code,
which RSA_PSS_PARAMS_30 is (almost entirely) reserved for use in our
providers.
(*) We use NIDs in this case, because we already have them and because
only algorithms that libcrypto knows about are permitted in PSS
restrictions. We could use any number series we want, as long as we
know for sure what they represent.
(**) That's for saltlen and for trailerfield, which are never expect
to surpass the set of numbers that fit in a regular 'int'.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/11710)
2020-05-02 18:46:55 +08:00
|
|
|
{
|
|
|
|
if (rsa_pss_params == NULL)
|
|
|
|
return default_RSASSA_PSS_params.salt_len;
|
|
|
|
return rsa_pss_params->salt_len;
|
|
|
|
}
|
|
|
|
|
rsa: add ossl_ prefix to internal rsa_ calls.
The functions being:
rsa_check_crt_components, rsa_check_key, rsa_check_pminusq_diff,
rsa_check_prime_factor, rsa_check_prime_factor_range,
rsa_check_private_exponent, rsa_check_public_exponent,
rsa_digestinfo_encoding, rsa_fips186_4_gen_prob_primes, rsa_fromdata,
rsa_get0_all_params, rsa_get0_libctx, rsa_get0_pss_params_30,
rsa_get_lcm, rsa_mgf_nid2name, rsa_mp_coeff_names, rsa_mp_exp_names,
rsa_mp_factor_names, rsa_new_with_ctx, rsa_oaeppss_md2nid,
rsa_oaeppss_nid2name, rsa_padding_add_PKCS1_OAEP_mgf1_with_libctx,
rsa_padding_add_PKCS1_type_2_with_libctx,
rsa_padding_add_SSLv23_with_libctx, rsa_padding_check_PKCS1_type_2_TLS,
rsa_pkey_method, rsa_pss_params_30_copy, rsa_pss_params_30_fromdata,
rsa_pss_params_30_hashalg, rsa_pss_params_30_is_unrestricted,
rsa_pss_params_30_maskgenalg, rsa_pss_params_30_maskgenhashalg,
rsa_pss_params_30_saltlen, rsa_pss_params_30_set_defaults,
rsa_pss_params_30_set_hashalg, rsa_pss_params_30_set_maskgenalg,
rsa_pss_params_30_set_maskgenhashalg, rsa_pss_params_30_set_saltlen,
rsa_pss_params_30_set_trailerfield, rsa_pss_params_30_todata,
rsa_pss_params_30_trailerfield, rsa_pss_pkey_method, rsa_set0_all_params,
rsa_sp800_56b_check_keypair, rsa_sp800_56b_check_private,
rsa_sp800_56b_check_public, rsa_sp800_56b_derive_params_from_pq,
rsa_sp800_56b_generate_key, rsa_sp800_56b_pairwise_test,
rsa_sp800_56b_validate_strength, rsa_todata, rsa_validate_pairwise,
rsa_validate_private and rsa_validate_public.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13040)
2020-09-30 12:20:14 +08:00
|
|
|
int ossl_rsa_pss_params_30_trailerfield(const RSA_PSS_PARAMS_30 *rsa_pss_params)
|
RSA: Add a less loaded PSS-parameter structure
RSA_PSS_PARAMS carries with it a lot of baggage in form of X509_ALGOR
and ASN1_INTEGER, which we would rather avoid in our providers.
Therefore, we create a parallell structure - RSA_PSS_PARAMS_30 - that
contains the same information, but uses numeric identities (*) and C
integers (**). This makes it simpler to handle.
Note that neither this structure nor its contents are passed between
libcrypto and the providers. Instead, the numeric identities are
translated to and from names, which are then passed over that
boundary.
For future considerations, we might consider dropping RSA_PSS_PARAMS
entirely. For now, it's still reserved for EVP_PKEY_ASN1_METHOD code,
which RSA_PSS_PARAMS_30 is (almost entirely) reserved for use in our
providers.
(*) We use NIDs in this case, because we already have them and because
only algorithms that libcrypto knows about are permitted in PSS
restrictions. We could use any number series we want, as long as we
know for sure what they represent.
(**) That's for saltlen and for trailerfield, which are never expect
to surpass the set of numbers that fit in a regular 'int'.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/11710)
2020-05-02 18:46:55 +08:00
|
|
|
{
|
|
|
|
if (rsa_pss_params == NULL)
|
|
|
|
return default_RSASSA_PSS_params.trailer_field;
|
|
|
|
return rsa_pss_params->trailer_field;
|
|
|
|
}
|
|
|
|
|
2005-08-08 06:21:49 +08:00
|
|
|
#if defined(_MSC_VER)
|
2015-01-22 11:40:55 +08:00
|
|
|
# pragma optimize("",on)
|
2005-08-08 06:21:49 +08:00
|
|
|
#endif
|