Re: Updating RSA public key generation and signature verification from 1.1.1 to 3.0
I am glad to hear that. Regards, Tomas Mraz, OpenSSL On Fri, 2022-09-30 at 17:18 +, GonzalezVillalobos, Diego wrote: > [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 > >
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_dige
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: Updating RSA public key generation and signature verification from 1.1.1 to 3.0
printf("Failed Final Verify > %s\n",ERR_error_string(ERR_get_error(),NULL)); > cout << "EC Verify error" << endl; > break; > } > > found_match = true; > cout << "SEV EC verification Succesful" << endl; > > if (verify_md_ctx) > EVP_MD_CTX_free(verify_md_ctx); > > break; > } > > The only difference still is using the der signature; besides that, > it is the same. Could it be a bug? > > Thank you, > > Diego Gonzalez > - > - > > > -Original Message- > From: Tomas Mraz > Sent: Thursday, September 29, 2022 1:12 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, > > comments below. > > On Wed, 2022-09-28 at 22:12 +, GonzalezVillalobos, Diego wrote: > > [AMD Official Use Only - General] > > > > Hello Tomas, > > > > I generated the key as you suggested, and I am no longer getting an > > error message! Thank you for that. Here is how I'm generating the > > key > > now: > > > > // SEV certificate are little-endian, must reverse bytes before > > generating key > > if ((cert->pub_key_algo == SEV_SIG_ALGO_ECDSA_SHA256) > > || > > (cert->pub_key_algo == SEV_SIG_ALGO_ECDSA_SHA384)) > > { > > //Grab x param and flip bytes to BE > > memcpy(px, >pub_key.ecdsa.qx, > > ec_group_order); > > if(!sev::reverse_bytes(px, sizeof(px))) > > break; > > //Grab y param and flip bytes to BE > > memcpy(py, >pub_key.ecdsa.qy, > > ec_group_order); > > if(!sev::reverse_bytes(py, sizeof(py))) > > break; > > } > > else if ((cert->pub_key_algo == > > SEV_SIG_ALGO_ECDH_SHA256) || > > (cert->pub_key_algo == > > SEV_SIG_ALGO_ECDH_SHA384)) > > { > > //Grab x param and flip bytes to BE > > memcpy(px, >pub_key.ecdh.qx, ec_group_order); > > if(!sev::reverse_bytes(px, sizeof(px))) > > break; > > //Grab y param and flip bytes to BE > > memcpy(py, >pub_key.ecdh.qy, ec_group_order); > > if(!sev::reverse_bytes(py, sizeof(py))) > > break; > > } > > > > int px_size = sizeof(px)/sizeof(*px); > > int py_size = sizeof(py)/sizeof(*py); > > > > // Will contain x and y components > > unsigned char public_key_xy[1 + px_size + py_size] = > > {0}; > > > > //Add point conversion as first value > > public_key_xy[0] = POINT_CONVERSION_UNCOMPRESSED; > > > > //Add x components after point compression > > memcpy(public_key_xy + 1, px, px_size); > > //Add y components after x > > memcpy(public_key_xy + px_size + 1, py ,py_size); > > > > // int nid = EC_curve_nist2nid("P-384"); // > > NID_secp384r1 > > > > OSSL_PARAM_BLD *params_build = OSSL_PARAM_BLD_new(); > > > > if ( params_build == NULL ) { > > cout << "Params build fails" << endl; > > break; > > } > > > > if (!OSSL_PARAM_BLD_push_utf8_string(params_build, > > OSSL_PKEY_PARAM_GROUP_NAME, "P-384", 0)) { > > cout<< "Push EC curve to build fails" << endl; > > break; > > } > > > > if (!OSSL_PARAM_BLD_push_octet_string(params_build, > > OSSL_PKEY_PARAM_PUB_KEY, public_key_xy, sizeof(public_key_xy))) { > > cout << "Error: failed to push qx into param > > build." > > << endl; > > break; > > } > > > > OSSL_PARAM *params = &
RE: Updating RSA public key generation and signature verification from 1.1.1 to 3.0
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(); uint32_t sig_len; unsigned char* der_sig = NULL;; // 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); // FreesBIGNUMs manually here BN_free(r_big_num); ECDSA_SIG_free(tmp_ecdsa_sig); break; } int der_sig_len = i2d_ECDSA_SIG(tmp_ecdsa_sig, _sig); // der_sig = static_cast(OPENSSL_malloc(der_sig_len)); // unsigned char* der_iter = der_sig; // der_sig_len = i2d_ECDSA_SIG(tmp_ecdsa_sig, _iter); // <= bugfix here if (der_sig_len == 0) { cout << "sig length invalid" << endl; break; } if (der_sig == NULL) { cout << "sig generation failed" << endl; break; } // loop through the array elements for (size_t i = 0; i < der_sig_len; i++) { cout << der_sig[i] << ' '; } verify_md_ctx = EVP_MD_CTX_new(); if (!verify_md_ctx) { cout << "Error md verify context " << endl;; break; } if (EVP_DigestVerifyInit(verify_md_ctx, NULL, (parent_cert->pub_key_algo == SEV_SIG_ALGO_ECDSA_SHA256 || parent_cert->pub_key_algo == SEV_SIG_ALGO_ECDH_SHA256) ? EVP_sha256(): EVP_sha384(), NULL, parent_signing_key) <= 0) { cout << "Init fails " << endl; break; } if (EVP_DigestVerifyUpdate(verify_md_ctx, (uint8_t *)child_cert, pub_key_offset) <= 0){// Calls SHA256_UPDATE cout << "updating digest fails" << endl; break; } int ret = EVP_DigestVerifyFinal(verify_md_ctx, der_sig, der_sig_len); if (ret == 0) { cout << "EC Verify digest fails" << endl; break; } else if (ret < 0) { printf("Failed Final Verify %s\n",ERR_error_string(ERR_get_error(),NULL)); cout << "EC Verify error" << endl; break; } found_match = true; cout << "SEV EC verification Succesful" << endl; if (verify_md_ctx) EVP_MD_CTX_free(verify_md_ctx); break; } The only difference still is using the der signature; besides that, it is the same. Could it be a bug? Thank you, Diego Gonzalez -- -Original Message- From: Tomas Mraz Sent: Thursday, September 29, 2022 1:12 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, comments below. On Wed, 2022-09-28 at 22:12 +, GonzalezVillalobos, Diego wrote: > [AMD Official Use Only - General] > > Hello Tomas, > > I generated the key as you suggested, and I am no longer getting an > error message! Thank you for that. Here is how I'm generating the key > now: > > // SEV certificate are little-endian, must reverse bytes before > generating key > if ((cert->pub_key_algo == SEV_SIG_ALGO_ECDSA_SHA256) || > (cert->pu
Re: Updating RSA public key generation and signature verification from 1.1.1 to 3.0
Hi, comments below. On Wed, 2022-09-28 at 22:12 +, GonzalezVillalobos, Diego wrote: > [AMD Official Use Only - General] > > Hello Tomas, > > I generated the key as you suggested, and I am no longer getting an > error message! Thank you for that. Here is how I'm generating the key > now: > > // SEV certificate are little-endian, must reverse bytes before > generating key > if ((cert->pub_key_algo == SEV_SIG_ALGO_ECDSA_SHA256) || > (cert->pub_key_algo == SEV_SIG_ALGO_ECDSA_SHA384)) { > //Grab x param and flip bytes to BE > memcpy(px, >pub_key.ecdsa.qx, ec_group_order); > if(!sev::reverse_bytes(px, sizeof(px))) > break; > //Grab y param and flip bytes to BE > memcpy(py, >pub_key.ecdsa.qy, ec_group_order); > if(!sev::reverse_bytes(py, sizeof(py))) > break; > } > else if ((cert->pub_key_algo == > SEV_SIG_ALGO_ECDH_SHA256) || > (cert->pub_key_algo == SEV_SIG_ALGO_ECDH_SHA384)) > { > //Grab x param and flip bytes to BE > memcpy(px, >pub_key.ecdh.qx, ec_group_order); > if(!sev::reverse_bytes(px, sizeof(px))) > break; > //Grab y param and flip bytes to BE > memcpy(py, >pub_key.ecdh.qy, ec_group_order); > if(!sev::reverse_bytes(py, sizeof(py))) > break; > } > > int px_size = sizeof(px)/sizeof(*px); > int py_size = sizeof(py)/sizeof(*py); > > // Will contain x and y components > unsigned char public_key_xy[1 + px_size + py_size] = {0}; > > //Add point conversion as first value > public_key_xy[0] = POINT_CONVERSION_UNCOMPRESSED; > > //Add x components after point compression > memcpy(public_key_xy + 1, px, px_size); > //Add y components after x > memcpy(public_key_xy + px_size + 1, py ,py_size); > > // int nid = EC_curve_nist2nid("P-384"); // > NID_secp384r1 > > OSSL_PARAM_BLD *params_build = OSSL_PARAM_BLD_new(); > > if ( params_build == NULL ) { > cout << "Params build fails" << endl; > break; > } > > if (!OSSL_PARAM_BLD_push_utf8_string(params_build, > OSSL_PKEY_PARAM_GROUP_NAME, "P-384", 0)) { > cout<< "Push EC curve to build fails" << endl; > break; > } > > if (!OSSL_PARAM_BLD_push_octet_string(params_build, > OSSL_PKEY_PARAM_PUB_KEY, public_key_xy, sizeof(public_key_xy))) { > cout << "Error: failed to push qx into param build." > << endl; > break; > } > > OSSL_PARAM *params = > OSSL_PARAM_BLD_to_param(params_build); > > if ( params == NULL ) { > cout << "Error: building parameters." << endl; > break; > } > > OSSL_PARAM_BLD_free(params_build); > > key_gen_ctx = EVP_PKEY_CTX_new_id(EVP_PKEY_EC, NULL); > > if(EVP_PKEY_fromdata_init(key_gen_ctx) != 1) { > cout << "failed to initialize key creation." << endl; > break; > } > > if(EVP_PKEY_fromdata(key_gen_ctx, _pub_key, > EVP_PKEY_PUBLIC_KEY, params) != 1) { > cout << "key generation breaks" << endl; > printf("Failed Final Verify > %s\n",ERR_error_string(ERR_get_error(),NULL)); > break; > } > > if (EVP_PKEY_get_base_id(evp_pub_key) != EVP_PKEY_EC) { > cout << "wrong key type" << endl; > break; > } > } > > if (!evp_pub_key) { > cout << "no evp pkey" << endl; > break; > } > cout << "compile key succesful" << endl; > cmd_ret = STATUS_SUCCESS; > > Although the key generation works and I'm not getting a verify error > anymore, I am still unsuccessful on verifying the digest. It keeps > failing (returning 0). Here is how I'm currently trying to do the > verification. Are you sure the px_size and py_size is equal to the group order? The x and y values must be padded to the group order with 0 (at the start because the values need to be BE). > ECDSA_SIG *tmp_ecdsa_sig = ECDSA_SIG_new(); > BIGNUM *r_big_num = BN_new(); > BIGNUM *s_big_num = BN_new(); > uint32_t sig_len; > unsigned char* der_sig; > > // 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, >
RE: Updating RSA public key generation and signature verification from 1.1.1 to 3.0
// 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); // FreesBIGNUMs manually here BN_free(r_big_num); ECDSA_SIG_free(tmp_ecdsa_sig); break; } int der_sig_len = i2d_ECDSA_SIG(tmp_ecdsa_sig, NULL); der_sig = static_cast(OPENSSL_malloc(der_sig_len)); unsigned char* der_iter = der_sig; der_sig_len = i2d_ECDSA_SIG(tmp_ecdsa_sig, _iter); // <= bugfix here if (der_sig_len == 0) { cout << "sig length invalid" << endl; break; } if (der_sig == NULL) { cout << "sig generation failed" << endl; break; } verify_md_ctx = EVP_MD_CTX_new(); if (!verify_md_ctx) { cout << "Error md verify context " << endl;; break; } if (EVP_DigestVerifyInit(verify_md_ctx, NULL, (parent_cert->pub_key_algo == SEV_SIG_ALGO_ECDSA_SHA256 || parent_cert->pub_key_algo == SEV_SIG_ALGO_ECDH_SHA256) ? EVP_sha256(): EVP_sha384(), NULL, parent_signing_key) <= 0) { cout << "Init fails " << endl; break; } if (EVP_DigestVerifyUpdate(verify_md_ctx, (uint8_t *)child_cert, pub_key_offset) <= 0){// Calls SHA256_UPDATE cout << "updating digest fails" << endl; break; } int ret = EVP_DigestVerifyFinal(verify_md_ctx, der_sig, der_sig_len); cout << ret << endl; if (ret == 0) { cout << "EC Verify digest fails" << endl; break; } else if (ret < 0) { printf("Failed Final Verify %s\n",ERR_error_string(ERR_get_error(),NULL)); cout << "EC Verify error" << endl; break; } found_match = true; cout << "SEV EC verification Succesful" << endl; Could it be because I'm creating a ECDSA SIG object and then turning it into a der format to verify? Again, suggestions would be appreciated. Thank you! Diego Gonzalez Villalobos -- -Original Message- From: Tomas Mraz Sent: Friday, September 23, 2022 1:17 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. Please look at the answer in this question in GitHub: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenssl%2Fopenssl%2Fissues%2F19219%23issuecomment-1247782572data=05%7C01%7CDiego.GonzalezVillalobos%40amd.com%7C49cb5498fa2142b3c73f08da9d2b3799%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637995106207913021%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=S%2FIfBL5bnOa%2Fa2owmcihtZlG4AxTYCWDkaGpmJdid%2Fw%3Dreserved=0 Matt Caswell's answer to very similar question is presented there. I'm copying the answer here for convenience: You are attempting to create an EC public key using the "x" and "y" parameters - but no such parameters exist. The list of available EC parameters is on this page: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.openssl.org%2Fdocs%2Fman3.0%2Fman7%2FEVP_PKEY-EC.htmldata=05%7C01%7CDiego.GonzalezVillalobos%40amd.com%7C49cb5498fa2142b3c73f08da9d2b3799%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637995106207913021%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=dRWekElnVV5leTg6ZN0k9LwQq1Sivf2Hx%2BZrY7YPajE%3Dreserved=0 For your purposes you need to use the OSSL_PKEY_PARAM_PUB_KEY parameter ("pub") to supply the public key. It needs to be an octet string with the value POINT_CONVERSION_UNCOMPRESSED at the start followed by the x and y co-ords concatenated together. For that curve, x and y need to be zero padded to be 32 bytes long each. There is an example of doing this on the EVP_PKEY_fromdata man page. Actually the example is is for EVP_PK
Re: Updating RSA public key generation and signature verification from 1.1.1 to 3.0
new(); > uint32_t sig_len; > unsigned char *p; > > // 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); > break; > } > > sig_len = i2d_ECDSA_SIG(tmp_ecdsa_sig, NULL); > unsigned char signature[sig_len]; > > p = signature; > > sig_len = i2d_ECDSA_SIG(tmp_ecdsa_sig, ); > > > if (signature == NULL) { > cout << "sig mem failed" << endl; > break; > } > > if (sig_len == 0) > cout << "sig length invalid" << endl; > > verify_md_ctx = EVP_MD_CTX_new(); > > > if (!verify_md_ctx) { > cout << "Error md verify context " << endl;; > break; > } > > if (EVP_DigestVerifyInit(verify_md_ctx, NULL, > (parent_cert->pub_key_algo == SEV_SIG_ALGO_ECDSA_SHA256 || > parent_cert->pub_key_algo == SEV_SIG_ALGO_ECDH_SHA256) ? EVP_sha256() > : EVP_sha384(), NULL, parent_signing_key) <= 0) { > cout << "Init fails " << endl; > break; > } > > if (EVP_DigestVerifyUpdate(verify_md_ctx, child_cert, > pub_key_offset) <= 0){ // Calls SHA256_UPDATE > cout << "updating digest fails" << endl; > break; > } > > int ret = EVP_DigestVerifyFinal(verify_md_ctx, > signature, sig_len); > cout << ret << endl; > if (ret == 0) { > cout << "EC Verify digest fails" << endl; > break; > } else if (ret < 0) { > printf("Failed Final Verify > %s\n",ERR_error_string(ERR_get_error(),NULL)); > cout << "EC Verify error" << endl; > break; > } > > found_match = true; > cout << "SEV EC verification Succesful" << endl; > > > My current output when I reach EVP_DigestVerifyFinal is showing this > error: > Failed Final Verify error:0395:digital envelope routines::no > operation set > > I have been playing around with it for a while, but I am stuck at > this point. Any advice would be appreciated. > > Thank you, > > Diego Gonzalez Villalobos > - > - > > > -Original Message- > From: Tomas Mraz > Sent: Friday, September 9, 2022 10:36 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: External Email] > > On Thu, 2022-09-08 at 16:10 +, GonzalezVillalobos, Diego via > openssl-users wrote: > > [AMD Official Use Only - General] > > > > Hello everyone, > > > > I am currently working on updating a signature verification > > function > > in C++ and I am a bit stuck. I am trying to replace the deprecated > > 1.1.1 functions to the appropriate 3.0 versions. The function takes > > in > > 2 certificate objects (parent and cert), which are not x509 > > certificates, but certificates the company had previously defined. > > Using the contents from parent we create an RSA public key and > > using > > the contents from cert we create the digest and grab the signature > > to > > verify. > > > > In the 1.1.1 version we were using the RSA Object and the > > rsa_set0_key > > function to create the RSA public key and then used > > RSA_public_decrypt > > to decrypt the signature and RSA_verify_PKCS1_PSS to verify it. > > This > > whole workflow is now deprecated. > > > ... > > Is this the correct way of creating RSA keys now? Where is my logic > > failing? Can the same type of procedure even be done on 3.0? Any > > advice would be really appreciated. > > > > In the original code you seem to be using PSS padding for > verification. > Did you try to set the PSS padding on the digest verify context? See > demos/signature/rsa_pss_hash.c on how to do it. > > -- > Tomáš Mráz, OpenSSL -- Tomáš Mráz, OpenSSL
RE: Updating RSA public key generation and signature verification from 1.1.1 to 3.0
lt;< "EC Verify digest fails" << endl; break; } else if (ret < 0) { printf("Failed Final Verify %s\n",ERR_error_string(ERR_get_error(),NULL)); cout << "EC Verify error" << endl; break; } found_match = true; cout << "SEV EC verification Succesful" << endl; My current output when I reach EVP_DigestVerifyFinal is showing this error: Failed Final Verify error:0395:digital envelope routines::no operation set I have been playing around with it for a while, but I am stuck at this point. Any advice would be appreciated. Thank you, Diego Gonzalez Villalobos ------ -Original Message- From: Tomas Mraz Sent: Friday, September 9, 2022 10:36 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: External Email] On Thu, 2022-09-08 at 16:10 +, GonzalezVillalobos, Diego via openssl-users wrote: > [AMD Official Use Only - General] > > Hello everyone, > > I am currently working on updating a signature verification function > in C++ and I am a bit stuck. I am trying to replace the deprecated > 1.1.1 functions to the appropriate 3.0 versions. The function takes in > 2 certificate objects (parent and cert), which are not x509 > certificates, but certificates the company had previously defined. > Using the contents from parent we create an RSA public key and using > the contents from cert we create the digest and grab the signature to > verify. > > In the 1.1.1 version we were using the RSA Object and the rsa_set0_key > function to create the RSA public key and then used RSA_public_decrypt > to decrypt the signature and RSA_verify_PKCS1_PSS to verify it. This > whole workflow is now deprecated. > ... > Is this the correct way of creating RSA keys now? Where is my logic > failing? Can the same type of procedure even be done on 3.0? Any > advice would be really appreciated. > In the original code you seem to be using PSS padding for verification. Did you try to set the PSS padding on the digest verify context? See demos/signature/rsa_pss_hash.c on how to do it. -- Tomáš Mráz, OpenSSL
Re: Updating RSA public key generation and signature verification from 1.1.1 to 3.0
On Thu, 2022-09-08 at 16:10 +, GonzalezVillalobos, Diego via openssl-users wrote: > [AMD Official Use Only - General] > > Hello everyone, > > I am currently working on updating a signature verification function > in C++ and I am a bit stuck. I am trying to replace the deprecated > 1.1.1 functions to the appropriate 3.0 versions. The function takes > in 2 certificate objects (parent and cert), which are not x509 > certificates, but certificates the company had previously defined. > Using the contents from parent we create an RSA public key and using > the contents from cert we create the digest and grab the signature to > verify. > > In the 1.1.1 version we were using the RSA Object and the > rsa_set0_key function to create the RSA public key and then used > RSA_public_decrypt to decrypt the signature and RSA_verify_PKCS1_PSS > to verify it. This whole workflow is now deprecated. > ... > Is this the correct way of creating RSA keys now? Where is my logic > failing? Can the same type of procedure even be done on 3.0? Any > advice would be really appreciated. > In the original code you seem to be using PSS padding for verification. Did you try to set the PSS padding on the digest verify context? See demos/signature/rsa_pss_hash.c on how to do it. -- Tomáš Mráz, OpenSSL
Updating RSA public key generation and signature verification from 1.1.1 to 3.0
[AMD Official Use Only - General] Hello everyone, I am currently working on updating a signature verification function in C++ and I am a bit stuck. I am trying to replace the deprecated 1.1.1 functions to the appropriate 3.0 versions. The function takes in 2 certificate objects (parent and cert), which are not x509 certificates, but certificates the company had previously defined. Using the contents from parent we create an RSA public key and using the contents from cert we create the digest and grab the signature to verify. In the 1.1.1 version we were using the RSA Object and the rsa_set0_key function to create the RSA public key and then used RSA_public_decrypt to decrypt the signature and RSA_verify_PKCS1_PSS to verify it. This whole workflow is now deprecated. //OPENSSL 1.1.1 Code SEV_ERROR_CODE AMDCert::amd_cert_validate_sig(const amd_cert *cert, const amd_cert *parent, ePSP_DEVICE_TYPE device_type) { SEV_ERROR_CODE cmd_ret = ERROR_INVALID_CERTIFICATE; hmac_sha_256 sha_digest_256; hmac_sha_512 sha_digest_384; SHA_TYPE algo = SHA_TYPE_256; uint8_t *sha_digest = NULL; size_t sha_length = 0; RSA *rsa_pub_key = NULL; BIGNUM *modulus = NULL; BIGNUM *pub_exp = NULL; EVP_MD_CTX* md_ctx = NULL; uint32_t sig_len = cert->modulus_size/8; uint32_t digest_len = 0; uint8_t decrypted[AMD_CERT_KEY_BYTES_4K] = {0}; // TODO wrong length uint8_t signature[AMD_CERT_KEY_BYTES_4K] = {0}; uint32_t fixed_offset = offsetof(amd_cert, pub_exp);// 64 bytes do { if (!cert || !parent) { cmd_ret = ERROR_INVALID_PARAM; break; } // Set SHA_TYPE to 256 bit or 384 bit depending on device_type if (device_type == PSP_DEVICE_TYPE_NAPLES) { algo = SHA_TYPE_256; sha_digest = sha_digest_256; sha_length = sizeof(hmac_sha_256); } else /*if (ROME/MILAN)*/ { algo = SHA_TYPE_384; sha_digest = sha_digest_384; sha_length = sizeof(hmac_sha_512); } // Memzero all the buffers memset(sha_digest, 0, sha_length); memset(decrypted, 0, sizeof(decrypted)); memset(signature, 0, sizeof(signature)); // New up the RSA key rsa_pub_key = RSA_new(); // Convert the parent to an RSA key to pass into RSA_verify modulus = BN_lebin2bn((uint8_t *)>modulus, parent->modulus_size/8, NULL); // n// New's up BigNum pub_exp = BN_lebin2bn((uint8_t *)>pub_exp, parent->pub_exp_size/8, NULL); // e if (RSA_set0_key(rsa_pub_key, modulus, pub_exp, NULL) != 1) break; // Create digest from certificate md_ctx = EVP_MD_CTX_create(); if (EVP_DigestInit(md_ctx, (algo == SHA_TYPE_256) ? EVP_sha256() : EVP_sha384()) <= 0) break; if (EVP_DigestUpdate(md_ctx, cert, fixed_offset) <= 0) // Calls SHA256_UPDATE break; if (EVP_DigestUpdate(md_ctx, >pub_exp, cert->pub_exp_size/8) <= 0) break; if (EVP_DigestUpdate(md_ctx, >modulus, cert->modulus_size/8) <= 0) break; EVP_DigestFinal(md_ctx, sha_digest, _len); // Swap the bytes of the signature memcpy(signature, >sig, parent->modulus_size/8); if (!sev::reverse_bytes(signature, parent->modulus_size/8)) break; // Now we will verify the signature. Start by a RAW decrypt of the signature if (RSA_public_decrypt(sig_len, signature, decrypted, rsa_pub_key, RSA_NO_PADDING) == -1) break; // Verify the data // SLen of -2 means salt length is recovered from the signature if (RSA_verify_PKCS1_PSS(rsa_pub_key, sha_digest, (algo == SHA_TYPE_256) ? EVP_sha256() : EVP_sha384(), decrypted, -2) != 1) { break; } cmd_ret = STATUS_SUCCESS; } while (0); // Free the keys and contexts if (rsa_pub_key) RSA_free(rsa_pub_key); if (md_ctx) EVP_MD_CTX_free(md_ctx); return cmd_ret; } My current attempt to do this update is first creating an EVP_PKEY object which will now store the public key and inputting the same data from parent by using the EVP_PKEY_fromdata generation function. I build my OSSL_PARAMETERS using OSSL_PARAM_BLD to which I push the data from parent. Lastly for the verification I am using the EVP_DigestVerifyFinal procedure. I create the digest using EVP_DigestVerifyInit and EVP_DigestVerifyUpdate and passing in the same data from cert that we were using in the 1.1.1 version of the function. I have tried different approaches to both creating the key and the verification procedure, but I cannot seem to get it to w
Re: RSA digital signature verification failure with openssl 1.1.0j
I found that if the signing and verification are all done by command line or all done by API, the verification will pass. But if cross, then failed. Any default configuration are different? -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html
RSA digital signature verification failure with openssl 1.1.0j
I am working on the upgrade my program written 4 years before with updated openssl version 1.1.0j from 1.0.1e. There are so many changes between the two versions. I updated my code with 1.1.0 API, but it failed and I cannot figure out the reason. The RSA key pair and message signature are generated with openssl command line as follows, key generation and cert generation $openssl req -new -keyout private/userkey.pem -out usercert-req.pem -config ./openssl.cnf $openssl ca -in usercert-req.pem -out newcerts/usercert.pem -days 180 -config ./openssl.cnf Sign. openssl dgst -sha256 -sign userkey.pem -out signature.binary msg openssl dgst -hex -sha256 -sign userkey.pem -out signature.hex msg //get public key from cert openssl x509 -pubkey -noout -in usercert.pem > pubkey.pem Verify openssl dgst -sha256 -verify pubkey.pem -signature signature.binary msg The result is verification OK But I have to use the API to verify the signature in hex format, and the result is verification failure. Can anyone help me to figure out the problem. The code first loads the certification and retrieve the public key from certificate into EVP_PKEY, and then translate the hex digest (messasge) to binary format, and use EVP_DigestVerifyInitial/EVP_DigestVerifyUpdate/EVP_DigestVerifyFinal to verify the signature. It works in openssl 1.01e, and I tried to update the related functions in the 1.1.0version, it still fails. Am I missing something in the new version? This is the C code I am using: #include #include #include #include #include #include #include #include #include #include #include #include #include #include int hex_to_bin(char ch) { if ((ch >= '0') && (ch <= '9')) return ch - '0'; if ((ch >= 'a') && (ch <= 'f')) return ch - 'a' + 0x0A; if ((ch >= 'A') && (ch <= 'F')) return ch - 'A' + 0x0A; return -1; } int hex2bin(unsigned char *dst, const char *src, unsigned count) { while (count--) { int hi = hex_to_bin(*src++); int lo = hex_to_bin(*src++); if ((hi < 0) || (lo < 0)) return -1; *dst++ = (hi << 4) | lo; } return 0; } int main() { FILE *fp; X509 *x509 = NULL; EVP_PKEY *pkey = NULL; unsigned char *sigbuf = NULL; unsigned char md[32]; unsigned char *digest = NULL; unsigned int i, siglen = 0; siglen = 128; char line[siglen * 2 + 3]; char *buf; int num = 0; //number of license const char cert_filestr[] = "./cert.pem"; const char license_filename_str[] = "./signature"; const char digest_filename_str[] = "./digest"; // //load certificate and get pub key //*** //OpenSSL_add_all_algorithms(); //ERR_load_crypto_strings(); fp = fopen(cert_filestr, "r"); if (!fp) { printf("Error opening certificate file \n"); return -1; } x509 = PEM_read_X509(fp, NULL, NULL, NULL); fclose(fp); pkey = X509_get_pubkey(x509); if(!pkey){ printf("Fail to create pkey!"); return -1; } //* // //load license.info (digest) // // fp =fopen(digest_filename_str, "r"); if(!fp) { printf("Error opening digest file\n"); return -1; } digest = (unsigned char*)malloc(64+10); digest = fgets(line, sizeof(line), fp); fclose(fp); //* // //load license.key (signature) // // // fp = fopen(license_filename_str, "r"); if (!fp) { printf("Error opening license file \n"); return -1; } //** //change the sigature format from Hex to Binary // fp = fopen(license_filename_str, "r"); unsigned int len = siglen ; sigbuf = (unsigned char*)malloc(len); if((buf = fgets(line, sizeof(line), fp)) != NULL) { printf("*Retrieved line of length %d :\n", (int)strlen(buf)); printf("*signature**\n%s", buf); hex2bin(sigbuf , buf, siglen); } fclose(fp); //** // //verify signature // //
Re: [openssl-users] Fwd: Openssl api for signature verification using digest
All on my phone Pada 29 Aug 2018, at 17:53, Linta Maria menulis: > Hi Viktor, > > As you suggested, signature wasn't correct. > With below input also it's not working. > > Pubkey is read to evp_PKEY format > > EVP_PKEY * vkey; > char PubKey [] ="-BEGIN PUBLIC KEY-""\n" > > "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxEZo8DRHBFBN0w1YYw3w" "\n" > > > "C/C/IxCH3WSDCBTZgPux+/Cm+Q+LtSHjxV2x+hHuR8+cWMgFIrpvN0jw1F6g0f3A" "\n" > > > "QQvQmPkyIUZGN1C9Da+SEdpc12gZdAOdILUaeiDRNUYXJinbBPQaNGAQIWwuzCuj" "\n" > > > "5sjZPrlJYDQ52kq2U86ZNcS/NVRZi+pFB4u0YHHiqJkQYT6yCQjR9Rdvxvjyg9L5" "\n" > > > "9petX/xa0tBurw5eTLOC9UlufblJnS7zrVkpoHdtt9rRgDBJ4kTJypeHq0Tybgro" "\n" > > > "hhxG1EqdAjoD0OjLV93JWr0DOmwWVE1SoJH/UBbgRXf40hxhdzswgJFWJLIdxfdj" "\n" > > "BwIDAQAB" "\n" > > "-END PUBLIC KEY-"; > > BIO *bio; > > bio = BIO_new_mem_buf(PubKey, strlen(PubKey) ); > > PEM_read_bio_PUBKEY( bio, , NULL, NULL ); > > > > unsigned char signew[]={0x14, 0x7e, 0x86, 0x9f, 0xfb, 0x10, 0xc8, 0xa4, > 0x98, 0xae, 0xcb, 0xf8, 0xd4, 0xd7, 0xad, 0xf2, 0x18, 0x40, 0xaf, 0x06, 0x85, > 0x8a, 0x69, 0xde, 0x29, 0x50, 0xf2, 0x52, 0x1c, 0x01, 0xbc, 0x3c, 0x45, 0x42, > 0xb1, 0x32, 0xd8, 0x19, 0xf6, 0xf3, 0x11, 0x39, 0x03, 0xbf, 0x23, 0xfb, 0x5d, > 0x97, 0x41, 0xb9, 0x85, 0xaf, 0x31, 0xf8, 0x32, 0x2f, 0xd2, 0xb6, 0x5b, 0xf1, > 0x22, 0xfd, 0xda, 0x28, 0x58, 0x6f, 0x45, 0x4b, 0x5c, 0x74, 0xf0, 0x84, 0xf2, > 0x1e, 0xfa, 0x33, 0xa3, 0x83, 0x38, 0x9f, 0xcf, 0x71, 0x37, 0x77, 0x6d, 0x86, > 0x84, 0xc6, 0x5e, 0x3b, 0x71, 0xf5, 0x29, 0x2a, 0x43, 0xf4, 0x43, 0x38, 0x0a, > 0x18, 0xf5, 0xbe, 0x6f, 0x03, 0xd3, 0x16, 0x79, 0x13, 0x89, 0x95, 0xb2, > 0xd7, 0x27, 0xcf, 0xd4, 0x2b, 0x6b, 0xa1, 0xbd, 0xe3, 0x8e, 0xac, 0x24, 0x1b, > 0xdd, 0x17, 0xf8, 0xe1, 0xf5, 0xb9, 0x5a, 0xd4, 0x97, 0xf4, 0xc3, 0xfc, 0x69, > 0xc8, 0x40, 0x30, 0x76, 0x7d, 0x18, 0x7c, 0x58, 0x11, 0x3d, 0x78, 0x27, 0x41, > 0xab, 0x1c, 0xd2, 0xd3, 0x5f, 0xe2, 0x94, 0xe1, 0x49, 0xba, 0x6b, 0xd7, 0xbe, > 0x3a, 0x9d, 0x86, 0x62, 0xdc, 0xd7, 0x46, 0xae, 0xa3, 0x8e, 0xe1, 0x46, 0x27, > 0xbc, 0xb2, 0x31, 0x69, 0xc5, 0x54, 0x15, 0x85,0x74, 0x1a, 0x66, 0x94, 0xa6, > 0x68, 0x5e, 0xa2,0x1c, 0x38, 0x3d, 0x84, 0xd8, 0x3f, 0x84, 0x81,0x56, 0xc2, > 0x9c, 0xac, 0xef, 0x68, 0xef, 0x68,0x96, 0xb3, 0xd1, 0xa9, 0x3a, 0x43, 0x75, > 0xef,0xaf, 0xf2, 0x1b, 0xea, 0x96, 0xb8, 0x23, 0xef,0xa6, 0x09, 0x89, 0x15, > 0x52, 0x26, 0xce, 0x1f,0x98, 0x02, 0x83, 0x22, 0x08, 0x60, 0x6c, 0xd9,0x14, > 0x64, 0xe8, 0xef, 0x53, 0xea, 0x48, 0x60,0xbb, 0x69, 0x49, 0x64, 0xa3, 0x0d, > 0xdb, 0xaa}; > > > > > > unsigned char > hashnew[]={0x8f,0x43,0x43,0x46,0x64,0x8f,0x6b,0x96,0xdf,0x89,0xdd,0xa9,0x1c,0x51,0x76,0xb1,0x0a,0x6d,0x83,0x96,0x1d,0xd3,0xc1,0xac,0x88,0xb5,0x9b,0x2d,0xc3,0x27,0xaa,0x4}; > > > > > > > > > > -- Forwarded message - > From: Viktor Dukhovni > Date: Wed 29 Aug, 2018, 11:30 AM > Subject: Re: [openssl-users] Openssl api for signature verification using > digest > To: openssl-users@openssl.org > > > > > > On Aug 29, 2018, at 1:05 AM, Linta Maria wrote: > > > > Still its not working. > > The code is working correctly. The real problem is that the PEM > format 2048-bit RSA key you posted: > > > BEGIN PUBLIC KEY- > > MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzMjyWZfVfBpmNKmIm9HH > > FnrhDLZaCmQvZz57uJHhBLwLk/UAJ+kLKV9Lox8eKfimzisPFBad/TUfwPUaQmji > > bPKCp+or2EHvPFooOnPWjSd57zPCohDdo0nOLw7iTUOMCvoqvJcdor+t1zBb8MQK > > yNTycuoGlT19lr8msJFtR+ulfKucj/zk5w/jr0SsxysqFsvtEfa62Wu/wSDYIfsq > > lKlRGLTlqJNtQybtTVv2Uu2KFrbe0C8+FBkxgtBS+0MkhzpJ37/02J+mHFx1bsgN > > 09QnQY+T05te+6/mmlsHP3PYRqXqJOLl9AkLd/9kiMhSFshowFehKmls9PYt1xGf > > 5QIDAQAB > > -END PUBLIC KEY- > > is NOT the key that was used to generate the below signature, or > the signature was subsequently altered. > > > Signature={ > > 0x24,0xb8,0xec,0xb4,0x4f,0x31,0xa6,0x8,0x72,0x61,0xc9,0xd3,0x1c,0xd0,0x9b,0xee,0x26,0x2d,0x3d,0xef,0xff,0x2c,0x5,0x78,0x4,0xd3,0xa3,0xff,0xdc,0x97,0x53,0xe6,0x6e,0x85,0x41,0x1b,0xb2,0x2c,0xed,0xbd,0xa6,0x5d,0x6f,0xac,0xbb,0xd5,0xb8,0xa0,0x9,0x2b,0xf1,0xf5,0xb6,0xce,0xdd,0x70,0x8a,0x1a,0xa1,0x20,0x11,0x2b,0xf0,0x17,0x41,0x83,0x80,0xf6,0x61,0xd4,0x6d,0x53,0x8f,0xf1,0x8c,0x19,0x42,0x93,0x96,0xa9,0xb6,0xf2,0x8f,0x27,0x9c,0x66,0x17,0xc5,0xca,0x3d,0xa9,0x3f,0xc5,0x76,0x
Re: [openssl-users] Fwd: Openssl api for signature verification using digest
> On Aug 29, 2018, at 5:53 AM, Linta Maria wrote: > > As you suggested, signature wasn't correct. > With below input also it's not working. Once again, the code is working correct, the key below did not produce the posted signature. Please use "openssl rsautl" as shown in my previous message to check that the signature matches the code, before using these to test your code. There's no use asking for help with making work something that should not and must not work. > > Pubkey is read to evp_PKEY format > > EVP_PKEY * vkey; > char PubKey [] ="-BEGIN PUBLIC KEY-""\n" > > "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxEZo8DRHBFBN0w1YYw3w" "\n" > > > "C/C/IxCH3WSDCBTZgPux+/Cm+Q+LtSHjxV2x+hHuR8+cWMgFIrpvN0jw1F6g0f3A" "\n" > > > "QQvQmPkyIUZGN1C9Da+SEdpc12gZdAOdILUaeiDRNUYXJinbBPQaNGAQIWwuzCuj" "\n" > > > "5sjZPrlJYDQ52kq2U86ZNcS/NVRZi+pFB4u0YHHiqJkQYT6yCQjR9Rdvxvjyg9L5" "\n" > > > "9petX/xa0tBurw5eTLOC9UlufblJnS7zrVkpoHdtt9rRgDBJ4kTJypeHq0Tybgro" "\n" > > > "hhxG1EqdAjoD0OjLV93JWr0DOmwWVE1SoJH/UBbgRXf40hxhdzswgJFWJLIdxfdj" "\n" > > "BwIDAQAB" "\n" > > "-END PUBLIC KEY-"; > > BIO *bio; > > bio = BIO_new_mem_buf(PubKey, strlen(PubKey) ); > > PEM_read_bio_PUBKEY( bio, , NULL, NULL ); > > > > unsigned char signew[]={0x14, 0x7e, 0x86, 0x9f, 0xfb, 0x10, 0xc8, 0xa4, > 0x98, 0xae, 0xcb, 0xf8, 0xd4, 0xd7, 0xad, 0xf2, 0x18, 0x40, 0xaf, 0x06, 0x85, > 0x8a, 0x69, 0xde, 0x29, 0x50, 0xf2, 0x52, 0x1c, 0x01, 0xbc, 0x3c, 0x45, 0x42, > 0xb1, 0x32, 0xd8, 0x19, 0xf6, 0xf3, 0x11, 0x39, 0x03, 0xbf, 0x23, 0xfb, 0x5d, > 0x97, 0x41, 0xb9, 0x85, 0xaf, 0x31, 0xf8, 0x32, 0x2f, 0xd2, 0xb6, 0x5b, 0xf1, > 0x22, 0xfd, 0xda, 0x28, 0x58, 0x6f, 0x45, 0x4b, 0x5c, 0x74, 0xf0, 0x84, 0xf2, > 0x1e, 0xfa, 0x33, 0xa3, 0x83, 0x38, 0x9f, 0xcf, 0x71, 0x37, 0x77, 0x6d, 0x86, > 0x84, 0xc6, 0x5e, 0x3b, 0x71, 0xf5, 0x29, 0x2a, 0x43, 0xf4, 0x43, 0x38, 0x0a, > 0x18, 0xf5, 0xbe, 0x6f, 0x03, 0xd3, 0x16, 0x79, 0x13, 0x89, 0x95, 0xb2, 0xd7, > 0x27, 0xcf, 0xd4, 0x2b, 0x6b, 0xa1, 0xbd, 0xe3, 0x8e, 0xac, 0x24, 0x1b, 0xdd, > 0x17, 0xf8, 0xe1, 0xf5, 0xb9, 0x5a, 0xd4, 0x97, 0xf4, 0xc3, 0xfc, 0x69, 0xc8, > 0x40, 0x30, 0x76, 0x7d, 0x18, 0x7c, 0x58, 0x11, 0x3d, 0x78, 0x27, 0x41, 0xab, > 0x1c, 0xd2, 0xd3, 0x5f, 0xe2, 0x94, 0xe1, 0x49, 0xba, 0x6b, 0xd7, 0xbe, 0x3a, 0x9d, 0x86, 0x62, 0xdc, 0xd7, 0x46, 0xae, 0xa3, 0x8e, 0xe1, 0x46, 0x27, 0xbc, 0xb2, 0x31, 0x69, 0xc5, 0x54, 0x15, 0x85,0x74, 0x1a, 0x66, 0x94, 0xa6, 0x68, 0x5e, 0xa2,0x1c, 0x38, 0x3d, 0x84, 0xd8, 0x3f, 0x84, 0x81,0x56, 0xc2, 0x9c, 0xac, 0xef, 0x68, 0xef, 0x68,0x96, 0xb3, 0xd1, 0xa9, 0x3a, 0x43, 0x75, 0xef,0xaf, 0xf2, 0x1b, 0xea, 0x96, 0xb8, 0x23, 0xef,0xa6, 0x09, 0x89, 0x15, 0x52, 0x26, 0xce, 0x1f,0x98, 0x02, 0x83, 0x22, 0x08, 0x60, 0x6c, 0xd9,0x14, 0x64, 0xe8, 0xef, 0x53, 0xea, 0x48, 0x60,0xbb, 0x69, 0x49, 0x64, 0xa3, 0x0d, 0xdb, 0xaa}; $ perl -pe 'chomp; s/(..)/chr(hex($1))/eg' /tmp/sig.hex | od -vtx1 00014 7e 86 9f fb 10 c8 a4 98 ae cb f8 d4 d7 ad f2 02018 40 af 06 85 8a 69 de 29 50 f2 52 1c 01 bc 3c 04045 42 b1 32 d8 19 f6 f3 11 39 03 bf 23 fb 5d 97 06041 b9 85 af 31 f8 32 2f d2 b6 5b f1 22 fd da 28 10058 6f 45 4b 5c 74 f0 84 f2 1e fa 33 a3 83 38 9f 120cf 71 37 77 6d 86 84 c6 5e 3b 71 f5 29 2a 43 f4 14043 38 0a 18 f5 be 6f 03 d3 16 79 13 89 95 b2 d7 16027 cf d4 2b 6b a1 bd e3 8e ac 24 1b dd 17 f8 e1 200f5 b9 5a d4 97 f4 c3 fc 69 c8 40 30 76 7d 18 7c 22058 11 3d 78 27 41 ab 1c d2 d3 5f e2 94 e1 49 ba 2406b d7 be 3a 9d 86 62 dc d7 46 ae a3 8e e1 46 27 260bc b2 31 69 c5 54 15 85 74 1a 66 94 a6 68 5e a2 3001c 38 3d 84 d8 3f 84 81 56 c2 9c ac ef 68 ef 68 32096 b3 d1 a9 3a 43 75 ef af f2 1b ea 96 b8 23 ef 340a6 09 89 15 52 26 ce 1f 98 02 83 22 08 60 6c d9 36014 64 e8 ef 53 ea 48 60 bb 69 49 64 a3 0d db aa 400 $ perl -pe 'chomp; s/(..)/chr(hex($1))/eg' /tmp/sig.hex | openssl rsautl -inkey /tmp/key.pem -pubin -encrypt -raw | od -vtx1 00019 5c c4 8f 80 35 35 17 c6 17 b9 71 4d 8b 04 a2 020f7 e4 8f 95 dc 1f 5d 15 b8 c2 41 16 78 fd 44 77 04088 c1 b9 46 3d 48 d4 d6 b3 5e d2 bc 4b 8e 0e bc 0607d bb 6d b5 2b 2d aa 40 01 a3 5e 48 31 76 a7 23 1001f 90 d4 0a d3 b1 1a 10 05 a0 c3 49 e7 5e 60 04 12082 02 34 43 d4 90 af 63 0f 90 67 3f 97 2a e7 9c 140c4 4d 2c 1a ca d3 c5 95 9f d7 92 cd 71 32 b1 60 16028 88 25 7a ea 58 dd 22 83 f1 cb 4d a7 39 ab f3 2004f d8 b6 7d e3 a6
[openssl-users] Fwd: Openssl api for signature verification using digest
Hi Viktor, As you suggested, signature wasn't correct. With below input also it's not working. Pubkey is read to evp_PKEY format EVP_PKEY * vkey; char PubKey [] ="-BEGIN PUBLIC KEY-""\n" "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxEZo8DRHBFBN0w1YYw3w" "\n" "C/C/IxCH3WSDCBTZgPux+/Cm+Q+LtSHjxV2x+hHuR8+cWMgFIrpvN0jw1F6g0f3A" "\n" "QQvQmPkyIUZGN1C9Da+SEdpc12gZdAOdILUaeiDRNUYXJinbBPQaNGAQIWwuzCuj" "\n" "5sjZPrlJYDQ52kq2U86ZNcS/NVRZi+pFB4u0YHHiqJkQYT6yCQjR9Rdvxvjyg9L5" "\n" "9petX/xa0tBurw5eTLOC9UlufblJnS7zrVkpoHdtt9rRgDBJ4kTJypeHq0Tybgro" "\n" "hhxG1EqdAjoD0OjLV93JWr0DOmwWVE1SoJH/UBbgRXf40hxhdzswgJFWJLIdxfdj" "\n" "BwIDAQAB" "\n" "-END PUBLIC KEY-"; BIO *bio; bio = BIO_new_mem_buf(PubKey, strlen(PubKey) ); PEM_read_bio_PUBKEY( bio, , NULL, NULL ); unsigned char signew[]={0x14, 0x7e, 0x86, 0x9f, 0xfb, 0x10, 0xc8, 0xa4, 0x98, 0xae, 0xcb, 0xf8, 0xd4, 0xd7, 0xad, 0xf2, 0x18, 0x40, 0xaf, 0x06, 0x85, 0x8a, 0x69, 0xde, 0x29, 0x50, 0xf2, 0x52, 0x1c, 0x01, 0xbc, 0x3c, 0x45, 0x42, 0xb1, 0x32, 0xd8, 0x19, 0xf6, 0xf3, 0x11, 0x39, 0x03, 0xbf, 0x23, 0xfb, 0x5d, 0x97, 0x41, 0xb9, 0x85, 0xaf, 0x31, 0xf8, 0x32, 0x2f, 0xd2, 0xb6, 0x5b, 0xf1, 0x22, 0xfd, 0xda, 0x28, 0x58, 0x6f, 0x45, 0x4b, 0x5c, 0x74, 0xf0, 0x84, 0xf2, 0x1e, 0xfa, 0x33, 0xa3, 0x83, 0x38, 0x9f, 0xcf, 0x71, 0x37, 0x77, 0x6d, 0x86, 0x84, 0xc6, 0x5e, 0x3b, 0x71, 0xf5, 0x29, 0x2a, 0x43, 0xf4, 0x43, 0x38, 0x0a, 0x18, 0xf5, 0xbe, 0x6f, 0x03, 0xd3, 0x16, 0x79, 0x13, 0x89, 0x95, 0xb2, 0xd7, 0x27, 0xcf, 0xd4, 0x2b, 0x6b, 0xa1, 0xbd, 0xe3, 0x8e, 0xac, 0x24, 0x1b, 0xdd, 0x17, 0xf8, 0xe1, 0xf5, 0xb9, 0x5a, 0xd4, 0x97, 0xf4, 0xc3, 0xfc, 0x69, 0xc8, 0x40, 0x30, 0x76, 0x7d, 0x18, 0x7c, 0x58, 0x11, 0x3d, 0x78, 0x27, 0x41, 0xab, 0x1c, 0xd2, 0xd3, 0x5f, 0xe2, 0x94, 0xe1, 0x49, 0xba, 0x6b, 0xd7, 0xbe, 0x3a, 0x9d, 0x86, 0x62, 0xdc, 0xd7, 0x46, 0xae, 0xa3, 0x8e, 0xe1, 0x46, 0x27, 0xbc, 0xb2, 0x31, 0x69, 0xc5, 0x54, 0x15, 0x85,0x74, 0x1a, 0x66, 0x94, 0xa6, 0x68, 0x5e, 0xa2,0x1c, 0x38, 0x3d, 0x84, 0xd8, 0x3f, 0x84, 0x81,0x56, 0xc2, 0x9c, 0xac, 0xef, 0x68, 0xef, 0x68,0x96, 0xb3, 0xd1, 0xa9, 0x3a, 0x43, 0x75, 0xef,0xaf, 0xf2, 0x1b, 0xea, 0x96, 0xb8, 0x23, 0xef,0xa6, 0x09, 0x89, 0x15, 0x52, 0x26, 0xce, 0x1f,0x98, 0x02, 0x83, 0x22, 0x08, 0x60, 0x6c, 0xd9,0x14, 0x64, 0xe8, 0xef, 0x53, 0xea, 0x48, 0x60,0xbb, 0x69, 0x49, 0x64, 0xa3, 0x0d, 0xdb, 0xaa}; unsigned char hashnew[]={0x8f,0x43,0x43,0x46,0x64,0x8f,0x6b,0x96,0xdf,0x89,0xdd,0xa9,0x1c,0x51,0x76,0xb1,0x0a,0x6d,0x83,0x96,0x1d,0xd3,0xc1,0xac,0x88,0xb5,0x9b,0x2d,0xc3,0x27,0xaa,0x4}; -- Forwarded message - From: *Viktor Dukhovni* Date: Wed 29 Aug, 2018, 11:30 AM Subject: Re: [openssl-users] Openssl api for signature verification using digest To: openssl-users@openssl.org > On Aug 29, 2018, at 1:05 AM, Linta Maria wrote: > > Still its not working. The code is working correctly. The real problem is that the PEM format 2048-bit RSA key you posted: > BEGIN PUBLIC KEY- > MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzMjyWZfVfBpmNKmIm9HH > FnrhDLZaCmQvZz57uJHhBLwLk/UAJ+kLKV9Lox8eKfimzisPFBad/TUfwPUaQmji > bPKCp+or2EHvPFooOnPWjSd57zPCohDdo0nOLw7iTUOMCvoqvJcdor+t1zBb8MQK > yNTycuoGlT19lr8msJFtR+ulfKucj/zk5w/jr0SsxysqFsvtEfa62Wu/wSDYIfsq > lKlRGLTlqJNtQybtTVv2Uu2KFrbe0C8+FBkxgtBS+0MkhzpJ37/02J+mHFx1bsgN > 09QnQY+T05te+6/mmlsHP3PYRqXqJOLl9AkLd/9kiMhSFshowFehKmls9PYt1xGf > 5QIDAQAB > -END PUBLIC KEY- is NOT the key that was used to generate the below signature, or the signature was subsequently altered. > Signature={ 0x24,0xb8,0xec,0xb4,0x4f,0x31,0xa6,0x8,0x72,0x61,0xc9,0xd3,0x1c,0xd0,0x9b,0xee,0x26,0x2d,0x3d,0xef,0xff,0x2c,0x5,0x78,0x4,0xd3,0xa3,0xff,0xdc,0x97,0x53,0xe6,0x6e,0x85,0x41,0x1b,0xb2,0x2c,0xed,0xbd,0xa6,0x5d,0x6f,0xac,0xbb,0xd5,0xb8,0xa0,0x9,0x2b,0xf1,0xf5,0xb6,0xce,0xdd,0x70,0x8a,0x1a,0xa1,0x20,0x11,0x2b,0xf0,0x17,0x41,0x83,0x80,0xf6,0x61,0xd4,0x6d,0x53,0x8f,0xf1,0x8c,0x19,0x42,0x93,0x96,0xa9,0xb6,0xf2,0x8f,0x27,0x9c,0x66,0x17,0xc5,0xca,0x3d,0xa9,0x3f,0xc5,0x76,0x5f,0x1b,0x31,0xf2,0xd3,0xe,0x78,0x53,0x97,0xcb,0x9d,0xc4,0xe6,0x41,0x61,0x58,0x44,0x5c,0xf5,0xc4,0x67,0x69,0x8,0xa,0x92,0xd5,0x7e,0x9c,0xb9,0x7e,0x54,0x8b,0x8a,0xb,0xa1,0x9a,0x63,0xbf,0xcc,0xed,0x63,0x2c,0xf8,0x14,0x25,0x6,0xa2,0x2,0x0,0x7,0x2e,0x1c,0xc1,0xeb,0x16,0x89,0xaa,0x69,0xe2,0x75,0x57,0x39,0x71,0x68,0xe,0xf,0xa4,0x7a,0xc5,0x14,0x97,0x88,0x67,0xd1,0x36,0x91,0x3b,0x49,0xe7,0xb4,0xf3,0xcb,0xca,0xf6,0xe9,0xb1,0x22,0xe9,0x85,0x89,0xab,0x2,0x4,0x3c,0x2e,0xbd,0x56,0x3,0x8a,0x8b,0x54,0xc6,0xe6,0xed,0x5b,0x4c,0 xa4,0x9e,0x1b,0xaa,0x90,0xc6,0xb,0x27,0x54,0xc0,0x50,0x5f,0x58,0x97,0xc,0x99,0x5c,0x2,0x74,0xfc,0x9f,0x4c,0x78,0x4e,0xc3,0xb4,0x6d,0x14,0xa1,0xdc,0x62,0xc5,0xfe,0x27,0xb8,0x7d,0x98,0x79,0x82,0x50,0x3a,0xbe,0x6f,
Re: [openssl-users] Openssl api for signature verification using digest
> On Aug 29, 2018, at 1:05 AM, Linta Maria wrote: > > Still its not working. The code is working correctly. The real problem is that the PEM format 2048-bit RSA key you posted: > BEGIN PUBLIC KEY- > MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzMjyWZfVfBpmNKmIm9HH > FnrhDLZaCmQvZz57uJHhBLwLk/UAJ+kLKV9Lox8eKfimzisPFBad/TUfwPUaQmji > bPKCp+or2EHvPFooOnPWjSd57zPCohDdo0nOLw7iTUOMCvoqvJcdor+t1zBb8MQK > yNTycuoGlT19lr8msJFtR+ulfKucj/zk5w/jr0SsxysqFsvtEfa62Wu/wSDYIfsq > lKlRGLTlqJNtQybtTVv2Uu2KFrbe0C8+FBkxgtBS+0MkhzpJ37/02J+mHFx1bsgN > 09QnQY+T05te+6/mmlsHP3PYRqXqJOLl9AkLd/9kiMhSFshowFehKmls9PYt1xGf > 5QIDAQAB > -END PUBLIC KEY- is NOT the key that was used to generate the below signature, or the signature was subsequently altered. > Signature={ > 0x24,0xb8,0xec,0xb4,0x4f,0x31,0xa6,0x8,0x72,0x61,0xc9,0xd3,0x1c,0xd0,0x9b,0xee,0x26,0x2d,0x3d,0xef,0xff,0x2c,0x5,0x78,0x4,0xd3,0xa3,0xff,0xdc,0x97,0x53,0xe6,0x6e,0x85,0x41,0x1b,0xb2,0x2c,0xed,0xbd,0xa6,0x5d,0x6f,0xac,0xbb,0xd5,0xb8,0xa0,0x9,0x2b,0xf1,0xf5,0xb6,0xce,0xdd,0x70,0x8a,0x1a,0xa1,0x20,0x11,0x2b,0xf0,0x17,0x41,0x83,0x80,0xf6,0x61,0xd4,0x6d,0x53,0x8f,0xf1,0x8c,0x19,0x42,0x93,0x96,0xa9,0xb6,0xf2,0x8f,0x27,0x9c,0x66,0x17,0xc5,0xca,0x3d,0xa9,0x3f,0xc5,0x76,0x5f,0x1b,0x31,0xf2,0xd3,0xe,0x78,0x53,0x97,0xcb,0x9d,0xc4,0xe6,0x41,0x61,0x58,0x44,0x5c,0xf5,0xc4,0x67,0x69,0x8,0xa,0x92,0xd5,0x7e,0x9c,0xb9,0x7e,0x54,0x8b,0x8a,0xb,0xa1,0x9a,0x63,0xbf,0xcc,0xed,0x63,0x2c,0xf8,0x14,0x25,0x6,0xa2,0x2,0x0,0x7,0x2e,0x1c,0xc1,0xeb,0x16,0x89,0xaa,0x69,0xe2,0x75,0x57,0x39,0x71,0x68,0xe,0xf,0xa4,0x7a,0xc5,0x14,0x97,0x88,0x67,0xd1,0x36,0x91,0x3b,0x49,0xe7,0xb4,0xf3,0xcb,0xca,0xf6,0xe9,0xb1,0x22,0xe9,0x85,0x89,0xab,0x2,0x4,0x3c,0x2e,0xbd,0x56,0x3,0x8a,0x8b,0x54,0xc6,0xe6,0xed,0x5b,0x4c,0 xa4,0x9e,0x1b,0xaa,0x90,0xc6,0xb,0x27,0x54,0xc0,0x50,0x5f,0x58,0x97,0xc,0x99,0x5c,0x2,0x74,0xfc,0x9f,0x4c,0x78,0x4e,0xc3,0xb4,0x6d,0x14,0xa1,0xdc,0x62,0xc5,0xfe,0x27,0xb8,0x7d,0x98,0x79,0x82,0x50,0x3a,0xbe,0x6f,0x83,0x79,0xd,0x8a,0xb8,0x3e,0xac,0xa,0xeb,0x62,0xd5,0x5e,0x95} $ od -tx1 < /tmp/sig 00024 b8 ec b4 4f 31 a6 08 72 61 c9 d3 1c d0 9b ee 02026 2d 3d ef ff 2c 05 78 04 d3 a3 ff dc 97 53 e6 0406e 85 41 1b b2 2c ed bd a6 5d 6f ac bb d5 b8 a0 06009 2b f1 f5 b6 ce dd 70 8a 1a a1 20 11 2b f0 17 10041 83 80 f6 61 d4 6d 53 8f f1 8c 19 42 93 96 a9 120b6 f2 8f 27 9c 66 17 c5 ca 3d a9 3f c5 76 5f 1b 14031 f2 d3 0e 78 53 97 cb 9d c4 e6 41 61 58 44 5c 160f5 c4 67 69 08 0a 92 d5 7e 9c b9 7e 54 8b 8a 0b 200a1 9a 63 bf cc ed 63 2c f8 14 25 06 a2 02 00 07 2202e 1c c1 eb 16 89 aa 69 e2 75 57 39 71 68 0e 0f 240a4 7a c5 14 97 88 67 d1 36 91 3b 49 e7 b4 f3 cb 260ca f6 e9 b1 22 e9 85 89 ab 02 04 3c 2e bd 56 03 3008a 8b 54 c6 e6 ed 5b 4c a4 9e 1b aa 90 c6 0b 27 32054 c0 50 5f 58 97 0c 99 5c 02 74 fc 9f 4c 78 4e 340c3 b4 6d 14 a1 dc 62 c5 fe 27 b8 7d 98 79 82 50 3603a be 6f 83 79 0d 8a b8 3e ac 0a eb 62 d5 5e 95 $ openssl rsa -pubin -in /tmp/key writing RSA key -BEGIN PUBLIC KEY- MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzMjyWZfVfBpmNKmIm9HH FnrhDLZaCmQvZz57uJHhBLwLk/UAJ+kLKV9Lox8eKfimzisPFBad/TUfwPUaQmji bPKCp+or2EHvPFooOnPWjSd57zPCohDdo0nOLw7iTUOMCvoqvJcdor+t1zBb8MQK yNTycuoGlT19lr8msJFtR+ulfKucj/zk5w/jr0SsxysqFsvtEfa62Wu/wSDYIfsq lKlRGLTlqJNtQybtTVv2Uu2KFrbe0C8+FBkxgtBS+0MkhzpJ37/02J+mHFx1bsgN 09QnQY+T05te+6/mmlsHP3PYRqXqJOLl9AkLd/9kiMhSFshowFehKmls9PYt1xGf 5QIDAQAB -END PUBLIC KEY- Which match your post, but raw public key encryption of the signature data does not yield a PKCS1 padded message: $ openssl rsautl -encrypt -pubin -inkey /tmp/key -raw -in /tmp/sig | od -tx1 00095 ca 3c b7 cf d3 19 3d 1d 4a 29 61 67 59 21 d1 02061 47 9f 09 69 23 cc 05 77 21 e6 5c 12 9b ed 39 04006 7c 23 51 5f e3 3f 48 45 df 41 89 2e d6 92 4a 060bd b2 e8 36 e6 83 2a 1e 71 5e 5b 97 52 f2 bc 18 10063 3b 45 e0 c1 0a ec 48 ae 42 a3 e5 46 dc 80 77 12087 19 a0 29 94 e7 33 2a 77 2b bb 54 39 06 92 ca 140df b2 21 04 98 d7 cb 16 a6 a0 5b ac c3 d8 20 df 160ac 8f 3a 6d b9 20 7c cb 52 5e 7f f8 69 fc 39 7f 2008b db c1 16 4c df ca ba d7 33 5f 8e 21 87 6b ae 220a8 e1 20 1b e5 1f 8c 3f 18 2d b4 c0 0d 66 ec 1e 240f2 7b 78 ab ad 3c 8c da 80 24 25 3d c8 19 ad 48 260b3 21 ca 90 40 ce dd 22 85 6d 8b 6f ed da 77 be 30081 02 d3 d5 5a ec fd 9f 6e 4a 52 f1 18 31 d4 e1 32014 43 17 02 ff 74 f8 ee cf 2c 09 bc 60 d8 65 e3 3403c c2 e1
[openssl-users] Openssl api for signature verification using digest
Thanks Viktor for the help…. Please find below the input format. Still its not working. > On Aug 28, 2018, at 7:08 AM, Linta Maria wrote: > > I have used below code, but it’s not working. Please help me to get the correct API. > > /* > * NB: assumes verify_key, sig, siglen md and mdlen are already set up > * and that verify_key is an RSA public key > */ In what form is the message digest? Is it the raw digest octets, or some hex or base64 encoding? In what form is the signature? Message digest and signature is given in hex format. Msg ={ 0x8f,0x43,0x43,0x46,0x64,0x8f,0x6b,0x96,0xdf,0x89,0xdd,0xa9,0x1c,0x51,0x76,0xb1,0x0a,0x6d,0x83,0x96,0x1d,0xd3,0xc1,0xac,0x88,0xb5,0x9b,0x2d,0xc3,0x27,0xaa,0x4}; Signature={ 0x24,0xb8,0xec,0xb4,0x4f,0x31,0xa6,0x8,0x72,0x61,0xc9,0xd3,0x1c,0xd0,0x9b,0xee,0x26,0x2d,0x3d,0xef,0xff,0x2c,0x5,0x78,0x4,0xd3,0xa3,0xff,0xdc,0x97,0x53,0xe6,0x6e,0x85,0x41,0x1b,0xb2,0x2c,0xed,0xbd,0xa6,0x5d,0x6f,0xac,0xbb,0xd5,0xb8,0xa0,0x9,0x2b,0xf1,0xf5,0xb6,0xce,0xdd,0x70,0x8a,0x1a,0xa1,0x20,0x11,0x2b,0xf0,0x17,0x41,0x83,0x80,0xf6,0x61,0xd4,0x6d,0x53,0x8f,0xf1,0x8c,0x19,0x42,0x93,0x96,0xa9,0xb6,0xf2,0x8f,0x27,0x9c,0x66,0x17,0xc5,0xca,0x3d,0xa9,0x3f,0xc5,0x76,0x5f,0x1b,0x31,0xf2,0xd3,0xe,0x78,0x53,0x97,0xcb,0x9d,0xc4,0xe6,0x41,0x61,0x58,0x44,0x5c,0xf5,0xc4,0x67,0x69,0x8,0xa,0x92,0xd5,0x7e,0x9c,0xb9,0x7e,0x54,0x8b,0x8a,0xb,0xa1,0x9a,0x63,0xbf,0xcc,0xed,0x63,0x2c,0xf8,0x14,0x25,0x6,0xa2,0x2,0x0,0x7,0x2e,0x1c,0xc1,0xeb,0x16,0x89,0xaa,0x69,0xe2,0x75,0x57,0x39,0x71,0x68,0xe,0xf,0xa4,0x7a,0xc5,0x14,0x97,0x88,0x67,0xd1,0x36,0x91,0x3b,0x49,0xe7,0xb4,0xf3,0xcb,0xca,0xf6,0xe9,0xb1,0x22,0xe9,0x85,0x89,0xab,0x2,0x4,0x3c,0x2e,0xbd,0x56,0x3,0x8a,0x8b,0x54,0xc6,0xe6,0xed,0x5b,0x4c,0xa4,0x9e,0x1b,0xaa,0x90,0xc6,0xb,0x27,0x54,0xc0,0x50,0x5f,0x58,0x97,0xc,0x99,0x5c,0x2,0x74,0xfc,0x9f,0x4c,0x78,0x4e,0xc3,0xb4,0x6d,0x14,0xa1,0xdc,0x62,0xc5,0xfe,0x27,0xb8,0x7d,0x98,0x79,0x82,0x50,0x3a,0xbe,0x6f,0x83,0x79,0xd,0x8a,0xb8,0x3e,0xac,0xa,0xeb,0x62,0xd5,0x5e,0x95} PublicKey- In evp_pkey format BEGIN PUBLIC KEY- MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzMjyWZfVfBpmNKmIm9HH FnrhDLZaCmQvZz57uJHhBLwLk/UAJ+kLKV9Lox8eKfimzisPFBad/TUfwPUaQmji bPKCp+or2EHvPFooOnPWjSd57zPCohDdo0nOLw7iTUOMCvoqvJcdor+t1zBb8MQK yNTycuoGlT19lr8msJFtR+ulfKucj/zk5w/jr0SsxysqFsvtEfa62Wu/wSDYIfsq lKlRGLTlqJNtQybtTVv2Uu2KFrbe0C8+FBkxgtBS+0MkhzpJ37/02J+mHFx1bsgN 09QnQY+T05te+6/mmlsHP3PYRqXqJOLl9AkLd/9kiMhSFshowFehKmls9PYt1xGf 5QIDAQAB -END PUBLIC KEY- > ctx = EVP_PKEY_CTX_new(verify_key, NULL /* no engine */); > if (!ctx) > /* Error occurred */ > > if (EVP_PKEY_verify_init(ctx) <= 0) > /* Error */ > > if (EVP_PKEY_CTX_set_rsa_padding(ctx, RSA_PKCS1_PADDING) <= 0) > /* Error */ > > if (EVP_PKEY_CTX_set_signature_md(ctx, EVP_sha256()) <= 0) > /* Error */ Since you're verifying a hash, do not configure a message digest. > /* Perform operation */ > > ret = EVP_PKEY_verify(ctx, sig, siglen, md, mdlen); This is the right function for verifying public key signatures over some input. For more help, post the *public* key used, the signature and the input digest. Message digest and signature is given in hex format. Msg ={ 0x8f,0x43,0x43,0x46,0x64,0x8f,0x6b,0x96,0xdf,0x89,0xdd,0xa9,0x1c,0x51,0x76,0xb1,0x0a,0x6d,0x83,0x96,0x1d,0xd3,0xc1,0xac,0x88,0xb5,0x9b,0x2d,0xc3,0x27,0xaa,0x4}; Signature={ 0x24,0xb8,0xec,0xb4,0x4f,0x31,0xa6,0x8,0x72,0x61,0xc9,0xd3,0x1c,0xd0,0x9b,0xee,0x26,0x2d,0x3d,0xef,0xff,0x2c,0x5,0x78,0x4,0xd3,0xa3,0xff,0xdc,0x97,0x53,0xe6,0x6e,0x85,0x41,0x1b,0xb2,0x2c,0xed,0xbd,0xa6,0x5d,0x6f,0xac,0xbb,0xd5,0xb8,0xa0,0x9,0x2b,0xf1,0xf5,0xb6,0xce,0xdd,0x70,0x8a,0x1a,0xa1,0x20,0x11,0x2b,0xf0,0x17,0x41,0x83,0x80,0xf6,0x61,0xd4,0x6d,0x53,0x8f,0xf1,0x8c,0x19,0x42,0x93,0x96,0xa9,0xb6,0xf2,0x8f,0x27,0x9c,0x66,0x17,0xc5,0xca,0x3d,0xa9,0x3f,0xc5,0x76,0x5f,0x1b,0x31,0xf2,0xd3,0xe,0x78,0x53,0x97,0xcb,0x9d,0xc4,0xe6,0x41,0x61,0x58,0x44,0x5c,0xf5,0xc4,0x67,0x69,0x8,0xa,0x92,0xd5,0x7e,0x9c,0xb9,0x7e,0x54,0x8b,0x8a,0xb,0xa1,0x9a,0x63,0xbf,0xcc,0xed,0x63,0x2c,0xf8,0x14,0x25,0x6,0xa2,0x2,0x0,0x7,0x2e,0x1c,0xc1,0xeb,0x16,0x89,0xaa,0x69,0xe2,0x75,0x57,0x39,0x71,0x68,0xe,0xf,0xa4,0x7a,0xc5,0x14,0x97,0x88,0x67,0xd1,0x36,0x91,0x3b,0x49,0xe7,0xb4,0xf3,0xcb,0xca,0xf6,0xe9,0xb1,0x22,0xe9,0x85,0x89,0xab,0x2,0x4,0x3c,0x2e,0xbd,0x56,0x3,0x8a,0x8b,0x54,0xc6,0xe6,0xed,0x5b,0x4c,0xa4,0x9e,0x1b,0xaa,0x90,0xc6,0xb,0x27,0x54,0xc0,0x50,0x5f,0x58,0x97,0xc,0x99,0x5c,0x2,0x74,0xfc,0x9f,0x4c,0x78,0x4e,0xc3,0xb4,0x6d,0x14,0xa1,0xdc,0x62,0xc5,0xfe,0x27,0xb8,0x7d,0x98,0x79,0x82,0x50,0x3a,0xbe,0x6f,0x83,0x79,0xd,0x8a,0xb8,0x3e,0xac,0xa,0xeb,0x62,0xd5,0x5e,0x95} PublicKey- In evp_pkey format BEGIN PUBLIC KEY- MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzMjyWZfVfBpmNKmIm9HH FnrhDLZaCmQvZz57uJHhBLwLk/UAJ+kLKV9Lox8eKfimzisPFBad/TUfwPUaQmji bPKCp+or2EHvPFooOnPWjSd57zPCohDdo0nOLw7iTUOMCvoqvJcdor+t1zBb8MQK yNTycuoGlT19lr8msJFtR+ulfKucj/zk5w/jr0SsxysqFsvtEfa62Wu/wSDYIfsq
Re: [openssl-users] Openssl api for signature verification using digest
[ Please post plain text, not HTML ] > On Aug 28, 2018, at 7:08 AM, Linta Maria wrote: > > I have used below code, but it’s not working. Please help me to get the > correct API. > > /* > * NB: assumes verify_key, sig, siglen md and mdlen are already set up > * and that verify_key is an RSA public key > */ In what form is the message digest? Is it the raw digest octets, or some hex or base64 encoding? In what form is the signature? > ctx = EVP_PKEY_CTX_new(verify_key, NULL /* no engine */); > if (!ctx) > /* Error occurred */ > > if (EVP_PKEY_verify_init(ctx) <= 0) > /* Error */ > > if (EVP_PKEY_CTX_set_rsa_padding(ctx, RSA_PKCS1_PADDING) <= 0) > /* Error */ > > if (EVP_PKEY_CTX_set_signature_md(ctx, EVP_sha256()) <= 0) > /* Error */ Since you're verifying a hash, do not configure a message digest. > /* Perform operation */ > > ret = EVP_PKEY_verify(ctx, sig, siglen, md, mdlen); This is the right function for verifying public key signatures over some input. For more help, post the *public* key used, the signature and the input digest. You can find similar code in the source code of the rsautl and pkeyutl commands. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Openssl api for signature verification using digest
Thanks Nicola for the updates. But I need to verify signature with hashed data or digest not with original message. Is there any openssl API to implement that? On Tue 28 Aug, 2018, 5:18 PM Nicola, wrote: > Hi! > > I would suggest using the newer `EVP_DigestSign` interface. > > You could find more documentation about it here: > https://wiki.openssl.org/index.php/EVP_Signing_and_Verifying > > Here is the relevant manpage: > https://www.openssl.org/docs/man1.1.1/man3/EVP_DigestVerifyInit.html > > Best regards, > > Nicola Tuveri > > On Tue, Aug 28, 2018, 14:09 Linta Maria wrote: > >> >> >> Hi All, >> >> >> >> >> >> I have started using open ssl recently for implementing some >> cryptographic operation. >> >> Now I want to implement signature verification by taking Signature and >> hashed data as input, but I am not able to get the proper API. >> >> I have used below code, but it’s not working. Please help me to get the >> correct API. >> >> >> >> >> >> #include >> >> #include >> >> >> >> EVP_PKEY_CTX *ctx; >> >> unsigned char *md, *sig; >> >> size_t mdlen, siglen; >> >> EVP_PKEY *verify_key; >> >> >> >> /* >> >> * NB: assumes verify_key, sig, siglen md and mdlen are already set up >> >> * and that verify_key is an RSA public key >> >> */ >> >> ctx = EVP_PKEY_CTX_new(verify_key, NULL /* no engine */); >> >> if (!ctx) >> >> /* Error occurred */ >> >> if (EVP_PKEY_verify_init(ctx) <= 0) >> >> /* Error */ >> >> if (EVP_PKEY_CTX_set_rsa_padding(ctx, RSA_PKCS1_PADDING) <= 0) >> >> /* Error */ >> >> if (EVP_PKEY_CTX_set_signature_md(ctx, EVP_sha256()) <= 0) >> >> /* Error */ >> >> >> >> /* Perform operation */ >> >> ret = EVP_PKEY_verify(ctx, sig, siglen, md, mdlen); >> >> >> >> /* >> >> * ret == 1 indicates success, 0 verify failure and < 0 for some >> >> * other error. >> >> */ >> >> >> >> >> >> >> >> Best regards, >> >> *George Linta Maria* >> -- >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Openssl api for signature verification using digest
Hi! I would suggest using the newer `EVP_DigestSign` interface. You could find more documentation about it here: https://wiki.openssl.org/index.php/EVP_Signing_and_Verifying Here is the relevant manpage: https://www.openssl.org/docs/man1.1.1/man3/EVP_DigestVerifyInit.html Best regards, Nicola Tuveri On Tue, Aug 28, 2018, 14:09 Linta Maria wrote: > > > Hi All, > > > > > > I have started using open ssl recently for implementing some cryptographic > operation. > > Now I want to implement signature verification by taking Signature and > hashed data as input, but I am not able to get the proper API. > > I have used below code, but it’s not working. Please help me to get the > correct API. > > > > > > #include > > #include > > > > EVP_PKEY_CTX *ctx; > > unsigned char *md, *sig; > > size_t mdlen, siglen; > > EVP_PKEY *verify_key; > > > > /* > > * NB: assumes verify_key, sig, siglen md and mdlen are already set up > > * and that verify_key is an RSA public key > > */ > > ctx = EVP_PKEY_CTX_new(verify_key, NULL /* no engine */); > > if (!ctx) > > /* Error occurred */ > > if (EVP_PKEY_verify_init(ctx) <= 0) > > /* Error */ > > if (EVP_PKEY_CTX_set_rsa_padding(ctx, RSA_PKCS1_PADDING) <= 0) > > /* Error */ > > if (EVP_PKEY_CTX_set_signature_md(ctx, EVP_sha256()) <= 0) > > /* Error */ > > > > /* Perform operation */ > > ret = EVP_PKEY_verify(ctx, sig, siglen, md, mdlen); > > > > /* > > * ret == 1 indicates success, 0 verify failure and < 0 for some > > * other error. > > */ > > > > > > > > Best regards, > > *George Linta Maria* > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Openssl api for signature verification using digest
Hi All, I have started using open ssl recently for implementing some cryptographic operation. Now I want to implement signature verification by taking Signature and hashed data as input, but I am not able to get the proper API. I have used below code, but it’s not working. Please help me to get the correct API. #include #include EVP_PKEY_CTX *ctx; unsigned char *md, *sig; size_t mdlen, siglen; EVP_PKEY *verify_key; /* * NB: assumes verify_key, sig, siglen md and mdlen are already set up * and that verify_key is an RSA public key */ ctx = EVP_PKEY_CTX_new(verify_key, NULL /* no engine */); if (!ctx) /* Error occurred */ if (EVP_PKEY_verify_init(ctx) <= 0) /* Error */ if (EVP_PKEY_CTX_set_rsa_padding(ctx, RSA_PKCS1_PADDING) <= 0) /* Error */ if (EVP_PKEY_CTX_set_signature_md(ctx, EVP_sha256()) <= 0) /* Error */ /* Perform operation */ ret = EVP_PKEY_verify(ctx, sig, siglen, md, mdlen); /* * ret == 1 indicates success, 0 verify failure and < 0 for some * other error. */ Best regards, *George Linta Maria* -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] CRL signature verification
➢ I was more talking about the parsing. Currently I have 40 LOC [1] to Look at X509_get1_ocsp which is in crypto/x509v3/v3_utl.c That’s in 1.0.2 and later ➢ > X509_CRL_verify. And yes, looking through to find the serial# is what you have to do. ➢ That's 1.1-specific, correct? Yes. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] CRL signature verification
Hi Rich, On 18-10-17 17:46, Salz, Rich via openssl-users wrote: > ➢ I used libcrypto to parse out the OCSP URL from the certificate validate > it against a whitelist of valid OCSP URLs, send an OCSP request and > validate the response and its signature against a custom certificate > store, and then parse out the result. > > Two points on that: > ➢ - This seems like something that should be in libcrypto rather than in > my own code. Did I miss something obvious? > > We generally don’t do any kind of network traffic (except SSL) and would > rather leave that up to the application. Especially because there are all > sorts of other frameworks, blocking issues, DNS, etc., that make things a > non-simple matter. Sorry, I should have been clearer. I didn't mean the HTTP requests etc. I agree that that should not be done by libcrypto. I was more talking about the parsing. Currently I have 40 LOC [1] to find the OCSP URL from a certificate; it seems to me that that's a lot of stuff that I shouldn't have to be doing, and that asking OpenSSL to parse out that URL (or really, any other X.509v3 extension's data) should not be too complicated. Perhaps I missed the call that I should have been using, though ;-) [1] https://github.com/Fedict/eid-mw/blob/master/plugins_tools/eid-viewer/verify.c#L89-L129 > ➢ - Currently I don't fall back to CRLs when the OCSP server is > unavailable. I would like to do so; however, I can't figure out how to > validate the signature on a CRL (which would be a pretty obvious > failure). Alternatively, is there an obvious alternative thing that I > should be doing, rather than manually parsing the CRL? > > X509_CRL_verify. And yes, looking through to find the serial# is what you > have to do. That's 1.1-specific, correct? -- Wouter Verhelst -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] CRL signature verification
➢ I used libcrypto to parse out the OCSP URL from the certificate validate it against a whitelist of valid OCSP URLs, send an OCSP request and validate the response and its signature against a custom certificate store, and then parse out the result. Two points on that: ➢ - This seems like something that should be in libcrypto rather than in my own code. Did I miss something obvious? We generally don’t do any kind of network traffic (except SSL) and would rather leave that up to the application. Especially because there are all sorts of other frameworks, blocking issues, DNS, etc., that make things a non-simple matter. ➢ - Currently I don't fall back to CRLs when the OCSP server is unavailable. I would like to do so; however, I can't figure out how to validate the signature on a CRL (which would be a pretty obvious failure). Alternatively, is there an obvious alternative thing that I should be doing, rather than manually parsing the CRL? X509_CRL_verify. And yes, looking through to find the serial# is what you have to do. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] CRL signature verification
Hi, I have an application which wants to do verification of a certificate. Not in the context of a context or a signature, but simply to verify if the certificates are still valid and from a source that is correct in the context in which the application runs. I used libcrypto to parse out the OCSP URL from the certificate validate it against a whitelist of valid OCSP URLs, send an OCSP request and validate the response and its signature against a custom certificate store, and then parse out the result. Two points on that: - This seems like something that should be in libcrypto rather than in my own code. Did I miss something obvious? - Currently I don't fall back to CRLs when the OCSP server is unavailable. I would like to do so; however, I can't figure out how to validate the signature on a CRL (which would be a pretty obvious failure). Alternatively, is there an obvious alternative thing that I should be doing, rather than manually parsing the CRL? Thanks, -- Wouter Verhelst -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OCSP signature verification
Hi, (that other mail on OCSP on this list reminded me of this...) I've found the answer in the mean time by using a debugger and single-stepping through the library... On 01-12-15 14:58, Verhelst Wouter (Consultant) wrote: Hi folks, I'm trying to write an application that needs to verify the validity of data on a smartcard. That data is signed with an RSA key for which a certificate exists on the card; but if the card is stolen or lost, the certificate will be revoked, so I want to ensure that the certificate is valid. I'm doing an OCSP request to take care of that. Since OpenSSL's own OCSP_sendreq_* functions don't support HTTP proxies, I'm currently using libcurl to send the request to the OCSP endpoint. This seems to work; when I get the reply and use d2i_OCSP_RESPONSE(), then with things like OCSP_response_status() and OCSP_resp_find_status() and friends I can manage to get the status of the request and a given certificate. However, that doesn't do signature verification. I believe that I should use OCSP_basic_verify() for that, but I'm not entirely sure whether that is the case, and if so whether I would need to do some additional checks beforehand. Unfortunately, I can't find any documentation on OCSP_basic_verify(). I should note that due to the nature of my needs, I have a rather huge set of valid intermediate CAs, but a fairly limited set of root CAs that can be used for valid cards (that is, if the signature validates but it wasn't signed by any of the CAs under one of my limited set of roots, the card is a forgery and should be rejected as invalid). A few questions: - Am I right in assuming that OCSP_basic_verify will check the signature on the OCSP request? Answer: yes (verified this by modifying some data in the OCSP response data, which caused signature verification to fail) - In "OCSP_basic_verify(OCSP_BASICRESP *bs, STACK_OF(X509) *certs, X509_STORE *st, unsigned long flags)", I'm not entirely certain of what the "st" argument is meant to contain, and can't figure out the "certs" one. Pouring over the code, I believe the "st" argument should allow me to limit validation to my set of root certificates, but I could be mistaken. As for the "certs" one, I can't understand that one at all. The only thing I can think of is that maybe it should contain the issuer certificate that I used for the original request, but then why is it a STACK_OF(X509)* and not just an X509*? What am I missing? Answers: - The "STACK_OF(X509) *certs" argument should just be bs->certs (i.e., the certificates which were sent along with the OCSP response, and which contain all certificates required to be able to verify the signature on the response as well as its certificate chain). I assume this is done so as to retain API compatibility with other certificate verification methods (e.g., using CRLs), even though the *certs argument really is superfluous (OCSP_basic_verify could just as easily pluck those certificates out of the *bs argument). - The "X509_STORE *st" argument indeed allows me to limit the root certificates allowed for valid signatures. By not including the default certificate store, I can reject cards that are signed by a different root. -- Wouter Verhelst ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OCSP signature verification
On 01-12-15 14:58, Verhelst Wouter (Consultant) wrote: Hi folks, I'm trying to write an application that needs to verify the validity of data on a smartcard. That data is signed with an RSA key for which a certificate exists on the card; but if the card is stolen or lost, the certificate will be revoked, so I want to ensure that the certificate is valid. I'm doing an OCSP request to take care of that. Since OpenSSL's own OCSP_sendreq_* functions don't support HTTP proxies, I'm currently using libcurl to send the request to the OCSP endpoint. This seems to work; when I get the reply and use d2i_OCSP_RESPONSE(), then with things like OCSP_response_status() and OCSP_resp_find_status() and friends I can manage to get the status of the request and a given certificate. However, that doesn't do signature verification. I believe that I should use OCSP_basic_verify() for that, but I'm not entirely sure whether that is the case, and if so whether I would need to do some additional checks beforehand. Unfortunately, I can't find any documentation on OCSP_basic_verify(). I should note that due to the nature of my needs, I have a rather huge set of valid intermediate CAs, but a fairly limited set of root CAs that can be used for valid cards (that is, if the signature validates but it wasn't signed by any of the CAs under one of my limited set of roots, the card is a forgery and should be rejected as invalid). A few questions: - Am I right in assuming that OCSP_basic_verify will check the signature on the OCSP request? - In "OCSP_basic_verify(OCSP_BASICRESP *bs, STACK_OF(X509) *certs, X509_STORE *st, unsigned long flags)", I'm not entirely certain of what the "st" argument is meant to contain, and can't figure out the "certs" one. Pouring over the code, I believe the "st" argument should allow me to limit validation to my set of root certificates, but I could be mistaken. As for the "certs" one, I can't understand that one at all. The only thing I can think of is that maybe it should contain the issuer certificate that I used for the original request, but then why is it a STACK_OF(X509)* and not just an X509*? What am I missing? Thanks for any help, Ping. Anyone? If this is documented somewhere, feel free to point me to the documentation... -- Wouter Verhelst ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] OCSP signature verification
Hi folks, I'm trying to write an application that needs to verify the validity of data on a smartcard. That data is signed with an RSA key for which a certificate exists on the card; but if the card is stolen or lost, the certificate will be revoked, so I want to ensure that the certificate is valid. I'm doing an OCSP request to take care of that. Since OpenSSL's own OCSP_sendreq_* functions don't support HTTP proxies, I'm currently using libcurl to send the request to the OCSP endpoint. This seems to work; when I get the reply and use d2i_OCSP_RESPONSE(), then with things like OCSP_response_status() and OCSP_resp_find_status() and friends I can manage to get the status of the request and a given certificate. However, that doesn't do signature verification. I believe that I should use OCSP_basic_verify() for that, but I'm not entirely sure whether that is the case, and if so whether I would need to do some additional checks beforehand. Unfortunately, I can't find any documentation on OCSP_basic_verify(). I should note that due to the nature of my needs, I have a rather huge set of valid intermediate CAs, but a fairly limited set of root CAs that can be used for valid cards (that is, if the signature validates but it wasn't signed by any of the CAs under one of my limited set of roots, the card is a forgery and should be rejected as invalid). A few questions: - Am I right in assuming that OCSP_basic_verify will check the signature on the OCSP request? - In "OCSP_basic_verify(OCSP_BASICRESP *bs, STACK_OF(X509) *certs, X509_STORE *st, unsigned long flags)", I'm not entirely certain of what the "st" argument is meant to contain, and can't figure out the "certs" one. Pouring over the code, I believe the "st" argument should allow me to limit validation to my set of root certificates, but I could be mistaken. As for the "certs" one, I can't understand that one at all. The only thing I can think of is that maybe it should contain the issuer certificate that I used for the original request, but then why is it a STACK_OF(X509)* and not just an X509*? What am I missing? Thanks for any help, -- Wouter Verhelst ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] beginner needs advice on data signature/verification
(continuing top posting to keep thread consistent) Note that the point of using an X.509 signature at file creation time and/or client approval time was to reuse the internal file structure that is already designed to hold that particular signature format (specifically, the internal file structure that would eventually hold the final signature, which was already specified to be in that format). Thus the idea was to simplify and reuse code, given the existence of code, tools and data formats to sign those particular files with X.509 signatures. This was also (presumably) the reason Microsoft did it this way. But yes, of cause if the file generation is already secure, then the secure file generation machine should apply an initial signature and the client just add some kind of counter-signature authorizing this particular one of the securely generated files. On 24/06/2015 15:24, Michael Wojcik wrote: In Marco's original description, the file is created by a trusted system and then transmitted to the client. Then, later, the client transmits it to the server, which verifies the contents. If the file is signed by the creating system, it doesn't matter if the client is compromised. A compromised client can refuse to send the file, or it can send a forged or corrupted file, but the server can dectect all of those cases. It's not clear from Marco's description whether the system that creates the file can perform the signing process, but I don't see any reason (in the description) why not. It would help if this point were clarified. The Windows driver-signing process and similar look wildly overengineered for Marco's purposes, if my understanding of his requirements is correct. They have a very different threat model - and that's why this isn't a common requirement. Windows drivers are created by thousands of organizations and consumed by thousands of end users. Marco has files created on a trusted system (or handful of trusted systems) he controls, and verified by trusted systems he controls. His followup message below says data has to be signed with an X.509 certificates public key that already exists. I'm guessing this actually means data has to be signed with the private key corresponding to a public key that happens to be in an X.509 certificate that already exists. That doesn't mean X.509 PKI must be used; X.509 isn't some sort of virus that infects everything it touches (appearances to the contrary). There's an asymmetric key pair of some sort - RSA probably - and we need to use it for signing. Fine. Here's what I'd do: the originating trusted system creates the data and runs openssl rsautl -sign with appropriate parameters to create a signature. (Just script the openssl command-line utility; this is a trusted system, so why reimplement the code?) Add the signature to the proprietary file format. Send the whole thing to the client. Client subsequently sends the signed data and signature to the server, as part of a file in the proprietary format, along with whatever unsigned data is included. Server extracts the signed data and signature, and uses openssl rsautl -verify to verify it. Michael Wojcik Technology Specialist, Micro Focus (original text snipped) Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] beginner needs advice on data signature/verification
In Marco's original description, the file is created by a trusted system and then transmitted to the client. Then, later, the client transmits it to the server, which verifies the contents. If the file is signed by the creating system, it doesn't matter if the client is compromised. A compromised client can refuse to send the file, or it can send a forged or corrupted file, but the server can dectect all of those cases. It's not clear from Marco's description whether the system that creates the file can perform the signing process, but I don't see any reason (in the description) why not. It would help if this point were clarified. The Windows driver-signing process and similar look wildly overengineered for Marco's purposes, if my understanding of his requirements is correct. They have a very different threat model - and that's why this isn't a common requirement. Windows drivers are created by thousands of organizations and consumed by thousands of end users. Marco has files created on a trusted system (or handful of trusted systems) he controls, and verified by trusted systems he controls. His followup message below says data has to be signed with an X.509 certificates public key that already exists. I'm guessing this actually means data has to be signed with the private key corresponding to a public key that happens to be in an X.509 certificate that already exists. That doesn't mean X.509 PKI must be used; X.509 isn't some sort of virus that infects everything it touches (appearances to the contrary). There's an asymmetric key pair of some sort - RSA probably - and we need to use it for signing. Fine. Here's what I'd do: the originating trusted system creates the data and runs openssl rsautl -sign with appropriate parameters to create a signature. (Just script the openssl command-line utility; this is a trusted system, so why reimplement the code?) Add the signature to the proprietary file format. Send the whole thing to the client. Client subsequently sends the signed data and signature to the server, as part of a file in the proprietary format, along with whatever unsigned data is included. Server extracts the signed data and signature, and uses openssl rsautl -verify to verify it. Michael Wojcik Technology Specialist, Micro Focus From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Jakob Bohm Sent: Wednesday, June 24, 2015 01:53 To: openssl-users@openssl.org Subject: Re: [openssl-users] beginner needs advice on data signature/verification (Continuing top posting to keep thread consistent). First of all, if the client itself is compromised, the file content can be compromised just before you do whatever you do to assure the server that this was what the user of the client wanted. No way to fix that other than to keep the client free of compromise. Now the common solution used by driver and program signing programs such as Symbian signed (discontinued), Windows driver package signing for compatibility, Windows driver binary signing for Windows 10, and older versions of Windows Mobile 5.x/6.x signing is this: 1. Client has a unique X509 certificate with a private key known only to that client. Doesn't matter who issued the certificate, but the server needs to have its own known genuine copy of that certificate. That certificate should be such that no one except that client and that server trusts things for being signed by it. 2. Client signs the file/message with its private certificate exactly as if that would be the final signature (even though almost no one will trust it). 3. Client sends signed file/message to server. 4. Server verifies the signed file/message using its private list of trusted client certificates. 5. Server maps the verified signature to the identity to be used for the final signature. 6. Server talks to its closely related CA to get a brand new single-use-only certificate for the identity (with a serial number added as an extra subject name element). 7. Server removes the client signature and signs the file/message with the brand new certificate for the final identity. 8. Server throws away the private key, so that no more files can be signed with that certificate, ever. 9. If the server ever signs anything by mistake, it (or an admin if the server was permanently compromised) asks its closely related CA to revoke the affected single-use certificate. 10. If the client certificate needs to be revoked due to the certificate or its user being compromised on some current or past time/date, the related CA revokes all the single-use certificates for that identity since that date/time. Other/replacement client certificates for the same (visible) identity remain valid because single-use certificates for those requests were never revoked. 11. Note that in this setup, there is no need for a time stamping service, simply give the single-use certificate the long
Re: [openssl-users] beginner needs advice on data signature/verification
Many thanks for the answer. I should have been more specific on the requirements right away. The file was really just an example to keep it simple. Reading my own writing, I would probably have suggested what you did :-) So here are the facts: - client/server are not connected to the internet - the network protocol is existing and proprietary - the file structure is existing and proprietary, but can be extended to allow for additional signature information to be embedded that will be sent to the server - the data actually transferred (and to be signed) is part of that file - the data has to be signed with an X.509 certificates public key that already exists S/MIME does pretty much do what I want to do. However the network protocol or the data to be signed cannot be changed for compatibility reasons. Under these circumstances, I don't really see how I could achieve my goal easier than by openssl directly. Considering the very common requirement: I was thinking of i.e. windows driver signatures, android/ios app signatures and similar mechanisms to ensure that files are from a trusted source. Am 22.06.2015 um 14:44 schrieb Michael Wojcik: Response inline below, prefixed with MW. (Unfortunately Outlook is incapable of replying to HTML messages properly, so you'll have to excuse the formatting.) Michael Wojcik Technology Specialist, Micro Focus *From:*openssl-users [mailto:openssl-users-boun...@openssl.org] *On Behalf Of *Marco Warga *Sent:* Saturday, June 20, 2015 04:48 *To:* openssl-users@openssl.org *Subject:* [openssl-users] beginner needs advice on data signature/verification Hi, I hope some of you could give me advice on my project using openssl. MW: Why are you using OpenSSL for this application? You want to create a file on a trusted system, pass it through an untrusted intermediary, and process it on another trusted system. Why not simply use an existing mechanism like secure email? (GPG is the obvious choice, unless there are licensing issues.) If you are determined to create your own protocol from primitives, then really all you appear to need here is an HMAC. Don't involve the horrific mess that is X.509 PKI unless it actually provides some benefit. Lets say I have a server/service on a machine processing a file a corresponding client sends. That file is usually created by me on a clean third machine. The server side is assumed to be uncompromised (no hacker). The client side may be compromised. Now I need to make sure that the service only accepts those files that are created by me. I believe that is a very common requirement and has been done alot of times - I just can't find tutorials on how to implement it. Know any ? MW: No, but that's probably because what you've described isn't a very common requirement. It's too vague. We don't know what problem you're actually trying to solve. It may be that you just need to send a file with a verifier, which - as I noted above - /is/ commonly done, generally using something like GPG or (for roll-your-own protocols where both ends are controlled by the same party) an HMAC. Lets assume I have an x509 cert together with its private key signed by a ca owned by me. The trusted ca cert will be present on the server side. This is what I plan to do: 1.) Create the data files/blobs and sign them using the priv key of the cert. Distribute the cert and the signature along with (or inside) the data file. 2.) Have the client send that data file to the server (cert/sig first) 3.) Service receives the cert, builds a cert store with the local ca cert in it and verifies the client's cert with X509_verify_cert() 4.) if cert verifies ok, service compares the signature against the one calculated from the incoming data using the public key that came inside the cert just verified Would this be the right approach considering that anything the client sends may be forged (cert, sig, data...) ? MW: It's safe from malicious behavior by the client, under a threat model where an attacker is not able to forge client certificates or client signatures. In other words, it's safe as long as the private keys are neither leaked nor forced. Or would it be safer to have the cert used for signing stored on the server side and not send with the data (instead just its subject protected by the signature) ? MW: Irrelevant to the security of the scheme. Simpler from a development and operations standpoint. But using something like PGP/GPG or S/MIME would be simpler yet. There are any number of examples online for signing a file and verifying its signature. Thanks alot, Marco X509_verify_cert X509_verify_cert Click here https://www.mailcontrol.com/sr/SMsSvn1riRfGX2PQPOmvUsrLibhXE7+S86glxWVUEjKk%21XLlG9uNumpG1wkqEL+kqdX9II%21hjWj1JTd%211uc+%21w== to report this email as spam. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman
Re: [openssl-users] beginner needs advice on data signature/verification
for the e-mail signing or document-signing extended usage attribute, not the object-signing one. On 23/06/2015 19:55, Marco Warga wrote: Many thanks for the answer. I should have been more specific on the requirements right away. The file was really just an example to keep it simple. Reading my own writing, I would probably have suggested what you did :-) So here are the facts: - client/server are not connected to the internet - the network protocol is existing and proprietary - the file structure is existing and proprietary, but can be extended to allow for additional signature information to be embedded that will be sent to the server - the data actually transferred (and to be signed) is part of that file - the data has to be signed with an X.509 certificates public key that already exists S/MIME does pretty much do what I want to do. However the network protocol or the data to be signed cannot be changed for compatibility reasons. Under these circumstances, I don't really see how I could achieve my goal easier than by openssl directly. Considering the very common requirement: I was thinking of i.e. windows driver signatures, android/ios app signatures and similar mechanisms to ensure that files are from a trusted source. Am 22.06.2015 um 14:44 schrieb Michael Wojcik: Response inline below, prefixed with MW. (Unfortunately Outlook is incapable of replying to HTML messages properly, so you'll have to excuse the formatting.) *From:*openssl-users [mailto:openssl-users-boun...@openssl.org] *On Behalf Of *Marco Warga *Sent:* Saturday, June 20, 2015 04:48 *To:* openssl-users@openssl.org *Subject:* [openssl-users] beginner needs advice on data signature/verification Hi, I hope some of you could give me advice on my project using openssl. MW: Why are you using OpenSSL for this application? You want to create a file on a trusted system, pass it through an untrusted intermediary, and process it on another trusted system. Why not simply use an existing mechanism like secure email? (GPG is the obvious choice, unless there are licensing issues.) If you are determined to create your own protocol from primitives, then really all you appear to need here is an HMAC. Don't involve the horrific mess that is X.509 PKI unless it actually provides some benefit. Lets say I have a server/service on a machine processing a file a corresponding client sends. That file is usually created by me on a clean third machine. The server side is assumed to be uncompromised (no hacker). The client side may be compromised. Now I need to make sure that the service only accepts those files that are created by me. I believe that is a very common requirement and has been done alot of times - I just can't find tutorials on how to implement it. Know any ? MW: No, but that's probably because what you've described isn't a very common requirement. It's too vague. We don't know what problem you're actually trying to solve. It may be that you just need to send a file with a verifier, which - as I noted above - /is/ commonly done, generally using something like GPG or (for roll-your-own protocols where both ends are controlled by the same party) an HMAC. Lets assume I have an x509 cert together with its private key signed by a ca owned by me. The trusted ca cert will be present on the server side. This is what I plan to do: 1.) Create the data files/blobs and sign them using the priv key of the cert. Distribute the cert and the signature along with (or inside) the data file. 2.) Have the client send that data file to the server (cert/sig first) 3.) Service receives the cert, builds a cert store with the local ca cert in it and verifies the client's cert with X509_verify_cert() 4.) if cert verifies ok, service compares the signature against the one calculated from the incoming data using the public key that came inside the cert just verified Would this be the right approach considering that anything the client sends may be forged (cert, sig, data...) ? MW: It's safe from malicious behavior by the client, under a threat model where an attacker is not able to forge client certificates or client signatures. In other words, it's safe as long as the private keys are neither leaked nor forced. Or would it be safer to have the cert used for signing stored on the server side and not send with the data (instead just its subject protected by the signature) ? MW: Irrelevant to the security of the scheme. Simpler from a development and operations standpoint. But using something like PGP/GPG or S/MIME would be simpler yet. There are any number of examples online for signing a file and verifying its signature. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones
Re: [openssl-users] beginner needs advice on data signature/verification
Response inline below, prefixed with MW. (Unfortunately Outlook is incapable of replying to HTML messages properly, so you'll have to excuse the formatting.) Michael Wojcik Technology Specialist, Micro Focus From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Marco Warga Sent: Saturday, June 20, 2015 04:48 To: openssl-users@openssl.org Subject: [openssl-users] beginner needs advice on data signature/verification Hi, I hope some of you could give me advice on my project using openssl. MW: Why are you using OpenSSL for this application? You want to create a file on a trusted system, pass it through an untrusted intermediary, and process it on another trusted system. Why not simply use an existing mechanism like secure email? (GPG is the obvious choice, unless there are licensing issues.) If you are determined to create your own protocol from primitives, then really all you appear to need here is an HMAC. Don't involve the horrific mess that is X.509 PKI unless it actually provides some benefit. Lets say I have a server/service on a machine processing a file a corresponding client sends. That file is usually created by me on a clean third machine. The server side is assumed to be uncompromised (no hacker). The client side may be compromised. Now I need to make sure that the service only accepts those files that are created by me. I believe that is a very common requirement and has been done alot of times - I just can't find tutorials on how to implement it. Know any ? MW: No, but that's probably because what you've described isn't a very common requirement. It's too vague. We don't know what problem you're actually trying to solve. It may be that you just need to send a file with a verifier, which - as I noted above - is commonly done, generally using something like GPG or (for roll-your-own protocols where both ends are controlled by the same party) an HMAC. Lets assume I have an x509 cert together with its private key signed by a ca owned by me. The trusted ca cert will be present on the server side. This is what I plan to do: 1.) Create the data files/blobs and sign them using the priv key of the cert. Distribute the cert and the signature along with (or inside) the data file. 2.) Have the client send that data file to the server (cert/sig first) 3.) Service receives the cert, builds a cert store with the local ca cert in it and verifies the client's cert with X509_verify_cert() 4.) if cert verifies ok, service compares the signature against the one calculated from the incoming data using the public key that came inside the cert just verified Would this be the right approach considering that anything the client sends may be forged (cert, sig, data...) ? MW: It's safe from malicious behavior by the client, under a threat model where an attacker is not able to forge client certificates or client signatures. In other words, it's safe as long as the private keys are neither leaked nor forced. Or would it be safer to have the cert used for signing stored on the server side and not send with the data (instead just its subject protected by the signature) ? MW: Irrelevant to the security of the scheme. Simpler from a development and operations standpoint. But using something like PGP/GPG or S/MIME would be simpler yet. There are any number of examples online for signing a file and verifying its signature. Thanks alot, Marco X509_verify_cert X509_verify_cert Click herehttps://www.mailcontrol.com/sr/SMsSvn1riRfGX2PQPOmvUsrLibhXE7+S86glxWVUEjKk!XLlG9uNumpG1wkqEL+kqdX9II!hjWj1JTd!1uc+!w== to report this email as spam. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] beginner needs advice on data signature/verification
Hi, I hope some of you could give me advice on my project using openssl. Lets say I have a server/service on a machine processing a file a corresponding client sends. That file is usually created by me on a clean third machine. The server side is assumed to be uncompromised (no hacker). The client side may be compromised. Now I need to make sure that the service only accepts those files that are created by me. I believe that is a very common requirement and has been done alot of times - I just can't find tutorials on how to implement it. Know any ? Lets assume I have an x509 cert together with its private key signed by a ca owned by me. The trusted ca cert will be present on the server side. This is what I plan to do: 1.) Create the data files/blobs and sign them using the priv key of the cert. Distribute the cert and the signature along with (or inside) the data file. 2.) Have the client send that data file to the server (cert/sig first) 3.) Service receives the cert, builds a cert store with the local ca cert in it and verifies the client's cert with X509_verify_cert() 4.) if cert verifies ok, service compares the signature against the one calculated from the incoming data using the public key that came inside the cert just verified Would this be the right approach considering that anything the client sends may be forged (cert, sig, data...) ? Or would it be safer to have the cert used for signing stored on the server side and not send with the data (instead just its subject protected by the signature) ? Thanks alot, Marco X509_verify_cert X509_verify_cert ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: openssl 1.0.1e Signature verification problems
Hi Steve, I have compiled openssl with -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS options. My kernel is OCF enabled. Below is the output of the command openssl asn1parse -genstr OID:sha1WithRSAEncryption # openssl asn1parse -genstr OID:sha1WithRSAEncryption 0:d=0 hl=2 l= 9 prim: OBJECT :sha1WithRSAEncryption Thanks, Anand - Original Message - From: Dr. Stephen Henson st...@openssl.org To: openssl-users@openssl.org Cc: Sent: Thursday, June 20, 2013 4:52 PM Subject: Re: openssl 1.0.1e Signature verification problems On Thu, Jun 20, 2013, anand rao wrote: The output of command openssl asn1parse -i -in cacert.pem is 0:d=0 hl=4 l= 872 cons: SEQUENCE 4:d=1 hl=4 l= 729 cons: SEQUENCE 8:d=2 hl=2 l= 3 cons: cont [ 0 ] 10:d=3 hl=2 l= 1 prim: INTEGER :02 13:d=2 hl=2 l= 9 prim: INTEGER :D46F3D4EDCA8F780 24:d=2 hl=2 l= 5 cons: SEQUENCE 26:d=3 hl=2 l= 1 prim: OBJECT :itu-t 29:d=3 hl=2 l= 0 prim: NULL That looks rather broken. Is this an unmodified version of OpenSSL? What happens if you do: openssl asn1parse -genstr OID:sha1WithRSAEncryption Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: openssl 1.0.1e Signature verification problems
prim: OBJECT :itu-t 742:d=2 hl=2 l= 0 prim: NULL 744:d=1 hl=3 l= 129 prim: BIT STRING Thanks, Anand - Original Message - From: Wim Lewis w...@omnigroup.com To: openssl-users@openssl.org Cc: Sent: Tuesday, June 18, 2013 11:33 PM Subject: Re: openssl 1.0.1e Signature verification problems On 14 Jun 2013, at 6:09 AM, anand rao wrote: I am using openssl 1.0.1e to create a CA and generate certificates. I am facing an issue while generating the device certificates. After creating the ca certificate using below command # openssl req -x509 -new -newkey rsa:1024 -keyout private/cakey.pem -days 3650 -out cacert.pem when we try to display the contents the signature algorithm is shown as itu-t instead of sha1WithRSAEncryption #openssl x509 -in cacert.pem -noout -text Certificate: [...] Signature Algorithm: itu-t That certainly looks wrong to me. What do you get if you run openssl asn1parse -i -in cacert.pem ? __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: openssl 1.0.1e Signature verification problems
On Thu, Jun 20, 2013, anand rao wrote: The output of command openssl asn1parse -i -in cacert.pem is 0:d=0 hl=4 l= 872 cons: SEQUENCE 4:d=1 hl=4 l= 729 cons: SEQUENCE 8:d=2 hl=2 l= 3 cons: cont [ 0 ] 10:d=3 hl=2 l= 1 prim: INTEGER :02 13:d=2 hl=2 l= 9 prim: INTEGER :D46F3D4EDCA8F780 24:d=2 hl=2 l= 5 cons: SEQUENCE 26:d=3 hl=2 l= 1 prim: OBJECT :itu-t 29:d=3 hl=2 l= 0 prim: NULL That looks rather broken. Is this an unmodified version of OpenSSL? What happens if you do: openssl asn1parse -genstr OID:sha1WithRSAEncryption Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: openssl 1.0.1e Signature verification problems
On 14 Jun 2013, at 6:09 AM, anand rao wrote: I am using openssl 1.0.1e to create a CA and generate certificates. I am facing an issue while generating the device certificates. After creating the ca certificate using below command # openssl req -x509 -new -newkey rsa:1024 -keyout private/cakey.pem -days 3650 -out cacert.pem when we try to display the contents the signature algorithm is shown as itu-t instead of sha1WithRSAEncryption #openssl x509 -in cacert.pem -noout -text Certificate: [...] Signature Algorithm: itu-t That certainly looks wrong to me. What do you get if you run openssl asn1parse -i -in cacert.pem ? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
openssl 1.0.1e Signature verification problems
Hi, I am using openssl 1.0.1e to create a CA and generate certificates. I am facing an issue while generating the device certificates. After creating the ca certificate using below command # openssl req -x509 -new -newkey rsa:1024 -keyout private/cakey.pem -days 3650 -out cacert.pem when we try to display the contents the signature algorithm is shown as itu-t instead of sha1WithRSAEncryption #openssl x509 -in cacert.pem -noout -text Certificate: Data: Version: 3 (0x2) Serial Number: 96:15:a3:26:59:5f:46:1d Signature Algorithm: itu-t Issuer: C=US, ST=LA, L=CA, O=Internet Widgits Pty Ltd, OU=crop, CN=GWCA/subjectAltName=DNS:www.evmweb.com Validity Not Before: Jun 14 12:08:24 2013 GMT Not After : Jun 12 12:08:24 2023 GMT Subject: C=US, ST=LA, L=CA, O=Internet Widgits Pty Ltd, OU=crop, CN=GWCA/subjectAltName=DNS:www.evmweb.com Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (1024 bit) Modulus: 00:c1:73:b4:37:ed:d1:1f:fb:bf:63:b0:8a:91:82: a8:f0:83:4d:5a:32:9b:5d:bc:23:06:3f:d4:fc:77: cf:83:0f:ab:ac:35:46:98:02:e5:a3:cc:89:30:34: 05:3f:80:ad:33:ae:dc:7e:57:60:e2:02:d6:c9:6b: b8:76:f7:56:e6:0f:44:c4:71:3a:cf:e1:59:8e:b4: 4b:6a:4a:de:59:25:4d:58:74:f0:82:27:0e:35:34: 72:86:9e:7c:a3:c8:cb:ba:55:8f:d5:8f:2f:cd:a0: 1f:e8:89:7c:74:0e:92:a0:de:72:d1:33:96:41:42: bc:44:d0:20:29:cf:7b:2c:a7 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Key Identifier: C3:92:EF:07:DE:25:21:48:F4:51:2B:38:C8:DE:56:D0:14:8E:CD:0A X509v3 Authority Key Identifier: keyid:C3:92:EF:07:DE:25:21:48:F4:51:2B:38:C8:DE:56:D0:14:8E:CD:0A DirName:/C=US/ST=LA/L=CA/O=Internet Widgits Pty Ltd/OU=crop/CN=GWCA/subjectAltName=DNS:www.evmweb.com serial:96:15:A3:26:59:5F:46:1D X509v3 Basic Constraints: CA:TRUE Signature Algorithm: itu-t a0:0e:98:f2:46:4e:0e:b5:d9:ff:f2:e5:57:24:d2:81:66:2e: 4a:2b:3c:f6:02:48:4a:37:d8:4d:d9:70:b2:01:43:f4:71:fc: 92:27:a9:d0:0b:9f:1a:c2:b7:54:3e:67:f3:0e:71:76:15:c0: c2:0f:b7:3a:13:de:93:4e:42:27:f9:5a:bb:d9:9e:e8:19:55: 88:7e:4b:d6:3a:b7:2d:46:3f:79:13:f4:c7:da:59:37:95:ef: 15:47:91:2a:32:4d:0d:ba:6f:a6:13:c3:57:87:ac:70:53:98: 41:11:8d:ee:af:3d:46:d1:48:bb:f7:de:5d:00:a4:f1:59:c2: 0c:56 when we try to sign a device certificate I am getting below error. # openssl ca -policy policy_anything -out certs/evm1gwcert.pem -infiles evm1gwCSR.pem Using configuration from /etc/ssl/openssl.cnf Enter pass phrase for /etc/ssl/private/cakey.pem: Check that the request matches the signature Signature verification problems.. This was not observed in previous versions. When I tried to change default_md to sha1 in openssl.cnf it doesn't had any effect. Please suggest if we need to configure anything in particular in openssl.cnf or is it a bug. Thanks, Anand __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
openssl-1.0.1e RSA signature verification fails
Hi Openssl developers, In our product we are using openssl source to some of the security development. In our old product we were using openssl-0.9.8l and the product is now in market. In our new product we upgraded our source base with openssl-1.0.1e, we didnt change any thing in our application but the RSA signature verification is failing when I comment the following portion of code in p_verify.c file, it started working, May I have to clue what should be set in our application to solve the issue with our modifying the openssl code. if (ctx-digest-flags EVP_MD_FLAG_PKEY_METHOD_SIGNATURE) { i = -1; pkctx = EVP_PKEY_CTX_new(pkey, NULL); if (!pkctx) goto err; if (EVP_PKEY_verify_init(pkctx) = 0) goto err; if (EVP_PKEY_CTX_set_signature_md(pkctx, ctx-digest) = 0) goto err; i = EVP_PKEY_verify(pkctx, sigbuf, siglen, m, m_len); err: EVP_PKEY_CTX_free(pkctx); return i; } In the above mention code is commented now, in result RSA_Signature verification is passing now. In this portion of code EVP_PKEY_CTX_new - int_ctx_new -EVP_PKEY_meth_find -OBJ_bsearch_pmeth is the failure path. OBJ_bsearch_pmeth returns zero,(openssl error is unsupported algorithms) but OpenSSL_add_all_algorithms is already called in our application. To add to this when I debugged type value received in EVP_PKEY_meth_find seems high value 1179403647(in decimal), this is derived from the pkey-ameth-pkey_id where as we dont set this value in our application. In our application do we need to set something to avoid the failure. Thanks in Advance. Thanks, Lavanya -- View this message in context: http://openssl.6102.n7.nabble.com/openssl-1-0-1e-RSA-signature-verification-fails-tp45250.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Openssl - Bouncy Castle : Signature Verification Failure
From: owner-openssl-us...@openssl.org On Behalf Of dwipin Sent: Thursday, 22 November, 2012 23:20 I am trying to develop a java utility based on Bouncy Castle that should be able to sign and encrypt data which can later be decrypted and verified on the server side (openssl). Data encrypted by BC gets decrypted fine with Openssl Data signed by BC gets verified fine with Openssl But when I sign and encrypt data with BC ... it decrypts fine. However the output of this decryption when I try to verify, it fails. I then opened the output of decryption, removed the first 3 lines from it. These lines were the 2 Headers and a blank line. After this the verification also went thru fine. So I am not sure how to avoid these extra headers that gets passed as input to openssl verification. My decrypt and verify is something like this - openssl smime -decrypt -in $1 -recip $2 -inkey $3 | openssl smime -verify -CAfile $4 -out $5 These were the extra lines I deleted - Content-Type: application/octet-stream Content-Transfer-Encoding: binary A blank line Those are standard MIME (part) headers and SMIME uses MIME headers, although c-type octet-stream isn't as informative as it could be. But if those headers are accurate for the related data you should need -inform der on the smime -verify. Even if those headers are inaccurate you should need -inform pem after stripping, because the default is -inform smime which *requires* the headers. Does your decryption output look like MIME+base64, MIME+binary, or what? Also, what openssl version are you using? I don't think the defaults have changed, but I might be mistaken. If you want plain CMS and not SMIME, BC may well have an option for that, but I don't have time at the moment to look for it. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Openssl - Bouncy Castle : Signature Verification Failure
I am trying to develop a java utility based on Bouncy Castle that should be able to sign and encrypt data which can later be decrypted and verified on the server side (openssl). Data encrypted by BC gets decrypted fine with Openssl Data signed by BC gets verified fine with Openssl But when I sign and encrypt data with BC and use OpenSSL to decrypt and verify, it fails. But if I only decrypt this content, it decrypts fine. However the output of this decryption when I try to verify, it fails. I then opened the output of decryption, removed the first 3 lines from it. These lines were the 2 Headers and a blank line. After this the verification also went thru fine. So I am not sure how to avoid these extra headers that gets passed as input to openssl verification. My decrypt and verify is something like this - openssl smime -decrypt -in $1 -recip $2 -inkey $3 | openssl smime -verify -CAfile $4 -out $5 These were the extra lines I deleted - Content-Type: application/octet-stream Content-Transfer-Encoding: binary A blank line Anyone know of a solution, please let me know. Thanks, Dwipin. -- View this message in context: http://openssl.6102.n7.nabble.com/Openssl-Bouncy-Castle-Signature-Verification-Failure-tp42468.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Openssl - Bouncy Castle : Signature Verification Failure
Its not exactly Signature Verification Failure. I get the following error - Error reading S/MIME message 24746:error:2107A083:PKCS7 routines:SMIME_read_PKCS7:invalid mime type:pk7_mime.c:364:type: application/octet-stream -- View this message in context: http://openssl.6102.n7.nabble.com/Openssl-Bouncy-Castle-Signature-Verification-Failure-tp42468p42469.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Effect of EC_GROUP_precompute_mult when doing signature verification (ECDSA_verify)
Hello list I became aware of EC_GROUP_precompute_mult when I had to generate a lot of public keys fast. It speeds up this process by about a factor of 5. So it's been very useful for me. I've been researching if EC_GROUP_precompute_mult has any effect when verifying ECDSA signatures using ECDSA_verify, and my results are somewhat inconclusive. I see a small speedup, around 2-5%, but I'm not sure what the reason is for this. I can see the code that verifies signatures uses EC_POINT_mul, but I don't see a significant speedup as I did when using it to just generate public keys (q and m set to NULL in EC_POINT_mul). I can see that in the OpenSSL signature verification code q and m are not NULL in EC_POINT_mul, so it makes sense why the speedup wouldn't be as great as when they are NULL (since precomputations are only made for the generator point of the curve). But I don't understand why the speedup becomes so small when q and m are set, as I still did see a 5x speedup (from roughly 1000 us per execution of EC_POINT_mul to roughly 200 us) when q and m are NULL. Should there, in theory, be any reason for EC_GROUP_precompute_mult to speed up signature verification? Thanks! /Rune __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Effect of EC_GROUP_precompute_mult when doing signature verification (ECDSA_verify)
On Tue, Oct 9, 2012 at 12:29 PM, Rune K. Svendsen runesv...@gmail.comwrote: I've been researching if EC_GROUP_precompute_mult has any effect when verifying ECDSA signatures using ECDSA_verify, and my results are somewhat inconclusive. I see a small speedup, around 2-5%, but I'm not sure what the reason is for this. I can see the code that verifies signatures uses EC_POINT_mul, but I don't see a significant speedup as I did when using it to just generate public keys (q and m set to NULL in EC_POINT_mul). I can see that in the OpenSSL signature verification code q and m are not NULL in EC_POINT_mul, so it makes sense why the speedup wouldn't be as great as when they are NULL (since precomputations are only made for the generator point of the curve). But I don't understand why the speedup becomes so small when q and m are set, as I still did see a 5x speedup (from roughly 1000 us per execution of EC_POINT_mul to roughly 200 us) when q and m are NULL. EC_GROUP_precompute_mult precomputation is based only on common group parameters, not on the specific key. It would be possible to speed up ECDSA verification similarly by doing something like that on a per-key level, but it would only help if you verify multiple signatures signed by the same key. That's why it is currently not supported by the OpenSSL API -- it would be a bit cumbersome to use properly. Bodo
openssl Signature Verification Failure : “RSA_padding_check_PKCS1_type_1:block type is not 01”
I am trying to verify the signature of a sample downloaded from NIST . But I am getting the following output: retval=0 err='error:0407006A:lib(4):func(112):reason(106)' When I collected the detailed description I found: openssl errstr 0407006A error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01 The signature verification is expected to pass as per the data input I have provided. Something might be wrong in my code. Any help is appreciated. The data and the example code that I used is , in http://stackoverflow.com/q/10927586/986020 thanks for help
Re: openssl Signature Verification Failure : “RSA_padding_check_PKCS1_type_1:block type is not 01”
Here is the vector and code that is provided in the link: /* VECTOR SOURCE: csrc.nist.gov/groups/STM/cavp/documents/dss/RSAVS.pdf B.1.3 SigVerRSA.req., it's Result = P as per B.3.3 SigVerRSA.rsp # CAVS 3.2 # SigVer RSA (X9.31) information for testshas # Mod sizes selected: 1024 1536 # SHA Algorithm selected:SHA1 SHA256 SHA384 SHA512 # Generated on Wed Apr 28 08:35:11 2004 [mod = 1024] n = 9ec4d483330916b69eee4e9b7614eafc4fbf60e74b5127a3ff5bd9d48c7ecf8418d94d1e60388bb68546f8bc92deb1974b9def6748fbb4ec93029ea8b7bea36f61c5c6aeedfd512a0f765846fad5edacb08c3d75cf1d43b48b394c94323c3f3e9ba6612f93fe2900134217433afb088b5ca33fc4e6b270194df077d2b6592743 SHAAlg = SHA1 e = 0003 Msg = b915e774b083e8cec80929cfbc89d87bd046f65cb43e5e78acba0380ee23794a4b17b78112bc1b9c3254ae0c9e12aabaf62c39b063328016c39edc6106ac6bc7d76ccff67f152e05079c7dab9d85ffaf3afa089f811a07c5e993c3571e73e5eea53bb739bf352bf391081f12818adf42e3d5ec91d59dfc6c67c141ca001feea7 S = 1c886e8041a0bfa57320c2033ac37eb2f8d8a96d42f3187b0f9164f37a0ce270ba35602a1e27c96fb6e2fdcfb25b00da1cceeb146f6a3320de97594d6de8664d3055142d408fc28c47dd380847d92450fad37535d366aabced070cc1fff6a6e023e2ce64e9e1914e82f384688c63beada87dd0ab7117b5d4c1129e39b40d2440 */ int verfiysignature (void) { int retval; EVP_PKEYpkey; EVP_MD_CTX ctx; RSA *rsa; chartestbuffer[512]; unsigned char testN[128] = {0x9e,0xc4,0xd4,0x83,0x33,0x09,0x16,0xb6,0x9e,0xee,0x4e,0x9b,0x76,0x14,0xea,0xfc,0x4f,0xbf,0x60,0xe7,0x4b,0x51,0x27,0xa3,0xff,0x5b,0xd9,0xd4,0x8c,0x7e,0xcf,0x84,0x18,0xd9,0x4d,0x1e,0x60,0x38,0x8b,0xb6,0x85,0x46,0xf8,0xbc,0x92,0xde,0xb1,0x97,0x4b,0x9d,0xef,0x67,0x48,0xfb,0xb4,0xec,0x93,0x02,0x9e,0xa8,0xb7,0xbe,0xa3,0x6f,0x61,0xc5,0xc6,0xae,0xed,0xfd,0x51,0x2a,0x0f,0x76,0x58,0x46,0xfa,0xd5,0xed,0xac,0xb0,0x8c,0x3d,0x75,0xcf,0x1d,0x43,0xb4,0x8b,0x39,0x4c,0x94,0x32,0x3c,0x3f,0x3e,0x9b,0xa6,0x61,0x2f,0x93,0xfe,0x29,0x00,0x13,0x42,0x17,0x43,0x3a,0xfb,0x08,0x8b,0x5c,0xa3,0x3f,0xc4,0xe6,0xb2,0x70,0x19,0x4d,0xf0,0x77,0xd2,0xb6,0x59,0x27,0x43}; unsigned char testE[1] = {0x03}; unsigned char testMsg[128] = {0xb9,0x15,0xe7,0x74,0xb0,0x83,0xe8,0xce,0xc8,0x09,0x29,0xcf,0xbc,0x89,0xd8,0x7b,0xd0,0x46,0xf6,0x5c,0xb4,0x3e,0x5e,0x78,0xac,0xba,0x03,0x80,0xee,0x23,0x79,0x4a,0x4b,0x17,0xb7,0x81,0x12,0xbc,0x1b,0x9c,0x32,0x54,0xae,0x0c,0x9e,0x12,0xaa,0xba,0xf6,0x2c,0x39,0xb0,0x63,0x32,0x80,0x16,0xc3,0x9e,0xdc,0x61,0x06,0xac,0x6b,0xc7,0xd7,0x6c,0xcf,0xf6,0x7f,0x15,0x2e,0x05,0x07,0x9c,0x7d,0xab,0x9d,0x85,0xff,0xaf,0x3a,0xfa,0x08,0x9f,0x81,0x1a,0x07,0xc5,0xe9,0x93,0xc3,0x57,0x1e,0x73,0xe5,0xee,0xa5,0x3b,0xb7,0x39,0xbf,0x35,0x2b,0xf3,0x91,0x08,0x1f,0x12,0x81,0x8a,0xdf,0x42,0xe3,0xd5,0xec,0x91,0xd5,0x9d,0xfc,0x6c,0x67,0xc1,0x41,0xca,0x00,0x1f,0xee,0xa7}; unsigned char testSig[128] = {0x1c,0x88,0x6e,0x80,0x41,0xa0,0xbf,0xa5,0x73,0x20,0xc2,0x03,0x3a,0xc3,0x7e,0xb2,0xf8,0xd8,0xa9,0x6d,0x42,0xf3,0x18,0x7b,0x0f,0x91,0x64,0xf3,0x7a,0x0c,0xe2,0x70,0xba,0x35,0x60,0x2a,0x1e,0x27,0xc9,0x6f,0xb6,0xe2,0xfd,0xcf,0xb2,0x5b,0x00,0xda,0x1c,0xce,0xeb,0x14,0x6f,0x6a,0x33,0x20,0xde,0x97,0x59,0x4d,0x6d,0xe8,0x66,0x4d,0x30,0x55,0x14,0x2d,0x40,0x8f,0xc2,0x8c,0x47,0xdd,0x38,0x08,0x47,0xd9,0x24,0x50,0xfa,0xd3,0x75,0x35,0xd3,0x66,0xaa,0xbc,0xed,0x07,0x0c,0xc1,0xff,0xf6,0xa6,0xe0,0x23,0xe2,0xce,0x64,0xe9,0xe1,0x91,0x4e,0x82,0xf3,0x84,0x68,0x8c,0x63,0xbe,0xad,0xa8,0x7d,0xd0,0xab,0x71,0x17,0xb5,0xd4,0xc1,0x12,0x9e,0x39,0xb4,0x0d,0x24,0x40}; rsa = RSA_new(); rsa-n = BN_bin2bn(testN, 128, rsa-n); rsa-e = BN_bin2bn(testE, 1, rsa-e); rsa-d = 0; rsa-p = 0; rsa-q = 0; pkey.type = EVP_PKEY_RSA; pkey.pkey.rsa = rsa; EVP_MD_CTX_init (ctx); ctx.flags |= EVP_MD_CTX_FLAG_PAD_X931; if (EVP_VerifyInit_ex (ctx, EVP_sha1(), NULL)) { if (EVP_VerifyUpdate (ctx, testMsg, 128)) { retval = EVP_VerifyFinal (ctx, testSig, 128, pkey); memset(testbuffer,0,sizeof(testbuffer)); printf(retval=%d err='%s', retval, ERR_error_string(ERR_get_error(), testbuffer)); } else { retval = -1; } } else { retval = -1; } EVP_MD_CTX_cleanup (ctx); RSA_free (rsa); return retval; } On Thu, Jun 7, 2012 at 1:58 PM, Lunar Mushrooms lunar.mushro...@gmail.comwrote: I am trying to verify the signature of a sample downloaded from NIST . But I am getting the following output: retval=0 err='error:0407006A:lib(4):func(112):reason(106)' When I collected the detailed description I found: openssl errstr 0407006A error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01 The signature verification is expected to pass as per the data input I
Re: openssl Signature Verification Failure : “RSA_padding_check_PKCS1_type_1:block type is not 01”
I typically divide the problem in two. Do a raw public key operation. If you see something that looks random, then the public key doesn't match the private key used to generate the signature, or either the public key or signature has been altered. If it looks like padding + OID + hash, then either the padding or digest you expect is wrong. On 6/7/2012 4:28 AM, Lunar Mushrooms wrote: I am trying to verify the signature of a sample downloaded from NIST . But I am getting the following output: retval=0 err='error:0407006A:lib(4):func(112):reason(106)' When I collected the detailed description I found: |openssl errstr 0407006A error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01 | The signature verification is expected to pass as per the data input I have provided. Something might be wrong in my code. Any help is appreciated. The data and the example code that I used is , in http://stackoverflow.com/q/10927586/986020 thanks for help __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Problem with signature verification on microchip embedded controller
Yes, you can verify 'by hand' by doing the raw public key operation, stripping off the padding and OID (what you call the asn1 formatting), and then comparing the hashes. When you say this is what I got from the PIC controller, I assume you mean the result of applying the public key to the signature. Since you don't see the obvious 00 01 ff ... padding, there are three possibilities: - you're using the wrong public key, or it got altered, or it's in the wrong format for the crypto library - you're using the wrong signature, or it got altered - the raw public key operation isn't working correctly, or you called it incorrectly It's not a hashing issue, since you don't see the padding. From: TSCOconan chu...@tsco.ca To: openssl-users@openssl.org, Date: 10/18/2011 03:03 PM Subject: Problem with signature verification on microchip embedded controller Sent by: owner-openssl-us...@openssl.org Hi, I'm trying to implement certificate signature verification (certificates are generated and signed using OpenSSL) on a Microchip pic controller. The Microchip PIC controller doesn't support OpenSSL libraries, but it does have an encryption/decryption function. I was successful in getting a SSL connection between PIC controller and a web server. My next step is to setup signature verification on the PIC controller. After reading PKCS#1 V2.1 RSA Cryptography Standard (http://www.rsa.com/rsalabs/node.asp?id=2125) I realized that encryption is essentially the same as signature verification and decryption is the same as signing. More specifically both encryption and verification uses the public key and the following formula: m = s^e mod n. Where s is the signature or the message, e is the public exponent, n is the modulus and m is the encrypted message or decoded signature. Therefore, I'm trying to use the encryption algorithm provided to perform signature verification. In order to verify the certificate, I generate the SHA1 hash of the certificate; Decode signature using CA's public key and encryption algorithm. Remove the padding from the decoded signature, the result hash should be equal to the SHA1 hash of the certificate. However, I cannot get the two hash values to be equal. I tried to verify my assumption and PIC controller results using OpenSSL command line. openssl rsautl -in signature.txt -verify -asn1parse -inkey pubkey.pem -pubin db e8 c6 cb 78 19 3c 0f-fd 96 1c 4f ed bd b2 34 45 60 bf 65 this matches the hash value I'm getting from PIC controller openssl rsautl -verify -in signature.txt -inkey pubkey.pem -pubin -raw -hexdump 00 01 ff ff ff ff ff ff-ff ff ff ff 00 30 21 30 09 06 05 2b 0e 03 02 1a-05 00 04 14 db e8 c6 cb 78 19 3c 0f fd 96 1c 4f-ed bd b2 34 45 60 bf 65 I believe this is what I should get after decoding the signature. After removing ff paddings I'll end up with asn1 format of the certificate hash. However this is what I got from the PIC controller which is much different 8e fb 62 0e 09 c8 0b 49 40 1f 4d 2d a7 7d d6 8c 9b bc 95 e6 bc 98 4b 96 aa 74 e5 68 90 40 bf 43 b5 c5 02 6d ab e3 ad 7b e6 98 fd 10 22 af b9 fb This is my signature 7951 9b3d 244a 37f6 86d7 dc02 dc18 3bb4 0f66 db3a a3c1 a254 5be5 11d3 a691 63ef 0cf2 ec59 c48b 25ad 8881 9ed2 5230 bcd6 This is my public key (I'm using a very small key just for testing, will make it larger once everything works) 96 FE CB 59 37 AE 8C 9C 6C 7A 01 50 0F D6 4F B4 E2 EC 45 D1 88 4E 1F 2D B7 1E 4B AD 76 4D 1F F1 B0 CD 09 6F E5 B7 43 CA F8 14 FE 31 B2 06 F8 7B Exponent is 01 00 01 I'm wondering are my assumptions wrong that I cannot use encryption algorithm for decoding signature? or I'm doing something else wrong. Thank you for any help.
Problem with signature verification on microchip embedded controller
Hi, I'm trying to implement certificate signature verification (certificates are generated and signed using OpenSSL) on a Microchip pic controller. The Microchip PIC controller doesn't support OpenSSL libraries, but it does have an encryption/decryption function. I was successful in getting a SSL connection between PIC controller and a web server. My next step is to setup signature verification on the PIC controller. After reading PKCS#1 V2.1 RSA Cryptography Standard (http://www.rsa.com/rsalabs/node.asp?id=2125) I realized that encryption is essentially the same as signature verification and decryption is the same as signing. More specifically both encryption and verification uses the public key and the following formula: m = s^e mod n. Where s is the signature or the message, e is the public exponent, n is the modulus and m is the encrypted message or decoded signature. Therefore, I'm trying to use the encryption algorithm provided to perform signature verification. In order to verify the certificate, I generate the SHA1 hash of the certificate; Decode signature using CA's public key and encryption algorithm. Remove the padding from the decoded signature, the result hash should be equal to the SHA1 hash of the certificate. However, I cannot get the two hash values to be equal. I tried to verify my assumption and PIC controller results using OpenSSL command line. openssl rsautl -in signature.txt -verify -asn1parse -inkey pubkey.pem -pubin db e8 c6 cb 78 19 3c 0f-fd 96 1c 4f ed bd b2 34 45 60 bf 65 this matches the hash value I'm getting from PIC controller openssl rsautl -verify -in signature.txt -inkey pubkey.pem -pubin -raw -hexdump 00 01 ff ff ff ff ff ff-ff ff ff ff 00 30 21 30 09 06 05 2b 0e 03 02 1a-05 00 04 14 db e8 c6 cb 78 19 3c 0f fd 96 1c 4f-ed bd b2 34 45 60 bf 65 I believe this is what I should get after decoding the signature. After removing ff paddings I'll end up with asn1 format of the certificate hash. However this is what I got from the PIC controller which is much different 8e fb 62 0e 09 c8 0b 49 40 1f 4d 2d a7 7d d6 8c 9b bc 95 e6 bc 98 4b 96 aa 74 e5 68 90 40 bf 43 b5 c5 02 6d ab e3 ad 7b e6 98 fd 10 22 af b9 fb This is my signature 7951 9b3d 244a 37f6 86d7 dc02 dc18 3bb4 0f66 db3a a3c1 a254 5be5 11d3 a691 63ef 0cf2 ec59 c48b 25ad 8881 9ed2 5230 bcd6 This is my public key (I'm using a very small key just for testing, will make it larger once everything works) 96 FE CB 59 37 AE 8C 9C 6C 7A 01 50 0F D6 4F B4 E2 EC 45 D1 88 4E 1F 2D B7 1E 4B AD 76 4D 1F F1 B0 CD 09 6F E5 B7 43 CA F8 14 FE 31 B2 06 F8 7B Exponent is 01 00 01 I'm wondering are my assumptions wrong that I cannot use encryption algorithm for decoding signature? or I'm doing something else wrong. Thank you for any help. Conan -- View this message in context: http://old.nabble.com/Problem-with-signature-verification-on-microchip-embedded-controller-tp32677043p32677043.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Problem with signature verification on microchip embedded controller
From: owner-openssl-us...@openssl.org On Behalf Of TSCOconan Sent: Tuesday, 18 October, 2011 14:57 I'm trying to implement certificate signature verification snip on a Microchip pic controller. snip After reading PKCS#1 V2.1 snip I realized that encryption is essentially the same as signature verification and decryption is the same as signing. snip Therefore, I'm trying to use the encryption algorithm provided to perform signature verification. Raw RSA encrypt/decrypt are the same as verify/sign, but the standard paddings are different. (PKCS#1 type2 padding for encrypt is similar to type1 padding for sign but not identical, and it proved vulnerable in application so it was mostly superseded by OAEP which is very different. And encrypt is pad-then-modexp-pub while verify is modexp-pub-then-unpad.) In order to verify the certificate, snip usual openssl rsautl -verify -in signature.txt -inkey pubkey.pem -pubin -raw -hexdump 00 01 ff ff ff ff ff ff-ff ff ff ff 00 30 21 30 09 06 05 2b 0e 03 02 1a-05 00 04 14 db e8 c6 cb 78 19 3c 0f fd 96 1c 4f-ed bd b2 34 45 60 bf 65 I believe this is what I should get after decoding the signature. After removing ff paddings I'll end up with asn1 format of the certificate hash. Yes. (To be exact, removing type 01, at least 8 IIRC FF's, and delimiter 00; those are all part of the padding.) However this is what I got from the PIC controller which is much different 8e fb 62 0e 09 c8 0b 49 40 1f 4d 2d a7 7d d6 8c 9b bc 95 e6 bc 98 4b 96 aa 74 e5 68 90 40 bf 43 b5 c5 02 6d ab e3 ad 7b e6 98 fd 10 22 af b9 fb I'm not sure what that encryption primitive is doing. Does it take any kind of setting to do padding or not? If it is doing any real padding it should reject your call because no padding scheme can encrypt a 384-bit (or even 376-bit) value with a 384-bit key. Maybe it is failing to return the error or you are failing to recognize it. If it is supposed to be doing unpadded something is wrong. snip data This is my public key (I'm using a very small key just for testing, will make it larger once everything works) I suggest you use a key large enough to give OAEP some elbow room, at least 512. Then try encrypting several known short values like 01; 01 02; 01 02 03; etc. and see if rsautl -decrypt -raw or -oaep gives them back. (Or maybe -pkcs, but as noted that is rare these days.) Increase up to the length you need (about 48 bytes). If you can get raw-encrypt to match, you can use it for the modexp-pub part of verify. (And the rest is, as you correctly described, relatively simple.) __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Java signature verification fail in openssl
My steps are 1. raw data eg.balamurugan 2. i am calculating hash for this data using sha256 which is 256 bit for readable i convert this into (32 to 64 byte) hex string not hex represent. eg hash string is a123sdf... which is 64 characters 3. now i am giving this 64 character string into the RSA_sign() function with 2048 RSA Private key. and input is a123sdf...(64 characters). NID_sha1() 4. the output is 256 character (binary) which i encode into base 64... Verification: 1. decode the Base64 code 2. calculate hash for raw data using sha256 which result in 64 character eg.(a123sdf. 3.Calling RSA-verify() with inputs hash string (a123sdf... 64 character) ,NID_sha1(),RSA public Key, are my steps are right if not in which place i am doing wrong ..? m data :a12df146d87db3ce911e61444eed322bbd027a58cfa27ceec3626317ebe62f89 sig-digest-data :?*?H?b9???A6w?(? Memcompare fail mLen :64sig-digest-length :20 Assuming 'mLen' is the m_length/m_len passed to RSA_verify, it appears your digest-to-compare is 64 hex chars (32 bytes) while the digest specified by the signer is 20 bytes. It looks like you are computing the wrong hash, maybe SHA256 instead of SHA1, and also representing it wrongly. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org -- View this message in context: http://old.nabble.com/Java-signature-verification-fail-in-openssl-tp32589928p32594391.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Java signature verification fail in openssl
Jeffrey Walton-3 wrote: On Tue, Oct 4, 2011 at 10:58 AM, brajan balamurugan@gmail.com wrote: hi can any one tell me why the signature verification in openssl fail when the message is signed bu java IBM fips compliant.i am using openssl 0.9.8g in power Pc. i am getting error in if (((unsigned int)sig-digest-length != m_len) || (memcmp(m,sig-digest-data,m_len) != 0)) line of source code in RSA_verify(). the value are m data :a12df146d87db3ce911e61444eed322bbd027a58cfa27ceec3626317ebe62f89 sig-digest-data :�*�H�b9���A6w�(� Memcompare fail mLen :64 sig-digest-length :20 DSA? Java uses a DER encoded signature per RFC 3279: SEQUENCE ::= { r INTEGER, s INTEGER } Jeff Hi Jeff ,, i didnt get what u are asking as DSA ? . i am using SHA1WithRSA in java __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org -- View this message in context: http://old.nabble.com/Java-signature-verification-fail-in-openssl-tp32589928p32594404.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Java signature verification fail in openssl
Jakob Bohm-7 wrote: On 10/4/2011 4:58 PM, brajan wrote: hi can any one tell me why the signature verification in openssl fail when the message is signed bu java IBM fips compliant.i am using openssl 0.9.8g in power Pc. i am getting error in if (((unsigned int)sig-digest-length != m_len) || (memcmp(m,sig-digest-data,m_len) != 0)) line of source code in RSA_verify(). the value are m data :a12df146d87db3ce911e61444eed322bbd027a58cfa27ceec3626317ebe62f89 sig-digest-data :�*�H�b9���A6w�(� Memcompare fail mLen :64sig-digest-length :20 why this is happening.? whether is it due to d2i_X509_SIG() this function Was the signature made with a different hash algorithm than the one you try to use to verify it? While signing the message in JAVA they are using Sha1WithRSA ... so i used RSA_verify with NID_sha1(). __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org -- View this message in context: http://old.nabble.com/Java-signature-verification-fail-in-openssl-tp32589928p32594410.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Java signature verification fail in openssl
On 10/5/2011 8:15 AM, brajan wrote: My steps are 1. raw data eg.balamurugan 2. i am calculating hash for this data using sha256 which is 256 bit for readable i convert this into (32 to 64 byte) hex string not hex represent. eg hash string is a123sdf... which is 64 characters 3. now i am giving this 64 character string into the RSA_sign() function with 2048 RSA Private key. and input is a123sdf...(64 characters). NID_sha1() WRONG, If you hashed with SHA256, you need to pass NID_sha256() and the binary (not hex) SHA256 value. If you have to use NID_sha1(), pass in the binary output of SHA1 of something, not some raw message of any other form or contents. 4. the output is 256 character (binary) which i encode into base 64... Verification: 1. decode the Base64 code 2. calculate hash for raw data using sha256 which result in 64 character eg.(a123sdf. 3.Calling RSA-verify() with inputs hash string (a123sdf... 64 character) ,NID_sha1(),RSA public Key, Same mistake as in your other step 3. are my steps are right if not in which place i am doing wrong ..? m data :a12df146d87db3ce911e61444eed322bbd027a58cfa27ceec3626317ebe62f89 sig-digest-data :?*?H?b9???A6w?(? Memcompare fail mLen :64sig-digest-length :20 Assuming 'mLen' is the m_length/m_len passed to RSA_verify, it appears your digest-to-compare is 64 hex chars (32 bytes) while the digest specified by the signer is 20 bytes. It looks like you are computing the wrong hash, maybe SHA256 instead of SHA1, and also representing it wrongly. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Java signature verification fail in openssl
hi can any one tell me why the signature verification in openssl fail when the message is signed bu java IBM fips compliant.i am using openssl 0.9.8g in power Pc. i am getting error in if (((unsigned int)sig-digest-length != m_len) || (memcmp(m,sig-digest-data,m_len) != 0)) line of source code in RSA_verify(). the value are m data :a12df146d87db3ce911e61444eed322bbd027a58cfa27ceec3626317ebe62f89 sig-digest-data :�*�H�b9���A6w�(� Memcompare fail mLen :64sig-digest-length :20 why this is happening.? whether is it due to d2i_X509_SIG() this function -- View this message in context: http://old.nabble.com/Java-signature-verification-fail-in-openssl-tp32589928p32589928.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Java signature verification fail in openssl
On 10/4/2011 4:58 PM, brajan wrote: hi can any one tell me why the signature verification in openssl fail when the message is signed bu java IBM fips compliant.i am using openssl 0.9.8g in power Pc. i am getting error in if (((unsigned int)sig-digest-length != m_len) || (memcmp(m,sig-digest-data,m_len) != 0)) line of source code in RSA_verify(). the value are m data :a12df146d87db3ce911e61444eed322bbd027a58cfa27ceec3626317ebe62f89 sig-digest-data :�*�H�b9���A6w�(� Memcompare fail mLen :64sig-digest-length :20 why this is happening.? whether is it due to d2i_X509_SIG() this function Was the signature made with a different hash algorithm than the one you try to use to verify it? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Java signature verification fail in openssl
On Tue, Oct 4, 2011 at 10:58 AM, brajan balamurugan@gmail.com wrote: hi can any one tell me why the signature verification in openssl fail when the message is signed bu java IBM fips compliant.i am using openssl 0.9.8g in power Pc. i am getting error in if (((unsigned int)sig-digest-length != m_len) || (memcmp(m,sig-digest-data,m_len) != 0)) line of source code in RSA_verify(). the value are m data :a12df146d87db3ce911e61444eed322bbd027a58cfa27ceec3626317ebe62f89 sig-digest-data :�*�H�b9���A6w�(� Memcompare fail mLen :64 sig-digest-length :20 DSA? Java uses a DER encoded signature per RFC 3279: SEQUENCE ::= { r INTEGER, s INTEGER } Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Java signature verification fail in openssl
From: owner-openssl-us...@openssl.org On Behalf Of brajan Sent: Tuesday, 04 October, 2011 10:58 can any one tell me why the signature verification in openssl fail when the message is signed bu java IBM fips compliant.i am using openssl 0.9.8g in power Pc. i am getting error in if (((unsigned int)sig-digest-length != m_len) || (memcmp(m,sig-digest-data,m_len) != 0)) line of source code in RSA_verify(). the value are m data :a12df146d87db3ce911e61444eed322bbd027a58cfa27ceec3626317ebe62f89 sig-digest-data :?*?H?b9???A6w?(? Memcompare fail mLen :64sig-digest-length :20 Assuming 'mLen' is the m_length/m_len passed to RSA_verify, it appears your digest-to-compare is 64 hex chars (32 bytes) while the digest specified by the signer is 20 bytes. It looks like you are computing the wrong hash, maybe SHA256 instead of SHA1, and also representing it wrongly. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Error While Signature verification ..
hi i am using openssl 0.9.8g version to verify the Java signed message. while verifing i got bad signature error how ever the same signature is verified in the Java correctlu ... erro occur in if (((unsigned int)sig-digest-length != m_len) || (memcmp(m,sig-digest-data,m_len) != 0)) { RSAerr(RSA_F_RSA_VERIFY,RSA_R_BAD_SIGNATURE); } else ret=1; why this error occuring .and how to over come this error -- View this message in context: http://old.nabble.com/Error-While-Signature-verification-..-tp32503816p32503816.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Error While Signature verification ..
A failed signature verification can have many causes. E.g., - bad digest - bad signature - bad public key - bad OID I debug by doing a raw public key operation on the signature. If you see obvious padding and a good OID, and the digest doesn't match, then you have to debug why the hash that was signed is different from the hash that was verified. If you see random data, no padding, then either the signature was altered (unlikely) or the public key used for verification does not match the private key used for signing (likely). Hint: While you can do cool things with C, combining a function call and two compares within an if statement is poor style when you have to debug. Split the line into 3 so you can determine where the error is. owner-openssl-us...@openssl.org wrote on 09/22/2011 09:19:07 AM: From: brajan balamurugan@gmail.com To: openssl-users@openssl.org Date: 09/22/2011 09:22 AM Subject: Error While Signature verification .. Sent by: owner-openssl-us...@openssl.org hi i am using openssl 0.9.8g version to verify the Java signed message. while verifing i got bad signature error how ever the same signature is verified in the Java correctlu ... erro occur in if (((unsigned int)sig-digest-length != m_len) || (memcmp(m,sig-digest-data,m_len) != 0)) { RSAerr(RSA_F_RSA_VERIFY,RSA_R_BAD_SIGNATURE); } else ret=1; why this error occuring .and how to over come this error
Trust Chain Loading and signature verification of a certificate
hi i am having 10 Different CA Root certificates and each having depth of 3 intermediate Certificate in a Folder. i want to verify the Signature of the incoming certificate which P7b file which can have certificates need to validate (3 different certificates to validate) or one certificate need to validate with its intermediate CA. Intermediate certificates also can be in the P7b file but not the Root Certificate or Self Signed Certificates. pls can any one tell me how to load the Trust Chain and verify . i am not able to understand the X509_STORE and X509_STORE_CTX concepts. (i am using c++ ) Thanks Regards Balamurugan -- View this message in context: http://old.nabble.com/Trust-Chain-Loading-and-signature-verification-of-a-certificate-tp32088489p32088489.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Openssl signature verification of CKM_ECDSA_SHA1 from Safenet HSM fails.
Hi, I am trying to use OpenSSL to independently verify a CKM_ECDSA_SHA1 signature produced by a Safenet protect gold HSM. The signature verification with the error below, however using the HSM ctbrowse tool I can verify the signature being produced. Can anybody out there help me interpret what I'm getting back from the SafeNet device? Or any suggestions how I can validate it using OpenSSL without having a dependency on the HSM / libcryptoki etc? This is the error I am getting: gm@dev:~/hsm/help$ ./a.out Signature verification: ERROR - error:0D07207B:asn1 encoding routines:ASN1_get_object:header too long dumpasn1 doesn't seem to recognize the structure either: gm@dev:~/hsm/help$ dumpasn1 sig.dat Error: Invalid data encountered at position 2: E4 99. Hexdump of data: 0d0e0a0d0b0e0e0f Hexdump of signature (tool was run against raw format): e49938467bef558e63b25d8460ef753c51dfa3d277beecaeffb23f6c23deb6913de34391990c6150dea05472c91156026898477118b872ec2b26aa326799049c Demo verification source code: http://pastebin.com/PybRp0jq Certificate: -BEGIN CERTIFICATE- MIIBxTCCAXECAQEwCwYHKoZIzj0EAQUAMHExEjAQBgNVBAMTCWVjZHNhZGVtbzEQ MA4GA1UEChMHdGVzdG9yZzEUMBIGA1UECxMLdGVzdG9yZ3VuaXQxETAPBgNVBAcT CEJyaXNiYW5lMQwwCgYDVQQIEwNRbGQxEjAQBgNVBAYTCUF1c3RyYWxpYTAeFw0x MTA1MTEwNDIyNDVaFw0xMjA1MTAyMjIyNDVaMHExEjAQBgNVBAMTCWVjZHNhZGVt bzEQMA4GA1UEChMHdGVzdG9yZzEUMBIGA1UECxMLdGVzdG9yZ3VuaXQxETAPBgNV BAcTCEJyaXNiYW5lMQwwCgYDVQQIEwNRbGQxEjAQBgNVBAYTCUF1c3RyYWxpYTBZ MBMGByqGSM49AgEGCCqGSM49AwEHA0IABDHDFQ1VOjE4hgdBsE3Qb/BurxJdUMOi Cbzw6Hn5I916NDppDpkEbYy3NXD15KifAF0JIpNalK8Uc3//o8lrIzIwCwYHKoZI zj0EAQUAA0EAGajEF/eDt3qlwdG8Zv1+yhwkrgL44UHsY0JGLog8TWBrNFqg6Qu/ SD3lJJv9g88rKtQs7DNbj5amNI4/kWaMcQ== -END CERTIFICATE- OpenSSL versions I've tried: OpenSSL 0.9.8g 19 Oct 2007, OpenSSL 0.9.8o 01 Jun 2010 Platfroms tested: Debian, Ubuntu, Windows. Many thanks, Grant.
WG: OCSP response signature verification
Hi everyone, we are currently trying to verify an ocsp response. The return is Response verify OK but we need to verify the signature algorithm of the response signature. We tried putting the response into an DER and parsing it. But still no information about the signature. There are signature algorithm printed, but those are the ones of the certificates. Or am I wrong? Is there a way to only print the signature of the response? I've added the response for further information. Any help would be appreciated! S999D003:/tmp/ocsp # openssl ocsp -respin response-2.der -text OCSP Response Data: OCSP Response Status: successful (0x0) Response Type: Basic OCSP Response Version: 1 (0x0) Responder Id: C = DE, O = D-Trust GmbH, CN = D-TRUST OCSP-03 2008:PN Produced At: Mar 12 09:58:31 2010 GMT Responses: Certificate ID: Hash Algorithm: sha1 Issuer Name Hash: A611B199CA6EE1B1B8599953CBF428F8F8C94641 Issuer Key Hash: F9CBC2D42788A9A1B050625E4DD2547D74731EBE Serial Number: 094D36 Cert Status: good This Update: Mar 12 09:58:31 2010 GMT Response Single Extensions: 1.3.36.8.3.12: ..20090715143639Z 1.3.36.8.3.13: 0!0...+...'.}O.L.j}..T. Response Extensions: OCSP Nonce: 0410F987B6A59DB4116D1F60F436790C8C73 OCSP Archive Cutoff: Mar 21 00:00:00 1975 GMT Certificate: Data: Version: 3 (0x2) Serial Number: 515214 (0x7dc8e) Signature Algorithm: sha256WithRSAEncryption Issuer: C=DE, O=D-Trust GmbH, CN=D-TRUST Qualified Root CA 1 2008:PN Validity Not Before: Jul 25 08:25:06 2008 GMT Not After : Jul 24 08:25:06 2013 GMT Subject: C=DE, O=D-Trust GmbH, CN=D-TRUST OCSP-03 2008:PN Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00:f9:ee:d4:f3:19:42:22:88:7b:cc:d4:9d:63:5b: 4b:7d:ed:ad:76:18:2d:90:76:d4:d3:46:b1:7a:fc: [...]47:83:7a:39:40:7c:dd:45:92:a3:d8:3d:e4:4c:62: c3:bd Exponent: 3017650581 (0xb3ddb195) X509v3 extensions: X509v3 Extended Key Usage: OCSP Signing X509v3 Authority Key Identifier: keyid:67:E0:65:56:FC:7D:25:37:C5:BF:ED:78:88:2A:F0:FA:F2:47:C0:3A qcStatements: 0.0..F..0..F. Authority Information Access: OCSP - URI:http://qual.ocsp.d-trust.net X509v3 Certificate Policies: Policy: 1.3.6.1.4.1.4788.2.31.1 X509v3 CRL Distribution Points: URI:ldap://directory.d-trust.net/CN=D-TRUST%20Qualified%20Root%20CA%201%202008%3APN,O=D-Trust%20GmbH,C=DE?certificaterevocationlist URI:http://www.d-trust.net/crl/d-trust_qualified_root_ca_1_2008.crl X509v3 Issuer Alternative Name: email:i...@d-trust.net, URI:http://www.d-trust.net X509v3 Subject Key Identifier: 69:6E:2D:C0:AC:21:5E:52:4F:04:B2:57:B9:A8:93:18:D9:4B:F3:42 X509v3 Key Usage: critical Non Repudiation Signature Algorithm: sha256WithRSAEncryption 08:15:99:7a:60:45:35:c0:48:78:b2:e8:cd:fe:c8:2d:ad:3d: [...] 44:b6:ea:3d:75:cb:40:5a:c4:e3:31:3b:69:14:77:e1:01:59: 3c:a8:56:27 -BEGIN CERTIFICATE- MIIFCjCCA/KgAwIBAgIDB9yOMA0GCSqGSIb3DQEBCwUAMFIxCzAJBgNVBAYTAkRF [...] SycN3OakJ+QSiYCOOlQOY5TC+Ns5r/I9UzgGRzUqSr5Ho1kkI9h3Z0fnCjLlHwC5 +f/EUYHDfsXGTLQT1L1xEcSOUMJqV3c2RLbqPXXLQFrE4zE7aRR34QFZPKhWJw== -END CERTIFICATE- Certificate: Data: Version: 3 (0x2) Serial Number: 515120 (0x7dc30) Signature Algorithm: sha256WithRSAEncryption Issuer: C=DE, O=D-Trust GmbH, CN=D-TRUST Qualified Root CA 1 2008:PN Validity Not Before: Jul 24 16:36:17 2008 GMT Not After : Jul 24 16:36:17 2013 GMT Subject: C=DE, O=D-Trust GmbH, CN=D-TRUST Qualified Root CA 1 2008:PN Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00:a6:87:ed:90:a5:73:91:95:c2:19:37:b5:29:c4: a4:5f:9d:0b:29:90:28:a7:07:7e:3f:62:49:b6:25: 2f:59:db:33:2d:25:d6:d7:a1:ff:87:08:f0:b5:04: dd:45:ca:25:a5:e3:29:8c:48:8d:06:79:a7:26:9f: c8:20:2d:09:de:bc:84:94:6d:23:8a:8a:98:1a:a9: 9e:5e:de:8e:f7:ca:b5:92:dc:0a:59:ef:03:e6:b4: 9c:83:9f:8a:b5:0e:e5:2c:2a:d5:c7:60:fa:00:ae: 41:db:76:e8:8b:bd:b1:16:06:37:85:d3:50:6d:6c: 56:af:42:6d:19:28:25:8a:a7:c5:de:e1:0b:b3:32:
Re: WG: OCSP response signature verification
On Fri, Mar 12, 2010, Michel Pittelkow - michael-wessel.de wrote: Hi everyone, we are currently trying to verify an ocsp response. The return is Response verify OK but we need to verify the signature algorithm of the response signature. We tried putting the response into an DER and parsing it. But still no information about the signature. There are signature algorithm printed, but those are the ones of the certificates. Or am I wrong? Is there a way to only print the signature of the response? It should print the signature algorithm and signature just before the certificates. See the OCSP_RESPONSE_print() function in ocsp_prn.c. Are you using an old version of OpenSSL? I've added the response for further information. Any help would be appreciated! Would be more useful if you'd attached the DER response i.e. response-2.der, can you send that? S999D003:/tmp/ocsp # openssl ocsp -respin response-2.der -text [snip] Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: WG: OCSP response signature verification
Sure! Here are the request and response files. Kind regards Michel Pittelkow Hi everyone, we are currently trying to verify an ocsp response. The return is Response verify OK but we need to verify the signature algorithm of the response signature. We tried putting the response into an DER and parsing it. But still no information about the signature. There are signature algorithm printed, but those are the ones of the certificates. Or am I wrong? Is there a way to only print the signature of the response? It should print the signature algorithm and signature just before the certificates. See the OCSP_RESPONSE_print() function in ocsp_prn.c. Are you using an old version of OpenSSL? I've added the response for further information. Any help would be appreciated! Would be more useful if you'd attached the DER response i.e. response-2.der, can you send that? S999D003:/tmp/ocsp # openssl ocsp -respin response-2.der -text [snip] Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org +--+ | - michael-wessel.de Secure E-Mail Status - | +--+ | - Die Nachricht war weder verschluesselt noch digital unterschrieben | +--+ request-2.der Description: request-2.der response-2.der Description: response-2.der
AW: WG: OCSP response signature verification
I forgot to write, which versions are used. For the client we are using 0.9.8L. But we also tested with M. We are not sure about the responders but we are trying to find out. Kind regards Michel Pittelkow Hi everyone, we are currently trying to verify an ocsp response. The return is Response verify OK but we need to verify the signature algorithm of the response signature. We tried putting the response into an DER and parsing it. But still no information about the signature. There are signature algorithm printed, but those are the ones of the certificates. Or am I wrong? Is there a way to only print the signature of the response? It should print the signature algorithm and signature just before the certificates. See the OCSP_RESPONSE_print() function in ocsp_prn.c. Are you using an old version of OpenSSL? I've added the response for further information. Any help would be appreciated! Would be more useful if you'd attached the DER response i.e. response-2.der, can you send that? S999D003:/tmp/ocsp # openssl ocsp -respin response-2.der -text [snip] Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org +--+ | - michael-wessel.de Secure E-Mail Status - | +--+ | - Die Nachricht war weder verschluesselt noch digital unterschrieben | +--+ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: WG: OCSP response signature verification
On Fri, Mar 12, 2010, Michel Pittelkow - michael-wessel.de wrote: I forgot to write, which versions are used. For the client we are using 0.9.8L. But we also tested with M. We are not sure about the responders but we are trying to find out. Oops, there was a bug in the print routine which meant the signature and signature algorithm were never printed out. I've just fixed it here: http://cvs.openssl.org/chngview?cn=19434 Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
AW: WG: OCSP response signature verification
Ah! That's exactly the point, where I tried to edit the code and recompile it. But every time I tried to I became an error in make complaining about [link_app.] and a false call of 'main' in _start... Can I just replace the file and recompile openssl? Or do I have to edit something in any type of data. Sorry. I am not that into C though :-( Kind regards Michel Pittelkow I forgot to write, which versions are used. For the client we are using 0.9.8L. But we also tested with M. We are not sure about the responders but we are trying to find out. Oops, there was a bug in the print routine which meant the signature and signature algorithm were never printed out. I've just fixed it here: http://cvs.openssl.org/chngview?cn=19434 Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org +--+ | - michael-wessel.de Secure E-Mail Status - | +--+ | - Die Nachricht war weder verschluesselt noch digital unterschrieben | +--+ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: WG: OCSP response signature verification
On Fri, Mar 12, 2010, Michel Pittelkow - michael-wessel.de wrote: Ah! That's exactly the point, where I tried to edit the code and recompile it. But every time I tried to I became an error in make complaining about [link_app.] and a false call of 'main' in _start... Can I just replace the file and recompile openssl? Or do I have to edit something in any type of data. Sorry. I am not that into C though :-( If you've compiled OpenSSL already you should just make the change and type make and it should rebuild it OK. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
AW: WG: OCSP response signature verification
Done that. It now seems to work! Thank you :) S999D003:/home/ah/test # ./openssl ocsp -respin response-2.der -text OCSP Response Data: OCSP Response Status: successful (0x0) Response Type: Basic OCSP Response Version: 1 (0x0) Responder Id: C = DE, O = D-Trust GmbH, CN = D-TRUST OCSP-03 2008:PN Produced At: Mar 12 09:58:31 2010 GMT Responses: Certificate ID: Hash Algorithm: sha1 Issuer Name Hash: A611B199CA6EE1B1B8599953CBF428F8F8C94641 Issuer Key Hash: F9CBC2D42788A9A1B050625E4DD2547D74731EBE Serial Number: 094D36 Cert Status: good This Update: Mar 12 09:58:31 2010 GMT Response Single Extensions: 1.3.36.8.3.12: ..20090715143639Z 1.3.36.8.3.13: 0!0...+...'.}O.L.j}..T. Response Extensions: OCSP Nonce: 0410F987B6A59DB4116D1F60F436790C8C73 OCSP Archive Cutoff: Mar 21 00:00:00 1975 GMT Signature Algorithm: sha256WithRSAEncryption c0:71:91:0c:47:da:92:47:4a:03:a7:4f:2b:1f:fb:96:aa:a3: ce:e0:c1:23:bb:e1:39:48:4e:68:28:db:99:79:83:12:bf:48: 66:63:4b:fc:c3:39:c0:87:ef:26:2c:53:6b:54:dd:f9:1e:17: 66:ff:d9:9f:6e:7d:31:65:90:7c:5c:b5:fa:31:42:44:96:4b: 1d:c7:4d:4f:6a:57:93:2e:c6:72:6f:da:47:f7:33:58:f4:ed: 51:fc:e7:24:19:dc:23:2e:12:b4:b2:1d:76:14:7c:56:ac:0e: 81:b8:b8:ef:a2:5f:5d:11:a9:cd:a8:19:31:2e:35:5a:b4:bc: 87:4b:66:c8:7a:a1:1f:6e:6b:1b:2b:85:5c:3a:34:cb:e4:c2: 68:58:27:70:d5:99:fd:92:3c:0d:08:2d:05:93:80:ef:be:42: 0a:d1:81:82:8f:06:51:ef:15:9c:19:38:63:d9:73:0f:c3:c5: 13:26:ca:eb:b2:76:7b:32:20:df:99:c1:50:13:f5:76:5c:44: f2:91:0d:42:4f:46:57:8a:f7:f1:6f:a2:21:dd:b5:8b:84:96: d2:de:25:df:d2:4b:f4:e1:dd:9e:31:48:21:95:08:0e:67:6f: 49:e1:ab:77:11:cf:61:dc:ae:d3:38:a3:fb:54:36:70:bc:1a: 56:47:22:fe Certificate: Data: Kind regards Michel Pittelkow Ah! That's exactly the point, where I tried to edit the code and recompile it. But every time I tried to I became an error in make complaining about [link_app.] and a false call of 'main' in _start... Can I just replace the file and recompile openssl? Or do I have to edit something in any type of data. Sorry. I am not that into C though :-( If you've compiled OpenSSL already you should just make the change and type make and it should rebuild it OK. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org +--+ | - michael-wessel.de Secure E-Mail Status - | +--+ | - Die Nachricht war weder verschluesselt noch digital unterschrieben | +--+ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Yet another signature Verification
Hello, We started working on a project several months ago that has a need for signature verification of an xml file. We had completed our tests and everything was woking. The provider of the file then sent us a new Public Key and said that it is what we will get for the live data. The file will not read into our programs (one in C++ and one in Java). The C code that was working is as follows: pkey = PEM_read_PUBKEY(fp, NULL, NULL, NULL); fclose (fp); if (pkey == NULL) { error stuff } sigDatEnc = g_base64_decode( (gchar *) sigDat, sigDatLen); EVP_VerifyInit(md_ctx, EVP_sha512()); EVP_VerifyUpdate(md_ctx, xmlDat, strlen((char *) xmlDat)); err = EVP_VerifyFinal (md_ctx, sigDatEnc, sigDatLen, pkey); free(sigDatEnc); EVP_PKEY_free (pkey); It fails on the PEM_read_PUBKEY by returning a NULL when it tries to read in the file. The only help we can get from the provider is the following code (Perl) which woks for them: #!/usr/bin/perl use Crypt::OpenSSL::Random; use Crypt::OpenSSL::RSA; use MIME::Base64; my $packet = EOD; -BEGIN GLOBAL ENERGY INNOVATIONS LICENSE DATA- license_datamac00:0D:15:00:74:1A/macversion1.0.0/versionserialEC 1000-0900018/serialmodule code=impedancestart2000-01-01/startend2099-12-31/end/modulecoo kieD2940155EEDB6C92E3FD703A63EC4527/cookietime1265407356/time/licens e_data -BEGIN GLOBAL ENERGY INNOVATIONS SIGNATURE- JkNJD5EG0o+ioFc67Ud+GWuoCjKHgdi9AzGC3B7yqf1QxBR8B4H5/owRrsgcB/KMjV2VP7drWWWD ETcS60FfYVLsUsakj69tCC8aVZCdkSeXmcvRvva8YzTi5oPzflDC8/o/MrMvy1+o8GgfgPTuAeSy iCGnI0R1KVIWiAeRB859y4WCJ/ME+CB1zWhf+8QawosQzGtrOL+l+8PRQSHxAU1Lr+8VcIQdF7iW MYmeS7YDNZRoxfKHev527oNYlR4ymSzgrgjh7sweNwLVuAIfX89PIGXPRWJYyddeE6au8cgJ2LIK aVU1Kf8MpQfbCm3IKCXgOnGUUGiNclAbOkfI4fR7wwsPM3XyNCtm0vLKZ58bdRC3tUxH3bzveOff +uyYQB+yRRNvhqMFnVtWr9N2Zd67eAkHlMKlJjBz2qyDcyMLk2NcaOJtcerHYmviBZrUaGJ8WvH8 7zb0FGsHzlkyIbaWrwwXAFl/yWxTwh0sti3QObpIFvY6CgsoCktZg2mtWHCdblgydBYer1dHN37h fz54lZAC6m5GpKch/K7ChcfmeSgX/3euybP6ZjcUeeyFp5AGhG9xND/e7XPk93iCzj044PyDoQLG 75ZP00LTIwAkG0Vf2WR6O9gTJovCklP2eKxn4BN7UlM/4S5EUkrW4mbV9f34/qGkhqG8f10Xzig= -END GLOBAL ENERGY INNOVATIONS SIGNATURE- EOD my $public_key = EOD; -BEGIN RSA PUBLIC KEY- MIICCgKCAgEAvW90MggAl07zMvyQdUk18/iOySyY8P/1vqC5XGNvC5aXIvC8UDpU 2v8EK40SUc0FEqP8g893HgW+yDJa7SF2VyW2IEcnum2yot2ifGHjCDUnea2W5wBO aFlY9Co9VXDLhRJNQyXyfKCXL/xiM2O2Py1x0+SIXkc1ml2M0x4Fb4QsMO5E2Y6o 2mRVlPlooDPkj4BijvVX/EiPWpfbQAoidk8urHif5OTdIyqunce6b1Fqz7NH118n DVQp/Txk6hGtGkHxYCC0biG20+u6XlD9qkYWn2KYqxBxJZvV12YO3pC1kzYAR9Xy VlCfyHK8pGdcHO8LHZsWR5PeryNBWU14xlOVQsziFE4oMyEiSt00cUQhF+yCLQpr T7+xvKTGA9YTXfI59LprKMXN5RPCBF5WuQZoxlREQMjhYV+b1rQx1jkkrflA0liF oTgkrGw5mxk9jlQbFNeY4eVAudF3w2OdVD/N5UNoR+L7Jj1gAJjEV6what uYQrJ9f58h 7UzsktkHPgROncZGGZLDM/acRbzar3Iv4CK8hnsHrAan8qd7jh9kU8DEXQ1Is2qf w1/BMX4DPfijY1zboqUbrFwAmq7twoiTJPK+++aYBU7fu5tvRIPIXdziGOkWmrc6 gjsIQA8GoM4am19VlD6P1inHMa1P4s8Md6AvbeAPkWXGmsYdsHvRDo8CAwEAAQ== -END RSA PUBLIC KEY- EOD my ($payload, $signature) = ($packet =~ m{--\n(.*?)--[^\n]+\n(.*?)--}ms); my $decoded_signature = decode_base64($signature); my $rsa_pub = Crypt::OpenSSL::RSA-new_public_key($public_key); $rsa_pub-use_sha512_hash(); if ($rsa_pub-verify($payload, $decoded_signature)) { print Signature verifies.\n; } else { print Signature DOES NOT verify.\n; } My question is -- can anyone tell me what OpenSSL function calls (in both C and Java) are made using this code written in Perl? I suppose a secondary question would be -- what function would read in this Public key from a file as my original code did? Thank you for the help Jim
Re: Yet another signature Verification
On Sat, Feb 06, 2010, Jim Welch wrote: Hello, We started working on a project several months ago that has a need for signature verification of an xml file. We had completed our tests and everything was woking. The provider of the file then sent us a new Public Key and said that it is what we will get for the live data. The file will not read into our programs (one in C++ and one in Java). The C code that was working is as follows: pkey = PEM_read_PUBKEY(fp, NULL, NULL, NULL); fclose (fp); if (pkey == NULL) { error stuff } sigDatEnc = g_base64_decode( (gchar *) sigDat, sigDatLen); EVP_VerifyInit(md_ctx, EVP_sha512()); EVP_VerifyUpdate(md_ctx, xmlDat, strlen((char *) xmlDat)); err = EVP_VerifyFinal (md_ctx, sigDatEnc, sigDatLen, pkey); free(sigDatEnc); EVP_PKEY_free (pkey); It fails on the PEM_read_PUBKEY by returning a NULL when it tries to read in the file. The only help we can get from the provider is the following code (Perl) which woks for them: The FAQ tells you how to get more information however... -BEGIN RSA PUBLIC KEY- MIICCgKCAgEAvW90MggAl07zMvyQdUk18/iOySyY8P/1vqC5XGNvC5aXIvC8UDpU 2v8EK40SUc0FEqP8g893HgW+yDJa7SF2VyW2IEcnum2yot2ifGHjCDUnea2W5wBO aFlY9Co9VXDLhRJNQyXyfKCXL/xiM2O2Py1x0+SIXkc1ml2M0x4Fb4QsMO5E2Y6o 2mRVlPlooDPkj4BijvVX/EiPWpfbQAoidk8urHif5OTdIyqunce6b1Fqz7NH118n DVQp/Txk6hGtGkHxYCC0biG20+u6XlD9qkYWn2KYqxBxJZvV12YO3pC1kzYAR9Xy VlCfyHK8pGdcHO8LHZsWR5PeryNBWU14xlOVQsziFE4oMyEiSt00cUQhF+yCLQpr T7+xvKTGA9YTXfI59LprKMXN5RPCBF5WuQZoxlREQMjhYV+b1rQx1jkkrflA0liF oTgkrGw5mxk9jlQbFNeY4eVAudF3w2OdVD/N5UNoR+L7Jj1gAJjEV6what uYQrJ9f58h 7UzsktkHPgROncZGGZLDM/acRbzar3Iv4CK8hnsHrAan8qd7jh9kU8DEXQ1Is2qf w1/BMX4DPfijY1zboqUbrFwAmq7twoiTJPK+++aYBU7fu5tvRIPIXdziGOkWmrc6 gjsIQA8GoM4am19VlD6P1inHMa1P4s8Md6AvbeAPkWXGmsYdsHvRDo8CAwEAAQ== -END RSA PUBLIC KEY- That is an RSAPublicKey structure for which you call PEM_read_RSAPublicKey(). That returns an RSA structure which you need to convert to an EVP_PKEY structure using EVP_PKEY_new() and EVP_PKEY_assign_RSA() Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Signature Verification
Hi, Based on information and suggestions you have given me, I came at the problem from a different direction. Instead of trying to verify the signature, I tried using out private key to sign the original data. After a couple of hours, I suceeded in getting the same signature as was supplied in the signed message. I then used this information to verify the signature just created. Just a small amount of more work yielded a routine that worked in taking the signed file, parsing it and verifying the signature. Here's a copy of the final verification code. xmlDat is the original xml file string and sigDat is the signature received. // Read public key fp = fopen (filePubKey, r); if (fp == NULL) { printf(Didn't work 1\n); return(1); } pkey = PEM_read_PUBKEY(fp, NULL, NULL, NULL); fclose (fp); if (pkey == NULL) { printf(Didn't work 2\n); return(2); } sigDatEnc = g_base64_decode( sigDat, sigDatLen); EVP_VerifyInit(md_ctx, EVP_sha512()); EVP_VerifyUpdate(md_ctx, xmlDat, strlen(xmlDat)); err = EVP_VerifyFinal (md_ctx, sigDatEnc, sigDatLen, pkey); // g_free(sigDatEnc); free(sigDatEnc);// looked up g_free and it seems to just do a free() EVP_PKEY_free (pkey); if (err != 1) { printf(Didn't Verify %d\n, err); return(2); } printf (Signature Verified Ok.\n); return(0); Thanks for everything. Jim - Original Message - From: Mounir IDRASSI mounir.idra...@idrix.net To: openssl-users@openssl.org Sent: Saturday, November 07, 2009 4:09 AM Subject: Re: Signature Verification Hi, In order to help you further, can you post : - The data to be hashed which is the content of your variable xmlDat - The signature to be verified which is the content of your variable sigDat (maybe it's what you posted first) - The public key that will be used for the verification - The endianess of the the signature. It should be big endian as expected by OpenSSL And just one last confirmation : In your first email, you posted some BASE64 data that you say is the signature. This data is 512 bytes long. So this would mean that the key used is a 4096 bit RSA key. Is this correct? Cheers, -- Mounir IDRASSI IDRIX http://www.idrix.fr Jim Welch wrote: Hello Again, The code is there to check for a non-null pkey. It wasn't copied to keep the original message shorter. I've now made sure that I've Base64'd the xml string and Base64'd the signature string. These are what I'm giving to the EVP_VerifyUpdate and EVP_VerifyFinal. Still not verifying. Thanks Again, Jim - Original Message - From: Mounir IDRASSI mounir.idra...@idrix.net To: openssl-users@openssl.org Sent: Friday, November 06, 2009 5:11 PM Subject: Re: Signature Verification Hi, You must also handle BASE64 decoding in EVP_VerifyUpdate not only EVP_VerifyFinal. Those two functions must have as input the byte arrays that represent the binary data and the binary signature respectively. Concerning PEM_read_PUBKEY, if it returns a non NULL pointer then everything is OK with the public key and you don't have to worry. Cheers, -- Mounir IDRASSI IDRIX http://www.idrix.fr Jim Welch wrote: Hi, Thank you for the response. It was sha512 not 256. I changed it to EVP_sha512 in the code but it still won't verify. On the verify final, I've tried it both with and without a Base64 converted string (and corresponding length). I'm not sure from what I've read if the PEM_read_PUBKEY does a Base64 conversion on the Public Key or not and I'm not sure where to look in the pkey to find out. Jim - Original Message - From: Mounir IDRASSI mounir.idra...@idrix.net To: openssl-users@openssl.org Sent: Friday, November 06, 2009 3:55 PM Subject: Re: Signature Verification Hi, In your description you say that the signature was created with SHA256 but in your code you are using SHA-1 through EVP_sha1. Replace this with EVP_sha256 to have a correct processing. Also, your data seems to be BASE64 encoded and you are computing the digest directly on the BASE64 string. You should convert this BASE64 string to the corresponding byte array and then compute the digest on this byte array. I hope this will help. Cheers, -- Mounir IDRASSI IDRIX http://www.idrix.fr Jim Welch wrote: Hello, I've been trying to verify the signature from the following xml data: license_dataversion1.0/versionserialEC1000-0900018/serialmac00:54:66:18:3A:40/macmodule code=impedancestart2000-01-01/startend2099-12-31/end/modulemodule code=multimeterstart2000-01-01/startend2099-12-31/end/modulemodule code=sulfationstart2000-01-01/startend2099-12-31/end/modulecookieAA80A2A7119FD4F1C122080E1AD17490/cookie/license_data using this signature: C4S953HqB8S/SZ8nOO5IgGA0Vm3BxHT8vByWJFG2gn/OrBKc45QvjEdX855bb9p8KdSa1YQt3nnv p6MCA+5YCDePEIuYpbTYzAIJ9p7zqpJsXzb8YlDpw4qpf0TSbCCEFZZReSRSAxlE2gH/SOvPAjRY ykvxbjrgMQ07Jf/ae4lX+CaBxA/Az8efhsBDyT6wCPECkj1SiufTtVA2MAt9Bf76Y1T5RnHph/kf Hj3/osgrMKKbIPhii2nPktMH223QfgmTOtHxw21ahi2vcSnADb9p1WIjDiq
Re: Signature Verification
Hi, In order to help you further, can you post : - The data to be hashed which is the content of your variable xmlDat - The signature to be verified which is the content of your variable sigDat (maybe it's what you posted first) - The public key that will be used for the verification - The endianess of the the signature. It should be big endian as expected by OpenSSL And just one last confirmation : In your first email, you posted some BASE64 data that you say is the signature. This data is 512 bytes long. So this would mean that the key used is a 4096 bit RSA key. Is this correct? Cheers, -- Mounir IDRASSI IDRIX http://www.idrix.fr Jim Welch wrote: Hello Again, The code is there to check for a non-null pkey. It wasn't copied to keep the original message shorter. I've now made sure that I've Base64'd the xml string and Base64'd the signature string. These are what I'm giving to the EVP_VerifyUpdate and EVP_VerifyFinal. Still not verifying. Thanks Again, Jim - Original Message - From: Mounir IDRASSI mounir.idra...@idrix.net To: openssl-users@openssl.org Sent: Friday, November 06, 2009 5:11 PM Subject: Re: Signature Verification Hi, You must also handle BASE64 decoding in EVP_VerifyUpdate not only EVP_VerifyFinal. Those two functions must have as input the byte arrays that represent the binary data and the binary signature respectively. Concerning PEM_read_PUBKEY, if it returns a non NULL pointer then everything is OK with the public key and you don't have to worry. Cheers, -- Mounir IDRASSI IDRIX http://www.idrix.fr Jim Welch wrote: Hi, Thank you for the response. It was sha512 not 256. I changed it to EVP_sha512 in the code but it still won't verify. On the verify final, I've tried it both with and without a Base64 converted string (and corresponding length). I'm not sure from what I've read if the PEM_read_PUBKEY does a Base64 conversion on the Public Key or not and I'm not sure where to look in the pkey to find out. Jim - Original Message - From: Mounir IDRASSI mounir.idra...@idrix.net To: openssl-users@openssl.org Sent: Friday, November 06, 2009 3:55 PM Subject: Re: Signature Verification Hi, In your description you say that the signature was created with SHA256 but in your code you are using SHA-1 through EVP_sha1. Replace this with EVP_sha256 to have a correct processing. Also, your data seems to be BASE64 encoded and you are computing the digest directly on the BASE64 string. You should convert this BASE64 string to the corresponding byte array and then compute the digest on this byte array. I hope this will help. Cheers, -- Mounir IDRASSI IDRIX http://www.idrix.fr Jim Welch wrote: Hello, I've been trying to verify the signature from the following xml data: license_dataversion1.0/versionserialEC1000-0900018/serialmac00:54:66:18:3A:40/macmodule code=impedancestart2000-01-01/startend2099-12-31/end/modulemodule code=multimeterstart2000-01-01/startend2099-12-31/end/modulemodule code=sulfationstart2000-01-01/startend2099-12-31/end/modulecookieAA80A2A7119FD4F1C122080E1AD17490/cookie/license_data using this signature: C4S953HqB8S/SZ8nOO5IgGA0Vm3BxHT8vByWJFG2gn/OrBKc45QvjEdX855bb9p8KdSa1YQt3nnv p6MCA+5YCDePEIuYpbTYzAIJ9p7zqpJsXzb8YlDpw4qpf0TSbCCEFZZReSRSAxlE2gH/SOvPAjRY ykvxbjrgMQ07Jf/ae4lX+CaBxA/Az8efhsBDyT6wCPECkj1SiufTtVA2MAt9Bf76Y1T5RnHph/kf Hj3/osgrMKKbIPhii2nPktMH223QfgmTOtHxw21ahi2vcSnADb9p1WIjDiq/gLk0uisT/p0g4MZb SKNOct3MRqgv64wtyUD+W/+8/yGQK+/IXNIhgKoKsvuwR242c7RpF+HdVZRrfeIQMnUAAo/7q+rS AzRJO7L7xoXYvFOmVxvjRZP8Rhw445N6bnLwLxANFNvyoo5ykGdocBUEBMD5sC3TipYUti39mso2 dsqSMwtRhPDw9dzf6evwG3+Qo0ewLVap3pNu8XzBrXxCM6pv7IydmekiHvSF6OFrt/rPUA2pXyuU njhD/twe0+n5fLlSTZ6w/D898e/blvFUroQbmaI8Rr7AE9fZY0KJBuc73YgPTXOnm4Iqc/5vMwId j27g+JGWEzjyAtNIBo9Su0/9LE1IVPyZgAjquBEmKEAcQQjnW4D8kj2mllJLRwI00e1TAwE9Klo= These two strings above are being sent from a server as one file which I parse into the two separate strings making sure white space has been removed from the xml as that was how it was signed. The signature was created with RSA SHA512. I'm using a C program to verify and have tried numerous attemps with no sucess. The openssl release is 0.9.8k. The vars sigDat and xmlDat are the respective strings. The code is as follows (some parts left out for simplicity): fp = fopen (filePubKey, r); pkey = PEM_read_PUBKEY(fp, NULL, NULL, NULL); EVP_VerifyInit (md_ctx, EVP_sha1()); EVP_VerifyUpdate (md_ctx, xmlDat, strlen(xmlDat)); err = EVP_VerifyFinal (md_ctx, sigDat, strlen(sigDat), pkey); EVP_PKEY_free (pkey); Any ideas as to what is wrong. Another part of the project here involves java and the programmer working on that says that he can verify the signature so I know that the data is correct. Thank You, Jim Welch __ OpenSSL Project http://www.openssl.org User Support
RE: Openssl signature verification
Dear All, Thank you Dave Thompson for your help and clarifying my doubt. Thank you. Regards, --Ajeet Kumar Singh Sarve Bhavantu Sukhina ,Sarve Santu NiramayaSarve Bhadrani Pashyantu , Maa Kaschit Dukha Bhagh Bhavet -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dave Thompson Sent: Saturday, January 31, 2009 8:11 AM To: openssl-users@openssl.org Subject: RE: Openssl signature verification From: owner-openssl-us...@openssl.org On Behalf Of Ajeet kumar.S Sent: Friday, 30 January, 2009 00:07 In openssl API X509_verify(X509 *a, EVP_PKEY *r) is used to verify the signature of certificate. I have some doubt please help me. Is in this API we are passing the CA certificate and public key of CA certificate? We pass any cert and the key we believe (are told) will verify it. CA root certs are self-signed; the key _in_ the cert is used to sign it, or to be precise the keypair whose public half is in the cert is used. As a result you can't trust a root cert simply because the signature verifies; you must have other evidence this is the/a valid root cert from/for a given CA, such as a trusted distribution or manually-checked fingerprint. Lower-level CA certs (if any) and end-entity certs are signed by a parent cert, or to be precise by a keypair whose public half is certified by the parent cert. If you instead use X509_verify_cert, it tries several methods to find and verify the whole cert chain (from a root) by looking in (data from) a configurable file and/or (hashed) entries in a configurable directory. If you want to do this job or part(s) of it yourself, you can look at that for an example, but it's pretty complicated. What is data over SSL compute the HASH? The DER-encoded CertificateInfo portion of the cert, which is the first element in the outermost SEQUENCE and contains version, serial, copy of sig-algid, issuer name, subject name publickey, validity period, and for v3 optional extensions such as keyusage, subjectaltname, keyids, etc. This is everything in the cert except the appended algid and signature, and is indented under Data: in the display from openssl x509 -text . SSL will decrypt the CA signature (Which is on CA certificate bundle)? Decrypted CA Signature will match to above HASH.(query 2)? For RSA signatures this is approximately true. You actually raise the signature value to the public exponent (like RSA encryption) rather than the private exponent (as for RSA decryption), and the (standard) padding is different for sign/verify than for encrypt/decrypt. For DSA signatures this is not true at all. There is no corresponding encryption or decryption; there is simply a signing algorithm and a verifying algorithm. You apply the verifying algorithm to determine if the received signature is correct for the (recomputed) hash. You separately asked In Openssl for signature verification we are using API ASN1_item_verify(). Let me know the data which is used for finger print (signature) creation is the CA public key or some thing else data . Please clarify this doubt. How we are verifying the signature? If you mean in crypto/x509/x_all.c X509_verify(), we are verifying the signature in the cert, of the data in the cert, using the key. No fingerprint is involved. This only applies to X509 certs; the verification of signatures on other things is similar but not identical. Fingerprints can be used in lots of situations and ways. _PKI_ fingerprints can meaningfully be computed on either the whole CertificateInfo thus verifying all the attributes directly, or just on the publickey since that is enough to verify the signature. But a fingerprint is not a signature; it does not itself have any cryptographic protection. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Openssl signature verification
From: owner-openssl-us...@openssl.org On Behalf Of Ajeet kumar.S Sent: Friday, 30 January, 2009 00:07 In openssl API X509_verify(X509 *a, EVP_PKEY *r) is used to verify the signature of certificate. I have some doubt please help me. Is in this API we are passing the CA certificate and public key of CA certificate? We pass any cert and the key we believe (are told) will verify it. CA root certs are self-signed; the key _in_ the cert is used to sign it, or to be precise the keypair whose public half is in the cert is used. As a result you can't trust a root cert simply because the signature verifies; you must have other evidence this is the/a valid root cert from/for a given CA, such as a trusted distribution or manually-checked fingerprint. Lower-level CA certs (if any) and end-entity certs are signed by a parent cert, or to be precise by a keypair whose public half is certified by the parent cert. If you instead use X509_verify_cert, it tries several methods to find and verify the whole cert chain (from a root) by looking in (data from) a configurable file and/or (hashed) entries in a configurable directory. If you want to do this job or part(s) of it yourself, you can look at that for an example, but it's pretty complicated. What is data over SSL compute the HASH? The DER-encoded CertificateInfo portion of the cert, which is the first element in the outermost SEQUENCE and contains version, serial, copy of sig-algid, issuer name, subject name publickey, validity period, and for v3 optional extensions such as keyusage, subjectaltname, keyids, etc. This is everything in the cert except the appended algid and signature, and is indented under Data: in the display from openssl x509 -text . SSL will decrypt the CA signature (Which is on CA certificate bundle)? Decrypted CA Signature will match to above HASH.(query 2)? For RSA signatures this is approximately true. You actually raise the signature value to the public exponent (like RSA encryption) rather than the private exponent (as for RSA decryption), and the (standard) padding is different for sign/verify than for encrypt/decrypt. For DSA signatures this is not true at all. There is no corresponding encryption or decryption; there is simply a signing algorithm and a verifying algorithm. You apply the verifying algorithm to determine if the received signature is correct for the (recomputed) hash. You separately asked In Openssl for signature verification we are using API ASN1_item_verify(). Let me know the data which is used for finger print (signature) creation is the CA public key or some thing else data . Please clarify this doubt. How we are verifying the signature? If you mean in crypto/x509/x_all.c X509_verify(), we are verifying the signature in the cert, of the data in the cert, using the key. No fingerprint is involved. This only applies to X509 certs; the verification of signatures on other things is similar but not identical. Fingerprints can be used in lots of situations and ways. _PKI_ fingerprints can meaningfully be computed on either the whole CertificateInfo thus verifying all the attributes directly, or just on the publickey since that is enough to verify the signature. But a fingerprint is not a signature; it does not itself have any cryptographic protection. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Openssl signature verification
Dear All, In openssl API X509_verify(X509 *a, EVP_PKEY *r) is used to verify the signature of certificate. I have some doubt please help me. 1. Is in this API we are passing the CA certificate and public key of CA certificate? 2. What is data over SSL compute the HASH? 3. SSL will decrypt the CA signature (Which is on CA certificate bundle)? 4. Decrypted CA Signature will match to above HASH.(query 2)? Please tell me. Thank you. Regards, --Ajeet Kumar Singh
Re: ECDSA signature verification
On Mon, 2009-01-19 at 11:22 +, Young, Alistair wrote: * is it possible to define our own curves (rather than using one of the predefined curves)? if you want to play with your EC, check crypto/ec/ectest.c if you want to add a new curve to openssl, have a look at crypto/ec/ec_curve.c, crypto/objects/object.txt I opened a thread in openssl-dev: Adding an EC to OpenSSL. * how configurable is the hashing step? I see that there are parameters like -ecdsa-with-SHA1 - can arbitrary hashing functions be used? there is only sha1. You have to add more EVP, I think... OpenSSL 0.9.9 is required for public-key EVP. * where can I find some good (= simple!) documentation on using OpenSSL for this task. I've not had much luck finding anything relevant in the man page. source code? ECDSA has also doxygen comments :-) bye! -- Emanuele Cesena emanuele.ces...@gmail.com http://ecesena.dyndns.org Il corpo non ha ideali __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: ECDSA signature verification
Thank you, Emanuele. We really need to use the FIPS version of OpenSSL, so updating the code isn't a possiblity. However, looking into the source it looks as though all of the functions that we need are there, so hopefully we can get the functionality we require by writing a bit of code ourselves which links to the FIPS library. Regards, Alistair. -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Emanuele Cesena Sent: 23 January 2009 08:24 To: openssl-users@openssl.org Subject: Re: ECDSA signature verification On Mon, 2009-01-19 at 11:22 +, Young, Alistair wrote: * is it possible to define our own curves (rather than using one of the predefined curves)? if you want to play with your EC, check crypto/ec/ectest.c if you want to add a new curve to openssl, have a look at crypto/ec/ec_curve.c, crypto/objects/object.txt I opened a thread in openssl-dev: Adding an EC to OpenSSL. * how configurable is the hashing step? I see that there are parameters like -ecdsa-with-SHA1 - can arbitrary hashing functions be used? there is only sha1. You have to add more EVP, I think... OpenSSL 0.9.9 is required for public-key EVP. * where can I find some good (= simple!) documentation on using OpenSSL for this task. I've not had much luck finding anything relevant in the man page. source code? ECDSA has also doxygen comments :-) bye! -- Emanuele Cesena emanuele.ces...@gmail.com http://ecesena.dyndns.org Il corpo non ha ideali __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org Please help Logica to respect the environment by not printing this email / Merci d'aider Logica à préserver l'environnement en évitant d'imprimer ce mail / Bitte drucken Sie diese Nachricht nicht aus und helfen Sie so Logica dabei die Umwelt zu schuetzen / Por favor ajude a Logica a respeitar o ambiente não imprimindo este correio electrónico. This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: ECDSA signature verification
... though I notice that the Security Policy document does not explicitly mention ECDSA in the table of FIPS approved algorithms. It does mention DSA with 1024-bit keys (but has a confusing footnote which states that DSA supports a key size of less than 1024 bits except when not in FIPS mode - is there an extra 'not' in this statement?), but that perhaps doesn't cover ECDSA. Alistair. -Original Message- From: Young, Alistair Sent: 23 January 2009 10:13 To: 'openssl-users@openssl.org' Subject: RE: ECDSA signature verification Thank you, Emanuele. We really need to use the FIPS version of OpenSSL, so updating the code isn't a possiblity. However, looking into the source it looks as though all of the functions that we need are there, so hopefully we can get the functionality we require by writing a bit of code ourselves which links to the FIPS library. Regards, Alistair. -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Emanuele Cesena Sent: 23 January 2009 08:24 To: openssl-users@openssl.org Subject: Re: ECDSA signature verification On Mon, 2009-01-19 at 11:22 +, Young, Alistair wrote: * is it possible to define our own curves (rather than using one of the predefined curves)? if you want to play with your EC, check crypto/ec/ectest.c if you want to add a new curve to openssl, have a look at crypto/ec/ec_curve.c, crypto/objects/object.txt I opened a thread in openssl-dev: Adding an EC to OpenSSL. * how configurable is the hashing step? I see that there are parameters like -ecdsa-with-SHA1 - can arbitrary hashing functions be used? there is only sha1. You have to add more EVP, I think... OpenSSL 0.9.9 is required for public-key EVP. * where can I find some good (= simple!) documentation on using OpenSSL for this task. I've not had much luck finding anything relevant in the man page. source code? ECDSA has also doxygen comments :-) bye! -- Emanuele Cesena emanuele.ces...@gmail.com http://ecesena.dyndns.org Il corpo non ha ideali __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org Please help Logica to respect the environment by not printing this email / Merci d'aider Logica à préserver l'environnement en évitant d'imprimer ce mail / Bitte drucken Sie diese Nachricht nicht aus und helfen Sie so Logica dabei die Umwelt zu schuetzen / Por favor ajude a Logica a respeitar o ambiente não imprimindo este correio electrónico. This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: ECDSA signature verification
On Fri, 2009-01-23 at 10:13 +, Young, Alistair wrote: We really need to use the FIPS version of OpenSSL, so updating the code isn't a possiblity. ah ok, so maybe you can just skip EVP. bye! -- Emanuele Cesena emanuele.ces...@gmail.com http://ecesena.dyndns.org Il corpo non ha ideali __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: ECDSA signature verification
On Fri, Jan 23, 2009, Young, Alistair wrote: ... though I notice that the Security Policy document does not explicitly mention ECDSA in the table of FIPS approved algorithms. It does mention DSA with 1024-bit keys (but has a confusing footnote which states that DSA supports a key size of less than 1024 bits except when not in FIPS mode - is there an extra 'not' in this statement?), but that perhaps doesn't cover ECDSA. That is correct, ECDSA is not an approved algorithm in FIPS mode. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: ECDSA signature verification
-Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dr. Stephen Henson Sent: 23 January 2009 13:07 To: openssl-users@openssl.org Subject: Re: ECDSA signature verification On Fri, Jan 23, 2009, Young, Alistair wrote: ... though I notice that the Security Policy document does not explicitly mention ECDSA in the table of FIPS approved algorithms. It does mention DSA with 1024-bit keys (but has a confusing footnote which states that DSA supports a key size of less than 1024 bits except when not in FIPS mode - is there an extra 'not' in this statement?), but that perhaps doesn't cover ECDSA. That is correct, ECDSA is not an approved algorithm in FIPS mode. Steve. Thanks for confirming this for me, Steve. Off the top of your head, are you aware of any ECDSA implementations which have been FIPS validated? Alistair. Please help Logica to respect the environment by not printing this email / Merci d'aider Logica à préserver l'environnement en évitant d'imprimer ce mail / Bitte drucken Sie diese Nachricht nicht aus und helfen Sie so Logica dabei die Umwelt zu schuetzen / Por favor ajude a Logica a respeitar o ambiente não imprimindo este correio electrónico. This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
ECDSA signature verification
Hi, I'm new to OpenSSL, having just installed openssl-fips-1.2. I'm looking for some guidance in how to use OpenSSL (from the command line) to verify ECDSA signatures. In particular, I have the following questions: * is it possible to define our own curves (rather than using one of the predefined curves)? * how configurable is the hashing step? I see that there are parameters like -ecdsa-with-SHA1 - can arbitrary hashing functions be used? * where can I find some good (= simple!) documentation on using OpenSSL for this task. I've not had much luck finding anything relevant in the man page. Apologies for any dumb questions there - thanks in advance for any assistance! Alistair. Please help Logica to respect the environment by not printing this email / Merci d'aider Logica à préserver l'environnement en évitant d'imprimer ce mail / Bitte drucken Sie diese Nachricht nicht aus und helfen Sie so Logica dabei die Umwelt zu schuetzen / Por favor ajude a Logica a respeitar o ambiente não imprimindo este correio electrónico. This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Signature verification fails with block type is not 01
Hello, I used the below mentioned test program. Theses were the results from the same. There was a core file created. The pstack of core is shown below. bash-2.03# openssl genrsa -out rsa.pem 2048 Generating RSA private key, 2048 bit long modulus .^C bash-2.03# cksum openssl 3693318708 2633912 openssl bash-2.03# ldd openssl libsocket.so.1 =/usr/lib/libsocket.so.1 libnsl.so.1 = /usr/lib/libnsl.so.1 libdl.so.1 =/usr/lib/libdl.so.1 libc.so.1 = /usr/lib/libc.so.1 libmp.so.2 =/usr/lib/libmp.so.2 /usr/platform/SUNW,Sun-Fire-280R/lib/libc_psr.so.1 bash-2.03# ls -l /usr/lib/libsocket.so.1 /usr/lib/libnsl.so.1 /usr/lib/libc.so.1 /usr/lib/libmp.so.2 /usr/platform/SUNW,Sun-Fire-280R/lib/libc_psr.so.1 -rwxr-xr-x 1 root bin 1158072 Jul 31 2006 /usr/lib/libc.so.1 -rwxr-xr-x 1 root bin24968 Jan 6 2000 /usr/lib/libmp.so.2 -rwxr-xr-x 1 root bin 920100 Jul 31 2006 /usr/lib/libnsl.so.1 -rwxr-xr-x 1 root bin70864 Nov 3 2001 /usr/lib/libsocket.so.1 lrwxrwxrwx 1 root root 33 Oct 3 2006 /usr/platform/SUNW,Sun-Fire-280R/lib/libc_psr.so.1 - ../../sun4u-us3/lib/libc_psr.so.1 bash-2.03# ls -la total 6000 drwxr-xr-x 2 root other646 Oct 17 04:50 . drwxr-xr-x 3 root other385 Oct 17 04:45 .. -rw--- 1 root other 383792 Oct 17 04:50 core -rw-r--r-- 1 root other 0 Oct 17 04:50 file.sig -rw-r--r-- 1 root other 15 Oct 17 04:50 file.txt -rwxr-xr-x 1 root other2633912 Oct 15 20:01 openssl -rw-r--r-- 1 root other 0 Oct 17 04:47 rsa.pem -rw-r--r-- 1 root other350 Oct 15 20:02 test_client.sh -rwxr-xr-x 1 root other 2332 Oct 15 20:01 test_rsa.sh -rw-r--r-- 1 root other 2097 Oct 15 20:01 test_server.sh bash-2.03# pstack core core 'core' of 7979:openssl genrsa -out rsa.pem 2048 000b5428 bn_mul_add_words (1f4ea8, 1ec470, 8, 7b55419a, 6432bff9, 5f6d1513) + 94 000b7f80 BN_from_montgomery (1eb76c, 1ec420, 1f, 1eb648, 0, 0) + 1bc 000b7d84 BN_mod_mul_montgomery (1eb76c, 1eb76c, 1eb76c, 1ec3d0, 1eb648, 0) + 68 00152178 BN_mod_exp_mont (1eb744, 161, 1eb730, 0, 1eb648, 1ec3d0) + 398 000b4e7c BN_is_prime_fasttest_ex (1db508, , 1eb648, 1db508, ffbef684, 3) + 41c 000b48d8 BN_generate_prime_ex (0, 400, 0, 0, 0, ffbef684) + 2c8 000c4908 rsa_builtin_keygen (1e10f0, 800, 1db468, ffbef684, 400, 1) + 1ec 0004fb44 genrsa_main (1, 18e5c4, 1e0148, 10001, ffbefc24, ffbefd38) + 668 000367cc do_cmd (1e0f60, 4, ffbefc18, f, 1e0fe8, 36ba4) + 40 0003657c main (5, ffbefc14, 1e0f60, ffbefb7c, 1c5010, 1843e0) + 2b0 00036190 _start (0, 0, 0, 0, 0, 0) + 108 bash-2.03# showrev -p |grep 112438 Patch: 112438-02 Obsoletes: Requires: Incompatibles: Packages: SUNWcarx, SUNWcsr, SUNWhea, SUNWmdb, SUNWmdbx Patch: 112438-03 Obsoletes: Requires: Incompatibles: Packages: SUNWcarx, SUNWcsr, SUNWhea, SUNWmdb, SUNWmdbx bash-2.03# uname -a SunOS test.hp.com 5.8 Generic_117350-39 sun4u sparc SUNW,Sun-Fire-280R Regards Ashith -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marek Marcola Sent: Friday, October 12, 2007 11:48 PM To: openssl-users@openssl.org Subject: RE: Signature verification fails with block type is not 01 Hello, Does anyone have a separate test program where we can test only the signature verification? # openssl genrsa -out rsa.pem 2048 # openssl rsa -in rsa.pem -text -noout # openssl rsa -in rsa.pem -pubout -out rsa-pub.pem # openssl rsa -in rsa-pub.pem -pubin -text -noout # echo test test test file.txt # openssl dgst -sign rsa.pem file.txt file.sig # openssl dgst -verify rsa-pub.pem -signature file.sig file.txt Verified OK Best regards, -- Marek Marcola [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Signature verification fails with block type is not 01
Has anyone seen this behavior? Any help would be appreciated. Thanks in advance, Regards Ashith -Original Message- From: Belliappa, Ashith Muddiana (HP Software) Sent: Wednesday, October 17, 2007 11:37 AM To: 'openssl-users@openssl.org' Subject: RE: Signature verification fails with block type is not 01 Hello, I used the below mentioned test program. Theses were the results from the same. There was a core file created. The pstack of core is shown below. bash-2.03# openssl genrsa -out rsa.pem 2048 Generating RSA private key, 2048 bit long modulus .^C bash-2.03# cksum openssl 3693318708 2633912 openssl bash-2.03# ldd openssl libsocket.so.1 =/usr/lib/libsocket.so.1 libnsl.so.1 = /usr/lib/libnsl.so.1 libdl.so.1 =/usr/lib/libdl.so.1 libc.so.1 = /usr/lib/libc.so.1 libmp.so.2 =/usr/lib/libmp.so.2 /usr/platform/SUNW,Sun-Fire-280R/lib/libc_psr.so.1 bash-2.03# ls -l /usr/lib/libsocket.so.1 /usr/lib/libnsl.so.1 /usr/lib/libc.so.1 /usr/lib/libmp.so.2 /usr/platform/SUNW,Sun-Fire-280R/lib/libc_psr.so.1 -rwxr-xr-x 1 root bin 1158072 Jul 31 2006 /usr/lib/libc.so.1 -rwxr-xr-x 1 root bin24968 Jan 6 2000 /usr/lib/libmp.so.2 -rwxr-xr-x 1 root bin 920100 Jul 31 2006 /usr/lib/libnsl.so.1 -rwxr-xr-x 1 root bin70864 Nov 3 2001 /usr/lib/libsocket.so.1 lrwxrwxrwx 1 root root 33 Oct 3 2006 /usr/platform/SUNW,Sun-Fire-280R/lib/libc_psr.so.1 - ../../sun4u-us3/lib/libc_psr.so.1 bash-2.03# ls -la total 6000 drwxr-xr-x 2 root other646 Oct 17 04:50 . drwxr-xr-x 3 root other385 Oct 17 04:45 .. -rw--- 1 root other 383792 Oct 17 04:50 core -rw-r--r-- 1 root other 0 Oct 17 04:50 file.sig -rw-r--r-- 1 root other 15 Oct 17 04:50 file.txt -rwxr-xr-x 1 root other2633912 Oct 15 20:01 openssl -rw-r--r-- 1 root other 0 Oct 17 04:47 rsa.pem -rw-r--r-- 1 root other350 Oct 15 20:02 test_client.sh -rwxr-xr-x 1 root other 2332 Oct 15 20:01 test_rsa.sh -rw-r--r-- 1 root other 2097 Oct 15 20:01 test_server.sh bash-2.03# pstack core core 'core' of 7979:openssl genrsa -out rsa.pem 2048 000b5428 bn_mul_add_words (1f4ea8, 1ec470, 8, 7b55419a, 6432bff9, 5f6d1513) + 94 000b7f80 BN_from_montgomery (1eb76c, 1ec420, 1f, 1eb648, 0, 0) + 1bc 000b7d84 BN_mod_mul_montgomery (1eb76c, 1eb76c, 1eb76c, 1ec3d0, 1eb648, 0) + 68 00152178 BN_mod_exp_mont (1eb744, 161, 1eb730, 0, 1eb648, 1ec3d0) + 398 000b4e7c BN_is_prime_fasttest_ex (1db508, , 1eb648, 1db508, ffbef684, 3) + 41c 000b48d8 BN_generate_prime_ex (0, 400, 0, 0, 0, ffbef684) + 2c8 000c4908 rsa_builtin_keygen (1e10f0, 800, 1db468, ffbef684, 400, 1) + 1ec 0004fb44 genrsa_main (1, 18e5c4, 1e0148, 10001, ffbefc24, ffbefd38) + 668 000367cc do_cmd (1e0f60, 4, ffbefc18, f, 1e0fe8, 36ba4) + 40 0003657c main (5, ffbefc14, 1e0f60, ffbefb7c, 1c5010, 1843e0) + 2b0 00036190 _start (0, 0, 0, 0, 0, 0) + 108 bash-2.03# showrev -p |grep 112438 Patch: 112438-02 Obsoletes: Requires: Incompatibles: Packages: SUNWcarx, SUNWcsr, SUNWhea, SUNWmdb, SUNWmdbx Patch: 112438-03 Obsoletes: Requires: Incompatibles: Packages: SUNWcarx, SUNWcsr, SUNWhea, SUNWmdb, SUNWmdbx bash-2.03# uname -a SunOS test.hp.com 5.8 Generic_117350-39 sun4u sparc SUNW,Sun-Fire-280R Regards Ashith -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marek Marcola Sent: Friday, October 12, 2007 11:48 PM To: openssl-users@openssl.org Subject: RE: Signature verification fails with block type is not 01 Hello, Does anyone have a separate test program where we can test only the signature verification? # openssl genrsa -out rsa.pem 2048 # openssl rsa -in rsa.pem -text -noout # openssl rsa -in rsa.pem -pubout -out rsa-pub.pem # openssl rsa -in rsa-pub.pem -pubin -text -noout # echo test test test file.txt # openssl dgst -sign rsa.pem file.txt file.sig # openssl dgst -verify rsa-pub.pem -signature file.sig file.txt Verified OK Best regards, -- Marek Marcola [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Signature verification fails with block type is not 01
Hi, We have checked for proper library files usage during the signature verification. Even we have compared the file size of the library used in working and non- working machine and found both are exactly same. Even the checksum matches for the files. In Solaris 5.7 also it works fine. The problem is in only one Solaris 5.8 box. 1) What all shared system library files we need to check which could be the possible reason for getting this error? 2) What are the machine configuration we need to check if that would cause the failure? 3) Is there any specific OS patch that could create an problem? If yes, please let me know. Thanks in advance, Regards Ashith -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of jimmy bahuleyan Sent: Friday, October 12, 2007 5:46 PM To: openssl-users@openssl.org Subject: Re: Signature verification fails with block type is not 01 Belliappa, Ashith Muddiana (HP Software) wrote: Hi, We have complied the code in an Solaris 5.7 machine. We have the same set of binaries working fine in all the Solaris 5.8 machines. I am getting the error ONLY in ONE Solaris 5.8 machine. i believe your saying that the same application code, same set of openssl libraries AND the same signature works on all but one Solaris 5.8. Have you checked that the proper library is picked up on this machine (or if shared libs are used, the proper library is loaded). Could possibly be a machine config issue if all the above hold true.. (I haven't got 5.7 thing. Is it that you have also checked the code on a 5.7 found it to be working properly?) Does anyone have a separate test program where we can test only the signature verification? Regards Ashith -jb -- No snowflake in an avalanche ever feels responsible. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Signature verification fails with block type is not 01
Belliappa, Ashith Muddiana (HP Software) wrote: Hi, We have checked for proper library files usage during the signature verification. Even we have compared the file size of the library used in working and non- working machine and found both are exactly same. Even the checksum matches for the files. In Solaris 5.7 also it works fine. The problem is in only one Solaris 5.8 box. i'm assuming the scenario is: build libs, application on 5.7, test it = works fine. build libs, application on 5.8, test it = works fine except one machine. signature, key is same in all cases. 1) What all shared system library files we need to check which could be the possible reason for getting this error? 2) What are the machine configuration we need to check if that would cause the failure? what I meant was, if your building the application on one particular 5.8 machine and then using it to run on other 5.8s, it could /possibly/ happen that one of the test machines may not have the proper library at the path that you're expecting. If you've already checked all of these, then it shouldn't be a problem. 3) Is there any specific OS patch that could create an problem? If yes, please let me know. Well, wrt to OS patches I assume you're keeping all your machines at the same patch level whatever it maybe. Thanks in advance, Regards Ashith If all of these lead you no where, I'm out of clues. You could probably try debug with the hints provided by Marek earlier. -jb -- No snowflake in an avalanche ever feels responsible. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Signature verification fails with block type is not 01
Hello, We have the same openssl version in both the machines. Still the problem occurs. My proposition was to check private key modulus and public/certificate modulus to be sure that they are the same. Best regards, -- Marek Marcola [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Signature verification fails with block type is not 01
Hello, Does anyone have a separate test program where we can test only the signature verification? # openssl genrsa -out rsa.pem 2048 # openssl rsa -in rsa.pem -text -noout # openssl rsa -in rsa.pem -pubout -out rsa-pub.pem # openssl rsa -in rsa-pub.pem -pubin -text -noout # echo test test test file.txt # openssl dgst -sign rsa.pem file.txt file.sig # openssl dgst -verify rsa-pub.pem -signature file.sig file.txt Verified OK Best regards, -- Marek Marcola [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Signature verification fails with block type is not 01
Belliappa, Ashith Muddiana (HP Software) wrote: Hi, We have complied the code in an Solaris 5.7 machine. We have the same set of binaries working fine in all the Solaris 5.8 machines. I am getting the error ONLY in ONE Solaris 5.8 machine. i believe your saying that the same application code, same set of openssl libraries AND the same signature works on all but one Solaris 5.8. Have you checked that the proper library is picked up on this machine (or if shared libs are used, the proper library is loaded). Could possibly be a machine config issue if all the above hold true.. (I haven't got 5.7 thing. Is it that you have also checked the code on a 5.7 found it to be working properly?) Does anyone have a separate test program where we can test only the signature verification? Regards Ashith -jb -- No snowflake in an avalanche ever feels responsible. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Signature verification fails with block type is not 01
On Fri, Oct 12, 2007, Belliappa, Ashith Muddiana (HP Software) wrote: Hi, We have the same openssl version in both the machines. Still the problem occurs. Do you have the same binaries or did you compile it on both machines? If you compiled it try make test on the failing machine if that fails check compiler versions. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Signature verification fails with block type is not 01
Hi, We have complied the code in an Solaris 5.7 machine. We have the same set of binaries working fine in all the Solaris 5.8 machines. I am getting the error ONLY in ONE Solaris 5.8 machine. Does anyone have a separate test program where we can test only the signature verification? Regards Ashith -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dr. Stephen Henson Sent: Friday, October 12, 2007 4:35 PM To: openssl-users@openssl.org Subject: Re: Signature verification fails with block type is not 01 On Fri, Oct 12, 2007, Belliappa, Ashith Muddiana (HP Software) wrote: Hi, We have the same openssl version in both the machines. Still the problem occurs. Do you have the same binaries or did you compile it on both machines? If you compiled it try make test on the failing machine if that fails check compiler versions. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Signature verification fails with block type is not 01
Hello, We are using openssl 0.9.8d in our environment. In one of the Solaris box we are getting an “block type is not 01” while doing the signature verification. We have compared the openssl (0.9.7l) and openssl (0.9.8d) and found few difference in the signature verification part. We then used openssl 0.9.7l and we get the same error message “block type is not 01. This does occur in only one Solaris box. details of the machine is provided below. If this happens only on one machine and with two different OpenSSL versions then private/public key compatibility may be problem. If you sign with some private key and next you will try to verify with public key not from pair then you will get this error. This error is generated after successful modular exponentation (where public key is used) when try to remove padding is performed. After modular exponentation first byte of result should be 0x01 but is not in this case. Look at private key modulus and public/certificate modulus and check if they are the same. Best regards, -- Marek Marcola [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Signature verification fails with block type is not 01
Hi, We have the same openssl version in both the machines. Still the problem occurs. Regards Ashith -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marek Marcola Sent: Thursday, October 11, 2007 10:14 PM To: openssl-users@openssl.org Subject: Re: Signature verification fails with block type is not 01 Hello, We are using openssl 0.9.8d in our environment. In one of the Solaris box we are getting an block type is not 01 while doing the signature verification. We have compared the openssl (0.9.7l) and openssl (0.9.8d) and found few difference in the signature verification part. We then used openssl 0.9.7l and we get the same error message block type is not 01. This does occur in only one Solaris box. details of the machine is provided below. If this happens only on one machine and with two different OpenSSL versions then private/public key compatibility may be problem. If you sign with some private key and next you will try to verify with public key not from pair then you will get this error. This error is generated after successful modular exponentation (where public key is used) when try to remove padding is performed. After modular exponentation first byte of result should be 0x01 but is not in this case. Look at private key modulus and public/certificate modulus and check if they are the same. Best regards, -- Marek Marcola [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Signature verification fails with block type is not 01
Hi All, We are using openssl 0.9.8d in our environment. In one of the Solaris box we are getting an block type is not 01 while doing the signature verification. We have compared the openssl (0.9.7l) and openssl (0.9.8d) and found few difference in the signature verification part. We then used openssl 0.9.7l and we get the same error message block type is not 01. This does occur in only one Solaris box. details of the machine is provided below. Could someone help us in resolving this issue. If any other details are required please let me know. Details from the machine where the problem occurs consistently: OS: Solaris 5.8 Patch levels: Patch: 108434-13 Obsoletes: Requires: 109147-07 Incompatibles: Packages: SUNWlibC Patch: 108434-18 Obsoletes: Requires: 109147-07 Incompatibles: Packages: SUNWlibC Patch: 108434-21 Obsoletes: Requires: 109147-07 Incompatibles: Packages: SUNWlibC Patch: 108434-22 Obsoletes: Requires: 109147-07 Incompatibles: Packages: SUNWlibC Patch: 108435-13 Obsoletes: Requires: 108434-13 Incompatibles: Packages: SUNWlibCx Patch: 108435-18 Obsoletes: Requires: 108434-17 Incompatibles: Packages: SUNWlibCx Patch: 108435-13 Obsoletes: Requires: 108434-13 Incompatibles: Packages: SUNWlibCx Patch: 108435-18 Obsoletes: Requires: 108434-17 Incompatibles: Packages: SUNWlibCx Patch: 109147-26 Obsoletes: 110791-01 Requires: Incompatibles: Packages: SUNWcsu, SUNWcsr, SUNWcslx, SUNWcsl, SUNWcsxu, SUNWhea, SUNWtoo, SUNWbtool, SUNWarc, SUNWbtoox, SUNWtoox, SUNWosdem Patch: 109147-32 Obsoletes: 110791-01 Requires: Incompatibles: Packages: SUNWcsu, SUNWcsr, SUNWcslx, SUNWcsl, SUNWcsxu, SUNWhea, SUNWtoo, SUNWbtool, SUNWarc, SUNWbtoox, SUNWtoox, SUNWosdem Patch: 108652-88 Obsoletes: 110499-03 Requires: 109147-26 Incompatibles: Packages: SUNWxwfnt, SUNWxwice, SUNWxwplt, SUNWxwman, SUNWxwfa, SUNWxwicx, SUNWxwplx, SUNWxwacx, SUNWxwpmn, SUNWxwdxm, SUNWxwinc, SUNWxwslb Patch: 108434-13 Obsoletes: Requires: 109147-07 Incompatibles: Packages: SUNWlibC Patch: 108434-18 Obsoletes: Requires: 109147-07 Incompatibles: Packages: SUNWlibC Patch: 108434-21 Obsoletes: Requires: 109147-07 Incompatibles: Packages: SUNWlibC Patch: 108434-22 Obsoletes: Requires: 109147-07 Incompatibles: Packages: SUNWlibC Patch: 111697-04 Obsoletes: Requires: Incompatibles: Packages: SUNWsprot, SUNWsprox, SUNWxcu4t Patch: 114802-01 Obsoletes: Requires: Incompatibles: Packages: SUNWsprot Patch: 114802-02 Obsoletes: Requires: Incompatibles: Packages: SUNWsprot Patch: 111721-04 Obsoletes: Requires: Incompatibles: Packages: SUNWlibms, SUNWlmsx, SUNWlibm NOTE: No other applications are running. Disk space is available and CPU utlisation is normal. Thanks in advance, Regards Ashith
PKCS7 signature verification fails
Hi, I am trying to use openssl to sign documents and store detached signatures in PKCS7 format. First, I sign the document : openssl smime -sign -in document.txt -out document.txt.sign -signer certs/jcr.crt -certfile certs/ca.crt -inkey private/jcr.key When I check the signature, it is OK : openssl smime -verify -CAfile certs/ca.crt -in document.txt.sign /dev/null Verification successful Then I create a PKCS7 structure : openssl smime -pk7out -in document.txt.sign -out document.txt.pkcs7 But the verification fails : openssl smime -verify -CAfile certs/ca.crt -inform PEM -content document.txt -in document.txt.pkcs7 /dev/null Verification failure 30871:error:21071065:PKCS7 routines:PKCS7_signatureVerify:digest failure:pk7_doit.c:928: 30871:error:21075069:PKCS7 routines:PKCS7_verify:signature failure:pk7_smime.c:299: Somebody has an idea of what is wrong ? Thanks, Jean-Claude __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: PKCS7 signature verification fails
On Wed, Feb 07, 2007, Jean-Claude Repetto wrote: Hi, I am trying to use openssl to sign documents and store detached signatures in PKCS7 format. First, I sign the document : openssl smime -sign -in document.txt -out document.txt.sign -signer certs/jcr.crt -certfile certs/ca.crt -inkey private/jcr.key When I check the signature, it is OK : openssl smime -verify -CAfile certs/ca.crt -in document.txt.sign /dev/null Verification successful Then I create a PKCS7 structure : openssl smime -pk7out -in document.txt.sign -out document.txt.pkcs7 But the verification fails : openssl smime -verify -CAfile certs/ca.crt -inform PEM -content document.txt -in document.txt.pkcs7 /dev/null Verification failure 30871:error:21071065:PKCS7 routines:PKCS7_signatureVerify:digest failure:pk7_doit.c:928: 30871:error:21075069:PKCS7 routines:PKCS7_verify:signature failure:pk7_smime.c:299: Somebody has an idea of what is wrong ? The text being signed gets translated into canonical format before the signature is calculated or verificate when the format is SMIME. If you output the content in the working smime -verify command and check the signature against that it should be OK. Alternatively use smime -sign with the -outform PEM and -binary options to generate the signature and no translation will occur. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]