Re: Updating RSA public key generation and signature verification from 1.1.1 to 3.0

2022-10-01 Thread Tomas Mraz
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

2022-09-30 Thread GonzalezVillalobos, Diego via openssl-users
[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

2022-09-30 Thread Michael Wojcik via openssl-users
> 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

2022-09-30 Thread Tomas Mraz
 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

2022-09-29 Thread GonzalezVillalobos, Diego via openssl-users
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

2022-09-29 Thread Tomas Mraz
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

2022-09-28 Thread GonzalezVillalobos, Diego via openssl-users
// 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

2022-09-23 Thread Tomas Mraz
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

2022-09-22 Thread GonzalezVillalobos, Diego via openssl-users
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

2022-09-09 Thread Tomas Mraz
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

2022-09-08 Thread GonzalezVillalobos, Diego via openssl-users
[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

2019-07-16 Thread Ying
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

2019-07-16 Thread Ying
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

2018-08-29 Thread Siti Rafidah


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

2018-08-29 Thread Viktor Dukhovni



> 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

2018-08-29 Thread Linta Maria
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

2018-08-29 Thread Viktor Dukhovni


> 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

2018-08-28 Thread Linta Maria
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

2018-08-28 Thread Viktor Dukhovni
[ 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

2018-08-28 Thread Linta Maria
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

2018-08-28 Thread Nicola
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

2018-08-28 Thread Linta Maria
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

2017-10-19 Thread Salz, Rich via openssl-users

➢   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

2017-10-19 Thread Wouter Verhelst
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

2017-10-18 Thread Salz, Rich via openssl-users
➢ 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

2017-10-18 Thread Wouter Verhelst
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

2016-01-06 Thread Wouter Verhelst

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

2015-12-09 Thread Wouter Verhelst

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

2015-12-01 Thread Verhelst Wouter (Consultant)
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

2015-07-14 Thread Jakob Bohm

(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

2015-07-11 Thread Michael Wojcik
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

2015-06-23 Thread Marco Warga

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

2015-06-23 Thread Jakob Bohm
 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

2015-06-22 Thread 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 
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

2015-06-20 Thread Marco Warga

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

2013-06-26 Thread anand rao
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

2013-06-20 Thread anand rao
 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

2013-06-20 Thread Dr. Stephen Henson
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

2013-06-18 Thread Wim Lewis

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

2013-06-14 Thread anand rao


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

2013-05-24 Thread Lavanya
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

2012-11-23 Thread Dave Thompson
 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

2012-11-22 Thread dwipin
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

2012-11-22 Thread dwipin
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)

2012-10-09 Thread Rune K. Svendsen

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)

2012-10-09 Thread Bodo Moeller
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”

2012-06-07 Thread Lunar Mushrooms
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”

2012-06-07 Thread Lunar Mushrooms
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”

2012-06-07 Thread Ken Goldman

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

2011-10-19 Thread Kenneth Goldman
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

2011-10-18 Thread TSCOconan

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

2011-10-18 Thread Dave Thompson
 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

2011-10-05 Thread brajan

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

2011-10-05 Thread brajan



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

2011-10-05 Thread brajan



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

2011-10-05 Thread Jakob Bohm

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

2011-10-04 Thread brajan

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

2011-10-04 Thread Jakob Bohm

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

2011-10-04 Thread Jeffrey Walton
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

2011-10-04 Thread Dave Thompson
 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 ..

2011-09-22 Thread brajan

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 ..

2011-09-22 Thread Kenneth Goldman
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

2011-07-19 Thread brajan

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.

2011-05-11 Thread grant murphy
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

2010-03-12 Thread Michel Pittelkow - michael-wessel . de
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

2010-03-12 Thread Dr. Stephen Henson
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

2010-03-12 Thread Michel Pittelkow - michael-wessel . de
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

2010-03-12 Thread Michel Pittelkow - michael-wessel . de
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

2010-03-12 Thread Dr. Stephen Henson
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

2010-03-12 Thread Michel Pittelkow - michael-wessel . de
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

2010-03-12 Thread Dr. Stephen Henson
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

2010-03-12 Thread Michel Pittelkow - michael-wessel . de
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

2010-02-06 Thread Jim Welch
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

2010-02-06 Thread Dr. Stephen Henson
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

2009-11-09 Thread Jim Welch

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

2009-11-07 Thread Mounir IDRASSI

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

2009-02-01 Thread Ajeet kumar.S

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

2009-01-30 Thread Dave Thompson
 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

2009-01-29 Thread Ajeet kumar.S
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

2009-01-23 Thread Emanuele Cesena
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

2009-01-23 Thread Young, Alistair
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

2009-01-23 Thread Young, Alistair
... 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

2009-01-23 Thread Emanuele Cesena
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

2009-01-23 Thread Dr. Stephen Henson
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

2009-01-23 Thread Young, Alistair
-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

2009-01-19 Thread Young, Alistair
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

2007-10-17 Thread Belliappa, Ashith Muddiana (HP Software)
 
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

2007-10-17 Thread Belliappa, Ashith Muddiana (HP Software)
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

2007-10-15 Thread Belliappa, Ashith Muddiana (HP Software)
 
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

2007-10-15 Thread jimmy bahuleyan
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

2007-10-12 Thread Marek Marcola
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

2007-10-12 Thread Marek Marcola
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

2007-10-12 Thread jimmy bahuleyan
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

2007-10-12 Thread Dr. Stephen Henson
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

2007-10-12 Thread Belliappa, Ashith Muddiana (HP Software)
 
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

2007-10-11 Thread Marek Marcola
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

2007-10-11 Thread Belliappa, Ashith Muddiana (HP Software)
 
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

2007-10-10 Thread Belliappa, Ashith Muddiana (HP Software)
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

2007-02-07 Thread Jean-Claude Repetto
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

2007-02-07 Thread Dr. Stephen Henson
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]


  1   2   >