Re: openssl smime verify fails in ASN1_CHECK_TLEN but asn1parse is ok?
On Mon, Aug 27, 2012 at 10:50 PM, Dr. Stephen Henson wrote: On Mon, Aug 27, 2012, GWu wrote: The email is available at http://www.buergerkarte.at/mvnforum/mvnforum/viewthread_thread,272#1180 (German language forum, but the email - or it's significant parts respectively - is easily visble). Well I'm not surprised Thunderbird and OpenSSL has problems with that. The signature is malformed. It should contain the digest enclosed in an ASN1 structure called DigestInfo but it isn't: it just contains the raw digest. Can you give me a hint where to find DigestInfo or the offending raw digest in the result of asn1parse? I can spot messageDigest, which is shown as: 3957:d=7 hl=2 l= 9 prim:OBJECT:messageDigest 3968:d=7 hl=2 l= 22 cons:SET 3970:d=8 hl=2 l= 20 prim: OCTET STRING [HEX DUMP]:38BA6AE720F09EFFB46BC8859293743DD13EDBF0 But this looks very similar in a message which verifies successfully. The asn1parse output of another, successfully verified signature also does not contain DigestInfo. Is DigestInfo a structure inside messageDigest in asn1parse output? If yes, is there a way to display it in structured/readable form? Or did you mean that the content inside of messageDigest is not encoded properly? Thanks for any advice and please excuse my beginner's questions, I'm trying to get a grip on these things ... __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: openssl smime verify fails in ASN1_CHECK_TLEN but asn1parse is ok?
On Tue, Aug 28, 2012, GWu wrote: On Mon, Aug 27, 2012 at 10:50 PM, Dr. Stephen Henson wrote: On Mon, Aug 27, 2012, GWu wrote: The email is available at http://www.buergerkarte.at/mvnforum/mvnforum/viewthread_thread,272#1180 (German language forum, but the email - or it's significant parts respectively - is easily visble). Well I'm not surprised Thunderbird and OpenSSL has problems with that. The signature is malformed. It should contain the digest enclosed in an ASN1 structure called DigestInfo but it isn't: it just contains the raw digest. Can you give me a hint where to find DigestInfo or the offending raw digest in the result of asn1parse? I can spot messageDigest, which is shown as: 3957:d=7 hl=2 l= 9 prim:OBJECT:messageDigest 3968:d=7 hl=2 l= 22 cons:SET 3970:d=8 hl=2 l= 20 prim: OCTET STRING [HEX DUMP]:38BA6AE720F09EFFB46BC8859293743DD13EDBF0 But this looks very similar in a message which verifies successfully. The asn1parse output of another, successfully verified signature also does not contain DigestInfo. Is DigestInfo a structure inside messageDigest in asn1parse output? If yes, is there a way to display it in structured/readable form? Or did you mean that the content inside of messageDigest is not encoded properly? Thanks for any advice and please excuse my beginner's questions, I'm trying to get a grip on these things ... Firsty you need to extract the signer certificate. You can use the smime utility for this by turning off all verification: openssl smime -verify -in message -noverify -nosigs -signer s.pem Then extract the final signature in binary form: in the asn1parse output look for the final OCTET STRING and note its offset (number before the :). Then do: openssl asn1parse -in message -strparse 4440 -noout -out sig.der Where you change 4440 for the right value if you use a different message. Then you do: openssl rsautl -verify -certin -inkey s.pem -in sig.der -hexdump The result should look like this: - ba 80 69 57 62 78 03 d4-57 3c 93 83 b9 86 f1 5a ..iWbx..W.Z 0010 - 35 23 58 3d This isn't a proper DigestInfo structure at all it's just presumably the raw SHA1 hash (as you can see from its length: 20 bytes). A proper DigestInfo would have the initial byte 0x30 (SEQUENCE tag). You could use the -asn1parse option to rsautl instead of -hexdump on a correct signature. 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 smime verify fails in ASN1_CHECK_TLEN but asn1parse is ok?
On Tue, Aug 28, 2012 at 1:07 PM, Dr. Stephen Henson wrote: - ba 80 69 57 62 78 03 d4-57 3c 93 83 b9 86 f1 5a ..iWbx..W.Z 0010 - 35 23 58 3d This isn't a proper DigestInfo structure at all it's just presumably the raw SHA1 hash (as you can see from its length: 20 bytes). A proper DigestInfo would have the initial byte 0x30 (SEQUENCE tag). You could use the -asn1parse option to rsautl instead of -hexdump on a correct signature. Great, thanks a lot. I've been able to reproduce this on the erroneous messages as well, and a correctly signed message gives for example openssl rsautl -verify -certin -inkey s.pem -in sig.der -asn1parse 0:d=0 hl=2 l= 33 cons: SEQUENCE 2:d=1 hl=2 l= 9 cons: SEQUENCE 4:d=2 hl=2 l= 5 prim: OBJECT:sha1 11:d=2 hl=2 l= 0 prim: NULL 13:d=1 hl=2 l= 20 prim: OCTET STRING - 42 f7 3b c1 41 4f 04 e9-ac f3 4c 1f 33 3f de 73 B.;.AOL.3?.s 0010 - e3 d9 e8 76 ...v Could you confirm which RFC is violated by that missing DigestInfo structure, RFC 2315? I'd like to inform the author of the crypto module that their output isn't correct (until now they deny that). Any ideas why Outlook (for example) accepts this malformed signature? Is there some alternate RFC/RFC version/format/..., which allows this kind of raw data (or is it maybe just more fault tolerant on the structure)? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
EVP_CIPHER_CTX_set_key_length and EVP_CIPHER_key_length
Hi all I created a shared key based on a DH exchange and want to use that key with a symmetric encryption algorithm. This key has a length of 16 Bytes (128 bit). Here is what I do to initialize AES: char *key,*iv; // DH exchange which ends with a 16B value in key RAND_pseudo_bytes(iv,16); EVP_EncryptInit(enc_ctx,EVP_aes_128_cbc(),NULL,NULL); EVP_CIPHER_CTX_set_key_length(enc_ctx,16); EVP_EncryptInit(enc_ctx,NULL,skey,iv); None of the functions seems to generate an error. I checked that by calling ERR_print_errors_fp. However when I check the key length printf(key len: %d\n,EVP_CIPHER_key_length(enc_ctx)); It returns 1. Shouldn't it return 16? I guess I make a mistake when setting the key, but where? best regards Carolin __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Server key issue. need Urgent Help on it
Sorry for the stupid questions, but - does this file exist on your machine (and there is no typo in the name)? - and does it have meaningful content (a key)? Dear All, I have installed OpenSSL and faces this given below error when try to tun apache server. Kindly advice me on this, how to correct it root@zeroshell root /etc/init.d/httpd start Starting httpd daemon... Syntax error on line 121 of /etc/httpd/conf/ssl.conf: SSLCertificateKeyFile: file '/etc/httpd/conf/ssl.key/server.key' does not exist or is empty I am looking forward to you about this error Best Regards, Jamshed Alam __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Server key issue. need Urgent Help on it
This means you need to create a key pair (private key with no password + X509 certficate) for apache to use. Some linux distributions sometimes include a dummy key pair just for testing. On Fedora Core 14 these is a /etc/pki/tls/certs/make-dummy-cert command. On 08/28/12 07:21, Jamshed Alam wrote: Dear All, I have installed OpenSSL and faces this given below error when try to tun apache server. Kindly advice me on this, how to correct it root@zeroshell root /etc/init.d/httpd start Starting httpd daemon... Syntax error on line 121 of /etc/httpd/conf/ssl.conf: SSLCertificateKeyFile: file '/etc/httpd/conf/ssl.key/server.key' does not exist or is empty I am looking forward to you about this error Best Regards, Jamshed Alam __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: openssl smime verify fails in ASN1_CHECK_TLEN but asn1parse is ok?
On Tue, Aug 28, 2012, GWu wrote:
Great, thanks a lot. I've been able to reproduce this on the erroneous
messages as well, and a correctly signed message gives for example
openssl rsautl -verify -certin -inkey s.pem -in sig.der -asn1parse
0:d=0 hl=2 l= 33 cons: SEQUENCE
2:d=1 hl=2 l= 9 cons: SEQUENCE
4:d=2 hl=2 l= 5 prim: OBJECT:sha1
11:d=2 hl=2 l= 0 prim: NULL
13:d=1 hl=2 l= 20 prim: OCTET STRING
- 42 f7 3b c1 41 4f 04 e9-ac f3 4c 1f 33 3f de 73
B.;.AOL.3?.s
0010 - e3 d9 e8 76 ...v
Could you confirm which RFC is violated by that missing DigestInfo
structure, RFC 2315?
I'd like to inform the author of the crypto module that their output
isn't correct (until now they deny that).
Well the RSA scheme used is mentioned in the PKCS#1 specification see the
comments about the EMSA-PKCS1-v1_5 operation.
Any ideas why Outlook (for example) accepts this malformed signature?
Is there some alternate RFC/RFC version/format/..., which allows this
kind of raw data (or is it maybe just more fault tolerant on the
structure)?
I think it is the latter: it just tolerates the raw form.
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: EVP_CIPHER_CTX_set_key_length and EVP_CIPHER_key_length
On Tue, Aug 28, 2012, la...@angry-red-pla.net wrote: Hi all I created a shared key based on a DH exchange and want to use that key with a symmetric encryption algorithm. This key has a length of 16 Bytes (128 bit). Here is what I do to initialize AES: char *key,*iv; // DH exchange which ends with a 16B value in key RAND_pseudo_bytes(iv,16); EVP_EncryptInit(enc_ctx,EVP_aes_128_cbc(),NULL,NULL); EVP_CIPHER_CTX_set_key_length(enc_ctx,16); EVP_EncryptInit(enc_ctx,NULL,skey,iv); None of the functions seems to generate an error. I checked that by calling ERR_print_errors_fp. However when I check the key length printf(key len: %d\n,EVP_CIPHER_key_length(enc_ctx)); It returns 1. Shouldn't it return 16? I guess I make a mistake when setting the key, but where? The cipher EVP_aes_128_cbc() has a fixed key length so there is no need to set it, though it is harmless to do so. The function EVP_CIPHER_key_length works on an EVP_CIPHER structure not an EVP_CIPHER_CTX. You need to call EVP_CIPHER_CTX_key_length instead. 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
