RE: Updating RSA public key generation and signature verification from 1.1.1 to 3.0
[AMD Official Use Only - General]
Hello Tomas,
There was a logic error in my code, I did not realize that the first iteration
of the verification was supposed to fail. The verification is working
correctly! I apologize for my last response. I really appreciate all your help!
Thank you very much,
Diego Gonzalez
--
-Original Message-
From: Tomas Mraz
Sent: Friday, September 30, 2022 1:22 AM
To: GonzalezVillalobos, Diego ;
openssl-users@openssl.org
Subject: Re: Updating RSA public key generation and signature verification from
1.1.1 to 3.0
Caution: This message originated from an External Source. Use proper caution
when opening attachments, clicking links, or responding.
Hi,
unfortunately I do not see anything wrong with the code. Does the
EVP_DigestVerifyFinal return 0 or negative value? I do not think this is a bug
in OpenSSL as this API is thoroughly tested and it is highly improbable that
there would be a bug in the ECDSA verification through this API.
I am currently out of ideas on what could be wrong or how to investigate
further. Perhaps someone else can chime in on what can be wrong?
Tomas
On Thu, 2022-09-29 at 19:22 +, GonzalezVillalobos, Diego wrote:
> [AMD Official Use Only - General]
>
> Hello Tomas,
>
> So, I made sure that px_size and py_size are equal to the group order
> (48). I was able to verify successfully using our previous method
> (deprecated) with the new key generation method, but I'm still not
> able to get the digestverify to work successfully. As a reminder this
> is how we were verifying before:
>
> // Determine if SHA_TYPE is 256 bit or 384 bit if
> (parent_cert->pub_key_algo == SEV_SIG_ALGO_RSA_SHA256 ||
> parent_cert->pub_key_algo == SEV_SIG_ALGO_ECDSA_SHA256 ||parent_cert-
> >pub_key_algo == SEV_SIG_ALGO_ECDH_SHA256)
> {
> sha_type = SHA_TYPE_256;
> sha_digest = sha_digest_256;
> sha_length = sizeof(hmac_sha_256);
> }
> else if (parent_cert->pub_key_algo == SEV_SIG_ALGO_RSA_SHA384 ||
> parent_cert->pub_key_algo == SEV_SIG_ALGO_ECDSA_SHA384 ||
> parent_cert->pub_key_algo == SEV_SIG_ALGO_ECDH_SHA384)
> {
> sha_type = SHA_TYPE_384;
> sha_digest = sha_digest_384;
> sha_length = sizeof(hmac_sha_512);
> }
> else
> {
> break;
> }
>
> // 1. SHA256 hash the cert from Version through pub_key
> parameters
> // Calculate the digest of the input message rsa.c ->
> rsa_pss_verify_msg()
> // SHA256/SHA384 hash the cert from the [Version:pub_key]
> params
> uint32_t pub_key_offset = offsetof(sev_cert, sig_1_usage); //
> 16 + sizeof(SEV_PUBKEY)
> if (!digest_sha((uint8_t *)child_cert, pub_key_offset,
> sha_digest, sha_length, sha_type)) {
> break;
> }
> if ((parent_cert->pub_key_algo == SEV_SIG_ALGO_ECDSA_SHA256) ||
> (parent_cert->pub_key_algo ==
> SEV_SIG_ALGO_ECDSA_SHA384) ||
> (parent_cert->pub_key_algo ==
> SEV_SIG_ALGO_ECDH_SHA256) ||
> (parent_cert->pub_key_algo ==
> SEV_SIG_ALGO_ECDH_SHA384)) { // ecdsa.c -> sign_verify_msg
> ECDSA_SIG *tmp_ecdsa_sig = ECDSA_SIG_new();
> BIGNUM *r_big_num = BN_new();
> BIGNUM *s_big_num = BN_new();
>
> // Store the x and y components as separate BIGNUM
> objects. The values in the
> // SEV certificate are little-endian, must reverse
> bytes before storing in BIGNUM
> r_big_num = BN_lebin2bn(cert_sig[i].ecdsa.r,
> sizeof(sev_ecdsa_sig::r), r_big_num);// LE to BE
> s_big_num = BN_lebin2bn(cert_sig[i].ecdsa.s,
> sizeof(sev_ecdsa_sig::s), s_big_num);
>
> // Calling ECDSA_SIG_set0() transfers the memory
> management of the values to
> // the ECDSA_SIG object, and therefore the values that
> have been passed
> // in should not be freed directly after this function
> has been called
> if (ECDSA_SIG_set0(tmp_ecdsa_sig, r_big_num,
> s_big_num) != 1) {
> BN_free(s_big_num); // Frees
> BIGNUMs manually here
> BN_free(r_big_num);
> ECDSA_SIG_free(tmp_ecdsa_sig);
> continue;
> }
> EC_KEY *tmp_ec_key =
> EVP_PKEY_get1_EC_KEY(parent_signing_key); // Make a local key so you
> can free it later
> if (ECDSA_do_verify(sha_digest, (uint32_t)sha_length,
> tmp_ecdsa_sig, tmp_ec_key) != 1) {
> EC_KEY_free(tmp_ec_key);
> ECDSA_SIG_free(tmp_ecdsa_sig); // Frees
> BIGNUMs too
> continue;
> }
>
> found_match = true;
RE: Updating RSA public key generation and signature verification from 1.1.1 to 3.0
> From: openssl-users On Behalf Of Tomas > Mraz > Sent: Friday, 30 September, 2022 00:22 > > unfortunately I do not see anything wrong with the code. Does the > EVP_DigestVerifyFinal return 0 or negative value? I do not think this > is a bug in OpenSSL as this API is thoroughly tested and it is highly > improbable that there would be a bug in the ECDSA verification through > this API. > > I am currently out of ideas on what could be wrong or how to > investigate further. Perhaps someone else can chime in on what can be > wrong? Coincidentally, just yesterday I was helping someone debug a DigestVerify issue. We were consistently getting the "first octet is invalid" error out of the RSA PSS signature verification code, but the same inputs worked with openssl dgst. I wrote a fresh minimal program from scratch (really minimal, with hard-coded filenames for the inputs), and it worked fine as soon as it compiled cleanly. I'd suggest trying that. Get it working in a minimal program first. Make sure you have all the correct OpenSSL headers, and there are no compilation warnings. Then integrate that code into your application. (I didn't have the original application to go back to, in my case, and the person I was working with is in another timezone and had left for the day.) -- Michael Wojcik Distinguished Engineer, Application Modernization and Connectivity
Re: CA/Server configuration
Cyprus Socialite wrote: > I am looking to clarify some conceptual and practical questions I've > accumulated while trying to configure a private 'Root CA - Intermediate > CA - Server' setup. Most of my confusion revolves around the Okay. (The word out there is "Intermediate CA" is a term best used in the context of Bridge/Federation of CAs, and that the term "Subordinate CA" is preferred in the original specifications. I think you are creating a subordinate CA) I think that you have gone some distance and entered into questions which I have very little opinion, and maybe nobody else does other than to observe what choices others have made. Bob, Henk and I maintain two IETF internet-draft repos whose goal it is to act as a demonstration of build two-level ECDSA and EDDSA CA+subordinate. (We never intend to publish as RFC, but preferred ID format) They are at: https://github.com/mcr/draft-moskowitz-ecdsa-pki-1 https://datatracker.ietf.org/doc/html/draft-moskowitz-ecdsa-pki-10 https://github.com/rgmhtt/draft-moskowitz-eddsa-pki > Secondly, how is the absence of a configuration field/section/extension > handled? Does it default to some value (e.g. from /etc/ssl/openssl.cnf) It defaults to whatever openssl.cnf you have pointed to. > or simply remain empty? For example, if I have no interest in OCSP > functionality, is the non-provision of all of the related fields enough > to prevent my certificates being declared invalid because CRL requests > fail? yes. > Thirdly, I would like to understand the difference between the 'digest' > and the 'cipher' and what roles they perform in the communication > process, especially in relation to the actual signing algorithm. As an > aside: I've noticed that using any of the `sha3-*` digests somehow > prevents Windows 10 from verifying my certificates. cipher would not be used in a CA. I would guess Windows10 does not support SHA3? > Onto more practical concerns, I am thoroughly confused by how many > OpenSSL tools seemingly perform the same tasks. For example, one can Yes, because the "openssl" tool is not really intended to be for production. It exists mostly to allow the libraries to be configured and tested. So, it evolved based upon the need of the day, not any master design. I've argued for splitting much of the higher-layer functions that it does into a different git repo, as the tool is too intimate with the libraries, and the continue to be things you can't (easily) do programatically, but the tools do. > Finally, if anyone happens to be in possession of an exhaustive > configuration file that includes *all* possible sections and fields > supported by OpenSSL, I would very much appreciate a copy! Not me. A Xmas-Lights configuration would be interested to look at, but likely more confusing than useful. signature.asc Description: PGP signature
Re: Regarding EVP_PKEY_decrypt()
There is EVP_PKEY_get_size() function which will give you the maximum length the encrypted data can have. Unfortunately it cannot give you the exact length which might be smaller in some cases. Tomas Mraz On Thu, 2022-09-29 at 21:49 +, ANUJ SHARMA wrote: > Hi, > I am working on this function. > result = EVP_PKEY_decrypt(ctx, DecryptedData, , > EncryptedData,256); > > I am getting the encrypted data from a different location and code is > in such a way that we just have a pointer pointing to the starting of > Encrypted data. Meaning -We don't know the encrypted data length. > I passed a pointer of encrypted data to this function and decryption > is also happening properly. > My doubt is whether is there any openssl/EVP_PKEY function or any way > by which we can find the exact encrypted data length before doing the > decryption. > > Thanks in advance for helping me out! -- Tomáš Mráz, OpenSSL
Re: BIO_flush Segmentation Fault Issue
The SSL BIO should have the rbio from the SSL object as the next BIO. If you create the SSL BIO and then BIO_push() the TCP socket BIO into the SSL BIO, it will work correctly. Otherwise, you can just fix the next BIO of the SSL BIO by using BIO_up_ref(socketbio); BIO_set_next(sslbio, socketbio); The SSL BIO should always have a next BIO if properly initialized. Tomas Mraz, OpenSSL On Thu, 2022-09-29 at 13:02 -0700, Jay Foster wrote: > I have an application that constructs a chain of BIOs. Sometimes > this > chain also includes an SSL BIO. Years ago, I ran into a problem that > caused BIO_flush() to segfault on the SSL BIO. This turned out to > happen because the SSL BIO is added using SSL_set_bio() instead of > BIO_push(). SSL_set_bio() results in the SSL BIO always having a > NULL > bio_next value, so BIO_flush then crashes dereferencing this NULL > pointer when it calls BIO_copy_next_retry() on the SSL BIO (see > BIO_CTRL_FLUSH in ssl/bio_ssl.c). > > This was reported as ticket 2615 years ago. > > My question is, how could calling BIO_flush() on a BIO chain with an > SSL > BIO ever work? Is there a way to add the SSL BIO using BIO_push() > instead of SSL_set_bio()? > > Jay > -- Tomáš Mráz, OpenSSL
Re: Updating RSA public key generation and signature verification from 1.1.1 to 3.0
Hi,
unfortunately I do not see anything wrong with the code. Does the
EVP_DigestVerifyFinal return 0 or negative value? I do not think this
is a bug in OpenSSL as this API is thoroughly tested and it is highly
improbable that there would be a bug in the ECDSA verification through
this API.
I am currently out of ideas on what could be wrong or how to
investigate further. Perhaps someone else can chime in on what can be
wrong?
Tomas
On Thu, 2022-09-29 at 19:22 +, GonzalezVillalobos, Diego wrote:
> [AMD Official Use Only - General]
>
> Hello Tomas,
>
> So, I made sure that px_size and py_size are equal to the group order
> (48). I was able to verify successfully using our previous method
> (deprecated) with the new key generation method, but I'm still not
> able to get the digestverify to work successfully. As a reminder this
> is how we were verifying before:
>
> // Determine if SHA_TYPE is 256 bit or 384 bit
> if (parent_cert->pub_key_algo == SEV_SIG_ALGO_RSA_SHA256 ||
> parent_cert->pub_key_algo == SEV_SIG_ALGO_ECDSA_SHA256 ||parent_cert-
> >pub_key_algo == SEV_SIG_ALGO_ECDH_SHA256)
> {
> sha_type = SHA_TYPE_256;
> sha_digest = sha_digest_256;
> sha_length = sizeof(hmac_sha_256);
> }
> else if (parent_cert->pub_key_algo == SEV_SIG_ALGO_RSA_SHA384 ||
> parent_cert->pub_key_algo == SEV_SIG_ALGO_ECDSA_SHA384 ||
> parent_cert->pub_key_algo == SEV_SIG_ALGO_ECDH_SHA384)
> {
> sha_type = SHA_TYPE_384;
> sha_digest = sha_digest_384;
> sha_length = sizeof(hmac_sha_512);
> }
> else
> {
> break;
> }
>
> // 1. SHA256 hash the cert from Version through pub_key
> parameters
> // Calculate the digest of the input message rsa.c ->
> rsa_pss_verify_msg()
> // SHA256/SHA384 hash the cert from the [Version:pub_key]
> params
> uint32_t pub_key_offset = offsetof(sev_cert, sig_1_usage);
> // 16 + sizeof(SEV_PUBKEY)
> if (!digest_sha((uint8_t *)child_cert, pub_key_offset,
> sha_digest, sha_length, sha_type)) {
> break;
> }
> if ((parent_cert->pub_key_algo == SEV_SIG_ALGO_ECDSA_SHA256) ||
> (parent_cert->pub_key_algo ==
> SEV_SIG_ALGO_ECDSA_SHA384) ||
> (parent_cert->pub_key_algo ==
> SEV_SIG_ALGO_ECDH_SHA256) ||
> (parent_cert->pub_key_algo ==
> SEV_SIG_ALGO_ECDH_SHA384)) { // ecdsa.c -> sign_verify_msg
> ECDSA_SIG *tmp_ecdsa_sig = ECDSA_SIG_new();
> BIGNUM *r_big_num = BN_new();
> BIGNUM *s_big_num = BN_new();
>
> // Store the x and y components as separate BIGNUM
> objects. The values in the
> // SEV certificate are little-endian, must reverse
> bytes before storing in BIGNUM
> r_big_num = BN_lebin2bn(cert_sig[i].ecdsa.r,
> sizeof(sev_ecdsa_sig::r), r_big_num); // LE to BE
> s_big_num = BN_lebin2bn(cert_sig[i].ecdsa.s,
> sizeof(sev_ecdsa_sig::s), s_big_num);
>
> // Calling ECDSA_SIG_set0() transfers the memory
> management of the values to
> // the ECDSA_SIG object, and therefore the values
> that have been passed
> // in should not be freed directly after this
> function has been called
> if (ECDSA_SIG_set0(tmp_ecdsa_sig, r_big_num,
> s_big_num) != 1) {
> BN_free(s_big_num); // Frees
> BIGNUMs manually here
> BN_free(r_big_num);
> ECDSA_SIG_free(tmp_ecdsa_sig);
> continue;
> }
> EC_KEY *tmp_ec_key =
> EVP_PKEY_get1_EC_KEY(parent_signing_key); // Make a local key so you
> can free it later
> if (ECDSA_do_verify(sha_digest, (uint32_t)sha_length,
> tmp_ecdsa_sig, tmp_ec_key) != 1) {
> EC_KEY_free(tmp_ec_key);
> ECDSA_SIG_free(tmp_ecdsa_sig); // Frees
> BIGNUMs too
> continue;
> }
>
> found_match = true;
> EC_KEY_free(tmp_ec_key);
> ECDSA_SIG_free(tmp_ecdsa_sig); // Frees BIGNUMs
> too
> break;
> }
>
>
> Digest sha function:
> bool digest_sha(const void *msg, size_t msg_len, uint8_t *digest,
> size_t digest_len, SHA_TYPE sha_type)
> {
> bool ret = false;
>
> do { //TODO 384 vs 512 is all a mess
> if ((sha_type == SHA_TYPE_256 && digest_len !=
> SHA256_DIGEST_LENGTH)/* ||
> (sha_type == SHA_TYPE_384 && digest_len !=
> SHA384_DIGEST_LENGTH)*/)
> break;
>
> if (sha_type == SHA_TYPE_256) {
> SHA256_CTX context;
>
> if (SHA256_Init() != 1)
> break;
> if (SHA256_Update(, (void *)msg, msg_len) != 1)
> break;
> if
