Re: Sign with PKCS8
Dear Dave, Thank you for your response! On 2013-06-27 6:21, Dave Thompson wrote: From: owner-openssl-us...@openssl.org On Behalf Of Lukas Haase Sent: Tuesday, 25 June, 2013 19:13 I have the public and the private key for ECDSA on secp128r1 in a file stored in PKCS8 format (saved with Crypto++; it is PKCS8 according to the Docu). I can create a signature without an error but unfortunately it is not validated successfully with my Crypto++ app: $ cat testakt.txt | openssl dgst -ecdsa-with-SHA1 -sign test.key -keyform DER act.bin I think I found the problem but I am unsure how to deal with it :-( There are two ways to create a signature: The original message can be part of the signature (put=true) or not (put=false). In the first case, the signature gets larger (this is what I observe, the signature is not exactly 32 Bytes) and only the signature needs to be presented to the verifier. In the latter case, the concatenation message|signature needs to be presented [1]. I use put=false in my application because I aim for a signature as short as possible (used for product activation in my software). openssl dgst -sign unfortunately uses the put=true When I rewrite my software to accept put=true it works so I am sure that this is the issue. Is there an easy way to convert the openssl output to the second method by stripping off the data somehow, leaving *only* the signature? I looked at -sigopt but this does not provide an option for that. On the other hand, if I want to check a signature, I cannot even open the (public) key file: $ cat testakt.txt | openssl dgst -sha1 -verify activation.pub -signature act.bin unable to load key file What exactly is in activation.pub? If it's a public-key-only (aka public half, suitable for distribution), it can't be PKCS8; the most common format for public is X.509 SubjectPublicKeyInfo, which openssl calls PUBKEY. You are right, it is X509 [2]. If that file is PUBKEY in PEM that command should work; if it is PUBKEY in DER you need -keyform der; [...] Yes, -keyform der was missing. Thank you! Regards, Luke [1] http://www.cryptopp.com/wiki/SignerFilter [2] http://www.cryptopp.com/wiki/Keys_and_Formats __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Sign with PKCS8
From: owner-openssl-us...@openssl.org On Behalf Of Lukas Haase Sent: Thursday, 27 June, 2013 04:46 snip previous I think I found the problem but I am unsure how to deal with it :-( There are two ways to create a signature: The original message can be part of the signature (put=true) or not (put=false). In the first case, the signature gets larger (this is what I observe, the signature is not exactly 32 Bytes) and only the signature needs to be presented to the verifier. In the latter case, the concatenation message|signature needs to be presented [cite to cryptopp]. That doesn't make sense. The ECDSA signature format in openssl (also DSA) is an ASN.1 encoding; it is almost never 32 bytes for a p-128 curve. It contains two values normally the size of the curve order (for DSA the subgroup) but maybe smaller with low probability, plus overhead from 6-11 bytes seemingly at random. It does not include the data and does not get longer for long data, as you can easily test. Simply concatenating data+signature (or || commonly is concatenation but | is not) can't work for variable length signatures as above and variable data as is almost always required. Possibly cryptopp is using a nonstandard fixed-size encoding for (these?) signatures, in which case the signature does remain the same length which could be 32 bytes here and it is only the data that varies in size; or the page you reference says at one point the signature is *prepended* to the message, which is different and could work. I use put=false in my application because I aim for a signature as short as possible (used for product activation in my software). openssl dgst -sign unfortunately uses the put=true When I rewrite my software to accept put=true it works so I am sure that this is the issue. Is there an easy way to convert the openssl output to the second method by stripping off the data somehow, leaving *only* the signature? I don't know what you're looking at, but as above openssl dgst (and EVP_Sign*) doesn't do what you say. openssl elsewhere does support the standard PKCS7/CMS/SMIME format(s) for data plus signature(s!), but those are quite a bit more complicated (and even in minimal case, noticeably bigger) than just concatentation. It also supports several things that use the X.509 SIGNED macro i.e. SEQUENCE of data, algid with possible parameters, and signature, which is simpler and smaller but still more than concatenation. openssl does not directly support XML-DSIG, a newer and even more complicated format. snip rest __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Problem with cipher suite ECDHE-ECDSA-AES256-SHA384
You don't need to change OpenSSL; TLSv1_2_server_method() replaces SSLv23_server_method() in your own code. k On Fri, Jun 7, 2013 at 10:17 AM, mehroz mehroz.ashra...@gmail.com wrote: Hi, Could you help where do i need to change the method from TLSv1_2_server_method() to SSLv23_server_method() . Which files(s) need to be addresses? -- View this message in context: http://openssl.6102.n7.nabble.com/Problem-with-cipher-suite-ECDHE-ECDSA-AES256-SHA384-tp42229p45461.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: smime verification failure
From: owner-openssl-us...@openssl.org On Behalf Of Gsandtner Michael Sent: Wednesday, 26 June, 2013 08:27 # openssl smime -verify -in mail.smime -CAfile A-Trust-nQual-03.pem Verification failure 3086427788:error:21071065:PKCS7 routines:PKCS7_signatureVerify: digest failure:pk7_doit.c:1097: 3086427788:error:21075069:PKCS7 routines:PKCS7_verify: signature failure:pk7_smime.c:410: # openssl version OpenSSL 1.0.1e 11 Feb 2013 Any hint locating the problem welcome. I don't see the point in SMIME-signing a timestamp response, which is already CMS-signed by its originator. Be that as it may, it appears to have been done wrong or damaged in transit. messageDigest in signedAttrs has value (hex) DB890D1C3E13C6FBBD85A64370B7C0165B726864 but for SHA1 of the actual (clear-part) data I get 911bf75107d9e75c7b480c4a12340e0164a46c74 -- that's your PKCS7_R_DIGEST_FAILURE at pk7_doit.c:1097. You might see if the sender can send an undetached signature, i.e. SignedData with content embedded; that will be opaque to mail-handlers that know about, and might alter, MIME. Or I note that your .smime as posted has LF=NL line endings throughout, not CRLF as required on the wire for 2822 headers and MIME-part headers, and I believe for S/MIME base64 bodies (which this is) -- openssl processing certainly assumes so. I hope the NLs are a MUA-local feature; if it was actually sent and hashed that way, openssl will compute the canonical hash and thus (practically) never match. Also, the cert chain is incomplete. The signer-id matches the first cert in the SignedData: Serial x04d15b from Issuer C=AT, O=A-Trust Ges. f. Sicherheitssysteme im elektr. Datenverkehr GmbH, OU=a-sign-corporate-light-03, CN=a-sign-corporate-light-03 for Subject: C=AT, O=Bundesamt f\xC3\xBCr Eich- und Vermessungswesen, CN=Signaturdienst BEV/serialNumber=246549429784 which has AKI keyid:41:91:69:1C:BF:AD:D8:98 . (And this cert's key verifies the signedAttrs, although as noted above signedAttrs does not verify the data.) The only other cert in the SignedData, which matches the cert you attached as your -CAfile, is a root for C=AT, O=A-Trust Ges. f. Sicherheitssysteme im elektr. Datenverkehr GmbH, OU=A-Trust-nQual-03, CN=A-Trust-nQual-03 with SKI 44:6A:95:67:55:79:11:4F . The signer's AIA does offer the needed chain cert, at least apparently so, but openssl won't follow AIA. You'll need to get it yourself and include it in your local truststore (CAfile and/'or CApath). Or of course get the sender to supply the complete chain. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
AW: smime verification failure
Probably really damaged in transit. The empty attachment should not be empty too. But the CA chain is complete and correct: there is a CA certificate present with required AKI 44:6A:95:67:55:79:11:4F and SKI 41:91:69:1C:BF:AD:D8:98 Specifying the root CA in -CAfile must (and normally really does) suffice. Thanks, Best Regards --Michi -Ursprüngliche Nachricht- Von: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] Im Auftrag von Dave Thompson *EXTERN* Gesendet: Freitag, 28. Juni 2013 05:43 An: openssl-users@openssl.org Betreff: RE: smime verification failure From: owner-openssl-us...@openssl.org On Behalf Of Gsandtner Michael Sent: Wednesday, 26 June, 2013 08:27 # openssl smime -verify -in mail.smime -CAfile A-Trust-nQual-03.pem Verification failure 3086427788:error:21071065:PKCS7 routines:PKCS7_signatureVerify: digest failure:pk7_doit.c:1097: 3086427788:error:21075069:PKCS7 routines:PKCS7_verify: signature failure:pk7_smime.c:410: # openssl version OpenSSL 1.0.1e 11 Feb 2013 Any hint locating the problem welcome. I don't see the point in SMIME-signing a timestamp response, which is already CMS-signed by its originator. Be that as it may, it appears to have been done wrong or damaged in transit. messageDigest in signedAttrs has value (hex) DB890D1C3E13C6FBBD85A64370B7C0165B726864 but for SHA1 of the actual (clear-part) data I get 911bf75107d9e75c7b480c4a12340e0164a46c74 -- that's your PKCS7_R_DIGEST_FAILURE at pk7_doit.c:1097. You might see if the sender can send an undetached signature, i.e. SignedData with content embedded; that will be opaque to mail-handlers that know about, and might alter, MIME. Or I note that your .smime as posted has LF=NL line endings throughout, not CRLF as required on the wire for 2822 headers and MIME-part headers, and I believe for S/MIME base64 bodies (which this is) -- openssl processing certainly assumes so. I hope the NLs are a MUA-local feature; if it was actually sent and hashed that way, openssl will compute the canonical hash and thus (practically) never match. Also, the cert chain is incomplete. The signer-id matches the first cert in the SignedData: Serial x04d15b from Issuer C=AT, O=A-Trust Ges. f. Sicherheitssysteme im elektr. Datenverkehr GmbH, OU=a-sign-corporate-light-03, CN=a-sign-corporate-light-03 for Subject: C=AT, O=Bundesamt f\xC3\xBCr Eich- und Vermessungswesen, CN=Signaturdienst BEV/serialNumber=246549429784 which has AKI keyid:41:91:69:1C:BF:AD:D8:98 . (And this cert's key verifies the signedAttrs, although as noted above signedAttrs does not verify the data.) The only other cert in the SignedData, which matches the cert you attached as your -CAfile, is a root for C=AT, O=A-Trust Ges. f. Sicherheitssysteme im elektr. Datenverkehr GmbH, OU=A-Trust-nQual-03, CN=A-Trust-nQual-03 with SKI 44:6A:95:67:55:79:11:4F . The signer's AIA does offer the needed chain cert, at least apparently so, but openssl won't follow AIA. You'll need to get it yourself and include it in your local truststore (CAfile and/'or CApath). Or of course get the sender to supply the complete chain. __ 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
Crash observed
Hello Openssl team,
Does any of you faced an issue while freeing the SSL_CTX?
Following is the backtrace found. But we are not yet sure which address is
being passed to SSL_CTX_free(). We are trying to get the crashinfo file and
trying to debug.
Meanwhile, if any of you faced similar issue please provide how you guys
have solved it.
Currently we are using openssl0.9.8q version. Does this version has any
problem in this area and any upgraded version fixed these issues? Please
let us know.
Your help is highly required.
% 0x3b197ea : __be_SSL_CTX_free + 202 (self)
1645 void SSL_CTX_free(SSL_CTX *a)
1646 {
1687 sk_SSL_CIPHER_free(a-cipher_list);
1688 if (a-cipher_list_by_id != NULL)
---
% 0x3adf8e0 : __be_sk_free + 48 (self)
303 void sk_free(STACK *st)
304 {
305 if (st == NULL) return;
306 if (st-data != NULL) OPENSSL_free(st-data);
307 OPENSSL_free(st);
308 }
309
--
-
% 0x3ad4368 : __be_CRYPTO_free + 56 (self)
404 void CRYPTO_free(void *str)
405 {
406 if (free_debug_func != NULL)
407 free_debug_func(str, 0);
408 #ifdef LEVITTE_DEBUG_MEM
409 fprintf(stderr, LEVITTE_DEBUG_MEM: 0x%p\n, str);
410 #endif
411 free_func(str); should be crashing here
412 if (free_debug_func != NULL)
413 free_debug_func(NULL, 1);
414 }
static void (*free_func)(void *) = free;
