Re: [EXTERNAL] Using openssl-rsautl for verifying signatures.
Please look at demos/signature/rsa_pss_direct.c If you want to use the old PKCS1 v1.5 padding then just replace RSA_PKCS1_PSS_PADDING with RSA_PKCS1_PADDING. Tomas On Thu, 2022-05-05 at 10:35 -0600, Philip Prindeville wrote: > Bonjour. Et milles mercis. > > That was helpful. > > One more question: if I want to reproduce RSA_sign() (and > RSA_verify()) using evp_key_sign() and evp_key_verify() then I'll > need add code to do the ASN.1 marshaling, right? There's no > convenience function to do that (seems like an oversight if that's > the case)? > > -Philip > > > > On May 4, 2022, at 3:45 AM, Erwann Abalea > > wrote: > > > > Bonjour, > > > > The ASN.1 structure (it's a DigestInfo) is part of the PKCS#1 v1.5 > > padding for signature operations. > > PKCS#1v1.5 is rewritten in RFC2313. > > > > Using the command line tool, you can reproduce this: > > > > echo -n "Mary had a little lamb." > datatosign > > > > either one of the following can be used to sign data: > > openssl dgst -sha1 -sign tests/keys/rsa_key1.key datatosign > > > signing > > openssl pkeyutl -inkey tests/keys/rsa_key1.key -in <(openssl dgst > > -sha1 -binary datatosign) -sign -pkeyopt digest:sha1 > signing > > > > and you can display the signature either way (this will not > > "verify", it will only perform the RSA verify operation with > > PKCS#1v1.5 padding, without checking the validity or even if what > > has been signed is a DigestInfo structure, and output the result of > > the RSA operation): > > openssl rsautl -verify -inkey tests/keys/rsa_key1.pub -pubin -in > > signing -asn1parse > > openssl pkeyutl -verifyrecover -inkey tests/keys/rsa_key1.pub - > > pubin -in signing -asn1parse > > > > or you can actually verify the thing without displaying the result > > of the RSA verify crypto operation: > > openssl pkeyutl -verify -inkey tests/keys/rsa_key1.pub -pubin -in > > <(openssl dgst -sha1 -binary datatosign) -sigfile signing -pkeyopt > > digest:sha1 > > openssl dgst -verify tests/keys/rsa_key1.pub -signature signing - > > sha1 datatosign > > > -- Tomáš Mráz, OpenSSL
SSL server send packet FIN than data user.More the client answer with RST packet
After establishing a secure connection between my SSL server and SSL client with OpenSSL library installed on separate Linux hosts, the SSL server send the packet FIN than the user data. The use of ssldump command indicates the presence of the following traces: TCP: dc01dshared1p(2524) -> dc01dadaperf1p.atempo.dev(50814) Seq 2822753961.(0) ACK 136721005 FIN 1057311.4840 (57311.0739) S>C TCP FIN They mean SSL server send end of send data (FIN packet). On the packet FIN, the client sends RST packet TCP: dc01dadaperf1p.atempo.dev(50814) -> dc01dshared1p(2524) Seq 136721005.(0) ACK 2822753962 RST 1057311.6295 (0.1454) C>S TCP RST Can you help me to known why the SSL server send FIN then data user and to resolve the problem? Best regards;
Re: [EXTERNAL] Using openssl-rsautl for verifying signatures.
Bonjour. Et milles mercis. That was helpful. One more question: if I want to reproduce RSA_sign() (and RSA_verify()) using evp_key_sign() and evp_key_verify() then I'll need add code to do the ASN.1 marshaling, right? There's no convenience function to do that (seems like an oversight if that's the case)? -Philip > On May 4, 2022, at 3:45 AM, Erwann Abalea wrote: > > Bonjour, > > The ASN.1 structure (it's a DigestInfo) is part of the PKCS#1 v1.5 padding > for signature operations. > PKCS#1v1.5 is rewritten in RFC2313. > > Using the command line tool, you can reproduce this: > > echo -n "Mary had a little lamb." > datatosign > > either one of the following can be used to sign data: > openssl dgst -sha1 -sign tests/keys/rsa_key1.key datatosign > signing > openssl pkeyutl -inkey tests/keys/rsa_key1.key -in <(openssl dgst -sha1 > -binary datatosign) -sign -pkeyopt digest:sha1 > signing > > and you can display the signature either way (this will not "verify", it will > only perform the RSA verify operation with PKCS#1v1.5 padding, without > checking the validity or even if what has been signed is a DigestInfo > structure, and output the result of the RSA operation): > openssl rsautl -verify -inkey tests/keys/rsa_key1.pub -pubin -in signing > -asn1parse > openssl pkeyutl -verifyrecover -inkey tests/keys/rsa_key1.pub -pubin -in > signing -asn1parse > > or you can actually verify the thing without displaying the result of the RSA > verify crypto operation: > openssl pkeyutl -verify -inkey tests/keys/rsa_key1.pub -pubin -in <(openssl > dgst -sha1 -binary datatosign) -sigfile signing -pkeyopt digest:sha1 > openssl dgst -verify tests/keys/rsa_key1.pub -signature signing -sha1 > datatosign >
Re: X509_STORE_CTX object doubt
On 05/05/2022 13:02, Srinivas, Saketh (c) wrote: Hi, for X509_STORE_CTX object we have a function X509_STORE_CTX_set_cert to set the cert pointer (x509* cert) is there any get function for this variable. X509_STORE_CTX_get_current_cert**is not for cert. Because, there is another variable current_cert. X509_STORE_CTX_get0_cert() does this: https://www.openssl.org/docs/man3.0/man3/X509_STORE_CTX_get0_cert.html Matt thanks, Saketh. Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.
X509_STORE_CTX object doubt
Hi, for X509_STORE_CTX object we have a function X509_STORE_CTX_set_cert to set the cert pointer (x509* cert) is there any get function for this variable. X509_STORE_CTX_get_current_cert is not for cert. Because, there is another variable current_cert. thanks, Saketh. Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.
