Re: [openssl-users] What global object I use in application lifetime
So, I can re-use g_ctx, but I need create a new g_ssl everytime, right? BTW, X509_STORE *store = X509_STORE_new(); for store, Can I reuse it as a global object? On Wed, Mar 25, 2015 at 11:33 AM, Salz, Rich wrote: >> From document, I think CTX can be initialize only once. But I do not know >> g_ssl can be initialize only once? I can reuse g_ssl for 1000 differnt URLs? >> Please correct me if anything. Thanks! > > You need to create a new SSL object every time you want to do a connect. > > /r$ > > -- > Senior Architect, Akamai Technologies > IM: richs...@jabber.at Twitter: RichSalz > > > ___ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- Rejoice,I Desire! ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] What global object I use in application lifetime
> From document, I think CTX can be initialize only once. But I do not know > g_ssl can be initialize only once? I can reuse g_ssl for 1000 differnt URLs? > Please correct me if anything. Thanks! You need to create a new SSL object every time you want to do a connect. /r$ -- Senior Architect, Akamai Technologies IM: richs...@jabber.at Twitter: RichSalz ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] What global object I use in application lifetime
Hi. Now when my application running, I will use SSL_connect() to connect 1000 different URLs. I want to keep some openssl object as global variable then I do not need to initialize/uninitialize again and again. Here is my sample code. g_ctx = SSL_CTX_new(method); g_ssl = SSL_new(g_ctx ); //SSL_connect will connect 1000 URLs 1 by 1. ... //release g_ctx and g_ssl >From document, I think CTX can be initialize only once. But I do not know g_ssl can be initialize only once? I can reuse g_ssl for 1000 differnt URLs? Please correct me if anything. Thanks! Best Regards Jerry -- Rejoice,I Desire! ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl 1.0.2a vc++ 9 (VS 2008) 64-bit build failing
Switching to a more recent version of nasm did the trick. As it turns out, before I posted, I had assumed that using nasm might resolve this. However, it appears that I grabbed nasm 2.05 which doesn't support AES-NI instructions, either(?). So, my intial switch to nasm failed with the same errors. After your reply, I upgraded to the latest version, 2.11.8, and it worked. Thanks for reinforcing my assumption and putting me back on track. Regards, Kevin -- -Original Message- From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Thomas J. Hruska Sent: Monday, March 23, 2015 9:04 PM To: openssl-users@openssl.org Subject: Re: [openssl-users] openssl 1.0.2a vc++ 9 (VS 2008) 64-bit build failing On 3/23/2015 9:51 AM, Kevin Moody wrote: > Hi, > > My apologies if I missed a post about this already, but I'm seeing the > following when running `nmake -f ms\ntdll.mak` in the vc9x64 build of openssl > 1.0.2a: > > ... > Assembling: tmp32dll\aesni-sha256-x86_64.asm > tmp32dll\aesni-sha256-x86_64.asm(109) : error A2006:undefined symbol : > __imp_Rtl VirtualUnwind > tmp32dll\aesni-sha256-x86_64.asm(127) : error A2006:undefined symbol : > $L$SEH_be gin_aesni_cbc_sha256_enc_xop > tmp32dll\aesni-sha256-x86_64.asm(128) : error A2006:undefined symbol : > $L$SEH_en d_aesni_cbc_sha256_enc_xop > tmp32dll\aesni-sha256-x86_64.asm(129) : error A2006:undefined symbol : > $L$SEH_in fo_aesni_cbc_sha256_enc_xop > tmp32dll\aesni-sha256-x86_64.asm(131) : error A2006:undefined symbol : > $L$SEH_be gin_aesni_cbc_sha256_enc_avx > tmp32dll\aesni-sha256-x86_64.asm(132) : error A2006:undefined symbol : > $L$SEH_en d_aesni_cbc_sha256_enc_avx > tmp32dll\aesni-sha256-x86_64.asm(133) : error A2006:undefined symbol : > $L$SEH_in fo_aesni_cbc_sha256_enc_avx NMAKE : fatal error U1077: > '"c:\Program Files\Microsoft Visual Studio 9.0\VC\BIN > \x86_amd64\ml64.EXE"' : return code '0x1' > Stop. > > What's odd is that this has built in my vc9x32, vc10x32, vc10x64, vc11x32, > and vc11x64 build configurations. Just to rule out an environment issue, I > built my previous version, 1.0.1g, within this same command prompt. Any > ideas or suggestions as to what might be breaking the VS 2008 64-bit build? > Has anyone seen this? > > Obviously, I don't know enough about this project to really debug the build > much further. So, thanks in advance! > > Regards, > Kevin Use NASM instead of MASM. AES-NI instructions are not supported under the VC++ 2008 compiler. -- Thomas Hruska Shining Light Productions Home of BMP2AVI and Win32 OpenSSL. http://www.slproweb.com/ ___ 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] FIPS: Which DRBG ?
On 03/24/2015 01:27 PM, jonetsu wrote: > > >> From: "Steve Marquess" Date: 03/24/15 12:38 >> > > >> No, the OpenSSL FIPS module 2.0 code is no longer suitable (as of >> early 2014) for use as-is in doing copycat validations. Some >> non-trivial code hacks will be necessary. > >> We'll do a new open source based validation to succeed the 2.0 >> FIPS module (#1747 validation) at the first opportunity, but that >> opportunity has not yet presented itself. > > I still do not know that much about the validation in practical > terms. If our units go through validation, can this benefit OpenSSL > ? Not in the tiniest, unless you completely open source the entire thing as we did (specifically in a validation that includes the build-from-source part). A FIPS 140-2 validation is like magical pixie dust in that you and I can each take exactly the same source code and each build a binary FIPS module from it in exactly the same way, for exactly the same platform, and your module will be "validated" and mine won't (or vice-versa, depending on the pixe dust). > > Also, to go back to the SP 800-90 vs. SP 800-90A regarding the DRBGs, > do you know how would the OpenSSL SP 800-90 validation fare in a FIPS > testing lab since the Dual EC was removed and the other three were > not touched ? We "revalidate" the DRBGs every time we do a new "change letter" platform addition, which is frequently. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com 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
Re: [openssl-users] FIPS: Which DRBG ?
> From: "Steve Marquess" > Date: 03/24/15 12:38 > No, the OpenSSL FIPS module 2.0 code is no longer suitable (as of early > 2014) for use as-is in doing copycat validations. Some non-trivial code > hacks will be necessary. > We'll do a new open source based validation to succeed the 2.0 FIPS > module (#1747 validation) at the first opportunity, but that opportunity > has not yet presented itself. I still do not know that much about the validation in practical terms. If our units go through validation, can this benefit OpenSSL ? Also, to go back to the SP 800-90 vs. SP 800-90A regarding the DRBGs, do you know how would the OpenSSL SP 800-90 validation fare in a FIPS testing lab since the Dual EC was removed and the other three were not touched ? Regards. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] FIPS: Which DRBG ?
On 03/24/2015 09:53 AM, jonetsu wrote: > > ... > >> Now the code for the OpenSSL FIPS module can no longer be used >> as-is for new "private label" or copycat validations, but that's >> for different reasons and not because of the DRBGs. > > I've read the User Guide bit on private label validations. In the > case of a product that consists of a dedicated unit, what would be > the best approach ? So far I have considered using the OpenSSL FIPS > module as is, in the hope that its FIPS validation would save costs > at the testing lab. Is this still feasible ? No, the OpenSSL FIPS module 2.0 code is no longer suitable (as of early 2014) for use as-is in doing copycat validations. Some non-trivial code hacks will be necessary. We'll do a new open source based validation to succeed the 2.0 FIPS module (#1747 validation) at the first opportunity, but that opportunity has not yet presented itself. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com 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
Re: [openssl-users] ChaCha20/Poly1305 in OpenSSL?
Following github repo has 1.0.2a with chacha20poly1305 patch from CloudFlare applied to it: https://github.com/eakraly/openssl And this one has chacha20poly1305 implementation from different source (1.0.2-aead branch in openssl) https://github.com/PeterMosmans/openssl Pavel Punsky -Original Message- From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Salz, Rich Sent: Monday, March 23, 2015 4:36 PM To: noloa...@gmail.com; openssl-users@openssl.org Subject: Re: [openssl-users] ChaCha20/Poly1305 in OpenSSL? It's unlikely to appear in 1.0.2 as it's a new feature. CloudFlare has posted patches that seem like they would drop in easily, for folks that want to do it; see https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/ -- Senior Architect, Akamai Technologies IM: rs...@jabber.me Twitter: RichSalz ___ 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] FIPS: Which DRBG ?
> From: "Steve Marquess" > Date: 03/24/15 09:22 > At the time that validation was obtained the four (at the time) DRBGs > were specified by SP800-90. That document was subsequently reissued in > several pieces; the current SP800-90A now contains the specifications > for the three surviving DRBGs (the fatally tainted Dual EC DRBG having > been removed from the formal standards and also from the OpenSSL FIPS > Object Module). If it concerns only the removal of the Dual EC, then it should be OK, technically. Not on paper. > Now the code for the OpenSSL FIPS module can no longer be used as-is for > new "private label" or copycat validations, but that's for different > reasons and not because of the DRBGs. I've read the User Guide bit on private label validations. In the case of a product that consists of a dedicated unit, what would be the best approach ? So far I have considered using the OpenSSL FIPS module as is, in the hope that its FIPS validation would save costs at the testing lab. Is this still feasible ? Regards. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] FIPS: Which DRBG ?
On 03/23/2015 02:36 PM, xxiao8 wrote: > The key issue still remains, are the validated SP800-90 DRBGs the _same_ > as SP800-90A's DRBGs? If yes then we can probably use Openssl-FIPS with > SP800-90A, otherwise OpenSSL-FIPS 2.0.9 probably can no longer be used > for any new validations? At the time that validation was obtained the four (at the time) DRBGs were specified by SP800-90. That document was subsequently reissued in several pieces; the current SP800-90A now contains the specifications for the three surviving DRBGs (the fatally tainted Dual EC DRBG having been removed from the formal standards and also from the OpenSSL FIPS Object Module). Now the code for the OpenSSL FIPS module can no longer be used as-is for new "private label" or copycat validations, but that's for different reasons and not because of the DRBGs. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com 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] Fwd to openssl-users, Re: [openssl-dev] Reminder: OpenSSL's EC private key encoding is broken
The private key is a random integer in [1, p-1], not in [2^(log2(p)-1), (2^log2(p))-1]. In DER, an INTEGER is always expressed using the smallest possible number of octets. "001a" is an integer equal to "001a", but it will be represented as "1a". -- Erwann ABALEA Le 24/03/2015 12:10, Annie Yousar a écrit : Dear all, this should not have happened: $ for i in `seq 1 1000` ; do if [ "x`openssl ecparam -genkey -name prime256v1 -noout > key.pem; ls -l key.pem | sed '/ 227 /d'`" != " x" ]; then echo; cat key.pem;else echo -n "."; fi; done -BEGIN EC PRIVATE KEY- MHYCAQEEH9gjg1X/Gn9X/2VTustsXS/OuWV9LU4ivfp5oewxbACgCgYIKoZIzj0D AQehRANCAARlO6sLkCzJl7khaT8Nj6z3WpcDnMALQ4nI8Toc4/oYHtgUopeSMEj8 fgHw9Ym3/2GgClzweJXYLuTYRB7oR/MY -END EC PRIVATE KEY- ... Conforming to the standards the EC private key has always a fixed length, defined by the group order. Regards, Ann. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
