Re: [openssl-users] Need more information on CVE-2016-2842
Thanks for the information Matt. Regards Sandeep From: Matt CaswellTo: openssl-users@openssl.org Date: 04/12/2016 12:44 AM Subject:Re: [openssl-users] Need more information on CVE-2016-2842 Sent by:"openssl-users" On 11/04/16 19:12, Sandeep Umesh wrote: > Hello > > Can someone please provide more information on CVE-2016-2842? Is this > different from CVE-2016-0799 ? Looks like this CVE information is not > captured in the advisory - > _http://openssl.org/news/secadv/20160301.txt_ > > Also, does this below patch fixes both CVE-2016-2842 and CVE-2016-0799 - > _https://git.openssl.org/?p=openssl.git;a=commit;h=578b956fe741bf8e84055547b1e83c28dd902c73_ CVE-2016-2842 is an identifier that was not issued by the OpenSSL Project and hence does not appear in the security advisory. The OpenSSL Project assigned CVE-2016-0799 and gave it the description as it appears in the advisory. Another organisation decided to split that into two different CVEs and assigned CVE-2016-2842. Whether you think of it as one CVE or two, the fix is the same, i.e. the commit that you identified fixes both. Matt -- 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] Are double-quotes valid characters in certifcates/keys?
On 11/04/2016 18:57, Salz, Rich wrote: You can merge the two files into one. As long as they are in PEM format, it will just work. Except when you want more people (usually everybody) access to the CRT, but few people (usually one or two trusted server processes) access to the private KEY. Then using two different files will make a lot of sense. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://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] Question about timestamps
My point was that the -text output would *show* you if the missing certs were included in the time stamp response somewhere, and where. If they are indeed inside the response, then the question would be why the "openssl ts -verify" command didn't find them automatically. If they are not inside the response, then the question would be why Symantec didn't include them like other tsa-s do. On 08/04/2016 22:36, Alex Samad wrote: Hi Yep I have tried the output to text. but does that verify the signature. So what I think I have now is my data to be signed I make a request send the request to the tsa the tsa signs it adds signature I have response. Now I need to verify it openssl ts -verify -data SHA.sha -in SHA.sha.tsr but it seems to fail, I presume (newbie), because I don't have the intermediary certs . I presume symantec have signed it with a cert thats rooted in one of their main CA's and I presume for me to verify I need the intermediaries or atleast the sign cert's ca. I have looked on symantecs site to no available and I am working on guess work here On 8 April 2016 at 16:26, Jakob Bohmwrote: Try something like $OPENSSL ts -reply -in ${FL}.tsr -text -noout (Not sure if it accepts the -noout option or not). On 08/04/2016 08:01, Alex Samad wrote: Okay, how do I dump the intermediaries then ? On 8 April 2016 at 15:49, Jakob Bohm wrote: On 08/04/2016 07:39, Alex Samad wrote: Hi I am trying to use a rfc3161 timestamp service to record timestamps. Basically I have a sha of some files and I would like to sign the file. basically I am using something like this # Generate Query and send $OPENSSL ts -query -data "$FL" -sha256 | $CURL -s -H "Content-Type:application/timestamp-query" --data-binary "@-" $TSA > "${FL}.tsr" $OPENSSL ts -reply -in "${FL}.tsr" -text > "${FL}.ts.txt" where FL = is file. What I want to be able to do is verify the .tsr file testing that with openssl ts -verify -data SHA.sha -in SHA.sha.tsr where SHA.sha is the original FL but I get Verification: FAILED 140221656393544:error:2107C080:PKCS7 routines:PKCS7_get0_signers:signer certificate not found:pk7_smime.c:476: from the text output cat *.txt Status info: Status: Granted. Status description: unspecified Failure info: unspecified TST info: Version: 1 Policy OID: 2.16.840.1.113733.1.7.23.3 Hash Algorithm: sha256 Message data: - 8c 6d 95 5b e0 cd 8b c9-df 8c ab 57 45 c4 69 e6 .m.[...WE.i. 0010 - 7a b9 ce cb 14 8f 55 25-91 2e 57 37 3e 5c b8 d5 z.U%..W7>\.. Serial number: 0xBEAF663E1CD2F0D029C1A641AD2F9137A5F097C9 Time stamp: Apr 8 04:58:08 2016 GMT Accuracy: 0x1E seconds, unspecified millis, unspecified micros Ordering: no Nonce: 0x8E67A9941BCB2570 TSA: DirName:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec SHA256 TimeStamping Signer - G1 Extensions: I think this certificate is the end entity certificate for the Symantec time stamping server that responded to your request. If you dump the full contents of the TSR it should include that certificate somewhere, plus a chain leading to a public root which is hopefully in your list of trusted certificates or at least available via some other secure method. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://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] Need more information on CVE-2016-2842
On 11/04/16 19:12, Sandeep Umesh wrote: > Hello > > Can someone please provide more information on CVE-2016-2842? Is this > different from CVE-2016-0799 ? Looks like this CVE information is not > captured in the advisory - > _http://openssl.org/news/secadv/20160301.txt_ > > Also, does this below patch fixes both CVE-2016-2842 and CVE-2016-0799 - > _https://git.openssl.org/?p=openssl.git;a=commit;h=578b956fe741bf8e84055547b1e83c28dd902c73_ CVE-2016-2842 is an identifier that was not issued by the OpenSSL Project and hence does not appear in the security advisory. The OpenSSL Project assigned CVE-2016-0799 and gave it the description as it appears in the advisory. Another organisation decided to split that into two different CVEs and assigned CVE-2016-2842. Whether you think of it as one CVE or two, the fix is the same, i.e. the commit that you identified fixes both. Matt -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Need more information on CVE-2016-2842
Hello Can someone please provide more information on CVE-2016-2842? Is this different from CVE-2016-0799 ? Looks like this CVE information is not captured in the advisory - http://openssl.org/news/secadv/20160301.txt Also, does this below patch fixes both CVE-2016-2842 and CVE-2016-0799 - https://git.openssl.org/?p=openssl.git;a=commit;h=578b956fe741bf8e84055547b1e83c28dd902c73 Thanks Regards Sandeep -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Are double-quotes valid characters in certifcates/keys?
You can merge the two files into one. As long as they are in PEM format, it will just work. -- Senior Architect, Akamai Technologies IM: richs...@jabber.at Twitter: RichSalz -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Are double-quotes valid characters in certifcates/keys?
Hi All. Thanks for the help. The certificate is a ".crt.pem". Key is a ".key". Anyhow, earlier I was thinking of saving the certificate+key in a file, where double-quotes were delimiters. But, I have rejected that idea; instead saving them in their respective files :) So, the question becomes obsolete. Anyhow, I am thanks (and sorry at the same time) for everyone's time. Thanks and Regards, Ajay On Mon, Apr 11, 2016 at 8:56 PM, Viktor Dukhovniwrote: > On Mon, Apr 11, 2016 at 10:01:33AM +0530, Ajay Garg wrote: > > [ Subject: Are double-quotes valid characters in certifcates/keys? ] > >> Could not find a definitive answer on google, so thought it would be >> best to ask the experts :) > > The question is ill-formed. Are you asking about allowed characters > in some field of the underlying canonical ASN.1 DER form of a > certificate, or about some particular encoding of the certificate > (e.g. PEM)? > > If the former, X.509v3 certificates are complicated objects, which > part of the certificate are you asking about? > > As for keys, in their ASN.1 DER encoding they are "binary" data, > and all octets are a priori valid in a public key. A public key > algorithm that prohibits 0x22 seems unlikely. > > -- > Viktor. > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- Regards, Ajay -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] FIPS 140-2 web site error
If you neither know nor care what FIPS 140-2 is, this is your lucky day. Avert your eyes and move on, nothing to see here. The entry for the ancestral OpenSSL FIPS Object Module v2.0 validation, #1747, on the NIST CMVP web site appears to be the victim of some sort of clerical error: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#1747 As of the time of this message that entry is showing the vendor as "Cleversafe, an IBM Company" instead of "OpenSSL Software Foundation". That is wrong. I'm assuming random error as April Fool's day is more than a week behind us, and we haven't been offered the bazillion dollars and a pony it would take for us to agree to relinquish that validation. I've asked the accredited test lab to contact the CMVP to correct it. Based on past experience that could take days to weeks. -Steve M. -- Steve Marquess OpenSSL Validation Services, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] openssl-1.1.0 sha1 performance
Afternoon, I have been running some speed tests of openssl 1.0.1, 1.0.2 and 1.1.0 versions against various compiler optimisations. Special interest was given to the more commonly used primitives, rsa's, aes's etc. I noticed that SHA1's have some significant performance improvements. However the multiplier by which it improved by diminishes as you approach 8k/16k block sizes. Any ideas why this tails off? I noticed no other 'statistically significant' change in other primitives, although freely admit i have not exhaustively checked. openssl-1.0.2g-native-speed.txt:Doing sha1 for 3s on 16 size blocks: 9225205 sha1's in 3.00s openssl-1.0.2g-native-speed.txt:Doing sha1 for 3s on 64 size blocks: 7275849 sha1's in 3.00s openssl-1.0.2g-native-speed.txt:Doing sha1 for 3s on 256 size blocks: 4821329 sha1's in 3.00s openssl-1.0.2g-native-speed.txt:Doing sha1 for 3s on 1024 size blocks: 2059373 sha1's in 3.00s openssl-1.0.2g-native-speed.txt:Doing sha1 for 3s on 8192 size blocks: 327032 sha1's in 3.00s openssl-1.1.0-pre4-native-speed.txt:Doing sha1 for 3s on 16 size blocks: 23362218 sha1's in 3.00s openssl-1.1.0-pre4-native-speed.txt:Doing sha1 for 3s on 64 size blocks: 14131714 sha1's in 2.99s openssl-1.1.0-pre4-native-speed.txt:Doing sha1 for 3s on 256 size blocks: 7166139 sha1's in 3.00s openssl-1.1.0-pre4-native-speed.txt:Doing sha1 for 3s on 1024 size blocks: 2413233 sha1's in 3.00s openssl-1.1.0-pre4-native-speed.txt:Doing sha1 for 3s on 8192 size blocks: 335803 sha1's in 3.00s openssl-1.1.0-pre4-native-speed.txt:Doing sha1 for 3s on 16384 size blocks: 169210 sha1's in 3.00s I assume the positive change was part of: *) Extensive assembler packs updates, most notably: - x86[_64]: AES-NI, PCLMULQDQ, RDRAND support; - x86[_64]: SSSE3 support (SHA1, vector-permutation AES); - x86_64: bit-sliced AES implementation; - ARM: NEON support, contemporary platforms optimizations; - s390x:z196 support; - *:GHASH and GF(2^m) multiplication implementations; [Andy Polyakov] Has anyone else completed any similar tests? Thank you, CraigT -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Are double-quotes valid characters in certifcates/keys?
On Mon, Apr 11, 2016 at 10:01:33AM +0530, Ajay Garg wrote: [ Subject: Are double-quotes valid characters in certifcates/keys? ] > Could not find a definitive answer on google, so thought it would be > best to ask the experts :) The question is ill-formed. Are you asking about allowed characters in some field of the underlying canonical ASN.1 DER form of a certificate, or about some particular encoding of the certificate (e.g. PEM)? If the former, X.509v3 certificates are complicated objects, which part of the certificate are you asking about? As for keys, in their ASN.1 DER encoding they are "binary" data, and all octets are a priori valid in a public key. A public key algorithm that prohibits 0x22 seems unlikely. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Received signal SIGSEGV in CRYPTO_add_lock()
Hi, It looks like there is issue in handling crypto locks. I encountered segmentation fault in CRYPTO_add_lock() function referencing NULL pointer. Please find GDB output below, (gdb) run ftp://x.x.x.x:sample.txt Starting program: /App/vikftp ftp://x.x.x.x:sample.txt Missing separate debuginfo for /lib/ld-linux.so.2 Missing separate debuginfo for /lib/libdl.so.2 Missing separate debuginfo for /lib/libpam.so.0 Missing separate debuginfo for /lib/libm.so.6 Missing separate debuginfo for /lib/libc.so.6 Missing separate debuginfo for /lib/libaudit.so.0 process 22287 is executing new program: /App/vikftp Missing separate debuginfo for /lib/ld-linux.so.2 Missing separate debuginfo for /lib/libdl.so.2 Missing separate debuginfo for /lib/libpam.so.0 Missing separate debuginfo for /lib/libm.so.6 Missing separate debuginfo for /lib/libc.so.6 Missing separate debuginfo for /lib/libaudit.so.0 Program received signal SIGSEGV, Segmentation fault. 0x08205766 in CRYPTO_add_lock (pointer=0x1011, amount=-1, type=3, file=0x85d0030 "/102d/s/tasn_utl.c", line=118) at /102d/s/cryptlib.c:624 624 ret = *pointer + amount; (gdb) bt #0 0x08205766 in CRYPTO_add_lock (pointer=0x1011, amount=-1, type=3, file=0x85d0030 "/102d/s/tasn_utl.c", line=118) at /102d/s/cryptlib.c:624 #1 0x08249d2a in asn1_do_lock (pval=0xff8eee90, op=-1, it=0x862cb1c) at /102d/s/tasn_utl.c:118 #2 0x08246ed5 in asn1_item_combine_free (pval=0xff8eee90, it=0x862cb1c, combine=0) at /102d/s/tasn_fre.c:146 #3 0x08246c40 in ASN1_item_free (val=0x1001, it=0x862cb1c) at /102d/s/tasn_fre.c:72 #4 0x0825eeea in X509_free (a=0x1001) at /102d/s/x_x509.c:143 #5 0x082ee677 in ssl_cert_clear_certs (c=0x872e4e0) at /102d/s/ssl_cert.c:431 #6 0x082ee7ed in ssl_cert_free (c=0x872e4e0) at /102d/s/ssl_cert.c:489 #7 0x0822f926 in SSL_free (s=0x872e340) at /102d/s/ssl_lib.c:627 #8 0x0816566c in closeConnection (pcx=0x86d8310, rsn=0x0, graceful=1 '\001') at /App/vikftp.c:10098 Please let me know if you have any solution. Thanks & Regards, Vikas -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] ECC private key length
It's because of the form of the group order for the curves you list. They look roughly like 2**n + 2**(n/2). So while technically possible to end up with 161 bits, with overwhelming probability you end up with less. BBB On Wed, Apr 6, 2016 at 9:22 PM, Frode Nilsenwrote: > Hi, > > When printing the contents of a PEM ECC keypair file for the secp160k1/r1/r2 > curves, OpenSSL says the private key is 161 bits: > > $ openssl ecparam -name secp160k1 -genkey -out test.pem > $ openssl ec -in test.pem -text -noout > read EC key > Private-Key: (161 bit) > priv: > 77:76:fb:ae:7a:0b:97:98:aa:c0:70:7d:af:28:14: > 6d:4f:03:d9:b5 > pub: > 04:9b:98:38:4a:d0:e4:22:a2:3f:80:ce:02:90:02: > d3:35:51:dc:8f:7b:5e:30:7d:2d:5e:98:6f:4b:9b: > 4b:c8:01:1c:2d:ce:39:37:04:c5:61 > ASN1 OID: secp160k1 > > However, following "priv:", there are only 20 bytes (160 bits). Why is this? > > When printing the keypair for other curves, the number of bytes after "priv:" > seem to always be the same or higher than the number of bits shown after > "Private-Key:". > > Thanks in advance, > Frode > > -- > 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] CMS with Symmetric key
Thank you for the responses. I have implemented encryption that adds a secret key, and secret key id using: CMS_add0_recipient_key, CMS_EncryptData_encrypt, SMIME_write_CMS The output file looks correct, but I need to decrypt it back to be sure. I would like to be able to get the secret key id from the envelope data to then search a database for the key, and then CMS_decrypt. I have yet to determine the most straightforward way of getting the key ids from the envelope/wrapped content of cms. Is there a combination if I have SMIME_read the cms from a file like: keyId = cms->envelopedData->keyId? Or do I need to handle a stack_of recipient infos in order to get the key id from kekri0_get_id? Thanks again, Abe On Tue, Apr 5, 2016 at 7:39 AM, Dr. Stephen Hensonwrote: > On Mon, Apr 04, 2016, Abe Racioppo wrote: > > > Hey guys, > > > > I'm trying to use the CMS operations in libcrypto but with a symmetric > key > > encryption key instead of x509. > > > > I'm thinking I want to use a combination of > > > > CMS_RecipientInfo_set0_pkey, > > SMIME_write_CMS, > > and > > CMS_EncryptedData_encrypt. > > > > Has anyone done this before and can give me some direction? This is my > > first time working with openssl and am getting kinda lost. > > > > You have several options here. > > You can just use the encrypted data type with a key directly. > > You can use the enveloped data type with a symmetric wrapping key. > > You can use the enveloped data type with a password based recipient info. > > Which you use depends on the application you have in mind. > > In the first case you just call CMS_EncryptData_encrypt() followed by > SMIME_write_CMS(). > > Steve. > -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see: http://www.openssl.org > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users