Re: [openssl-users] Precedence of URL between configured one and provided in AIA filed.
That's software dependant. Either one is a valid responder, and either response has the same value, there's no priority. -- Erwann ABALEA Le 02/09/2013 10:27, deepak.kathuria a écrit : Hi, I am using openssl OCSP utility as OCSP Responder in linux platform. At OCSP Requester side, if OCSP Responder URL is coniguered and OCSP Responder URL is also present in subject certificate (AIA field of extension), then which one will get precedence- configued one or provided by AIA extension of the subjcet certificate? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Which version of net-snmp is compatible with openssl-1.0.1e
Hello, I have compiled net-snmp-5.5.2 with openssl-1.0.1e, and find it can not success in windows OS. At last I realize net-snmp-5.5.2 is not compatible with openssl-1.0.1e. So I want to know which version of net-snmp is right under openssl-1.0.1e environment. Hope your quick answer, thank you very much! Best Regards - Evan Liu(刘正) --- Engineer, Advanced Setting Utility(ASU) China Systems Technology Lab (CSTL) Email: liu...@cn.ibm.com Tel: +86 18261580205 Address:无锡市滨湖区绣溪路55号旭天软件园A1楼5F
Re: OpenSSL prime EDH parameters
On Sun, Sep 01, 2013, Viktor Dukhovni wrote: Incidentally, I just noticed the undocumented SSL_CTX_set_tmp_ecdh_callback(), which has the same interface as SSL_CTX_set_tmp_dh_callback(3) and it seems is also called with keylength equal to either 512 or 1024. What is the meaning of the keylength in this context? The keylength parameter and indeed is pretty useless (it was just copied from the DH version) the best it can be used for is to determine if the ciphersuite is export or not. I have been using the equally undocumented SSL_CTX_set_tmp_ecdh(), which just sets a fixed curve for all EECDH cipher-suites. Is there any disadvantage to this approach? Just setting P-256 should be fine for most circumstances just about everything supports it. The only thing it will cause problems with is SuiteB and 192 bit security mode but you really need (unreleased) OpenSSL 1.0.2 or later to handle SuiteB properly. For OpenSSL 1.0.2 the EC curve negotiation has been overhauled. Both client and server can set curve preferences and by calling: SSL_CTX_set_ecdh_auto(ctx, 1); the curve to use is handled automatically. 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 prime EDH parameters
On Tue, Sep 03, 2013 at 03:16:06PM +0200, Dr. Stephen Henson wrote: Incidentally, I just noticed the undocumented SSL_CTX_set_tmp_ecdh_callback(), which has the same interface as SSL_CTX_set_tmp_dh_callback(3) and it seems is also called with keylength equal to either 512 or 1024. What is the meaning of the keylength in this context? The keylength parameter and indeed is pretty useless (it was just copied from the DH version) the best it can be used for is to determine if the ciphersuite is export or not. And since there are no EECDH export ciphersuites: $ openssl ciphers -v 'kEECDH:!HIGH:!MEDIUM:!eNULL' 140735189950940:error:1410D0B9:SSL routines:SSL_CTX_set_cipher_list:no cipher match:ssl_lib.c:1314: even that information is not particularly useful. I have been using the equally undocumented SSL_CTX_set_tmp_ecdh(), which just sets a fixed curve for all EECDH cipher-suites. Is there any disadvantage to this approach? Just setting P-256 should be fine for most circumstances just about everything supports it. The only thing it will cause problems with is SuiteB and 192 bit security mode but you really need (unreleased) OpenSSL 1.0.2 or later to handle SuiteB properly. The Postfix user (that is email administrator) interface does not require users to know much or anything at all about the various EECDH curves. The administrator chooses one of: # default strong smtpd_tls_eecdh_grade = none | strong | ultra and behind the scenes Postfix TLS library parameters with defaults that only expert users would ever consider changing set: tls_eecdh_strong_curve = prime256v1 tls_eecdh_ultra_curve = secp384r1 For OpenSSL 1.0.2 the EC curve negotiation has been overhauled. Both client and server can set curve preferences and by calling: SSL_CTX_set_ecdh_auto(ctx, 1); the curve to use is handled automatically. That sounds like a substantial improvement. However, I notice that this too is undocumented. :-( In the Postfix project the rule is that undocumented code does not get included even in snapshot releases. (Think of these as commits of working code to the master repository). Such a policy is long overdue in the OpenSSL project. Should there also be an SSL_CTX_set_dh_auto(ctx, 1)? With suitable compiled-in MODP groups (perhaps from RFC 5114, though there is I think no gain from the DSA-style subgroups in TLS since q is not sent to the client). On Tue, Sep 03, 2013 at 01:40:29AM -0400, Dave Thompson wrote: - Is it reasonable for clients to expect stronger EDH groups? - Is there is any API support in OpenSSL for servers to provide a suitable range of parameters, perhaps tied to the negotiated symmetric algorithm key size? (With anonymous cipher-suites there is no public key on which to base the EDH parameter choice). Not that I've seen. The callback does get the SSL *, from which it could find the suite, and its characteristics. It isn't an IETF standard, but NIST SP800-57 has a general purpose mapping of strength across symmetric, hash, RSA (IFC), DSA/DH (IDL), and ECC which I would use for lack of any better. Right, and this is what the GnuTLS folks seem to have used to (inadvisably) set EDH prime lower bounds on TLS clients, thereby breaking interoperability with pretty much every other TLS implementation. So the question is what to do now? Should every application using GnuTLS work-around the problem? Should other implementations (OpenSSL, ...) now rush to implement SP800-57 compatible EDH parameters based on the negotiated symmetric key length? I have been using the equally undocumented SSL_CTX_set_tmp_ecdh(), which just sets a fixed curve for all EECDH cipher-suites. Is there any disadvantage to this approach? In principle if a client supports some curve(s) but not the one you selected, handshake will unnecessarily skip ECDHE -- and if no other key-exchange available fail. I'd say in practice if you pick p-256 or maybe p-384 you probably get decent results. That was my conclusion when EECDH support was added to Postfix 2.6 snapshots in 2008. In Postfix 2.8 EECDH was enabled by default. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Verify signature (ECDSA_do_verify) using only x-coordinate in public key (EC_POINT)?
Hi all, Is there a way to verify a signature with ECDSA_do_verify having only the x-coordinate (in public key) available? I am trying to verify a signature using ECDSA_do_verify: ECDSA_do_verify(dgst, dgst_len, signature, eckey_nistp256); , where the eckey_nistp256 is given from: EC_KEY_set_public_key(eckey_nistp256, ecpoint_nistp256); and only the x part of ecpoint_nistp256 is available. When trying to verify, this function returns -1. (I have verified that the digest and signature are correct). Thanks in advance. Best regards /Jonas
Re: OpenSSL prime EDH parameters
On Tue, Sep 03, 2013, Viktor Dukhovni wrote: On Tue, Sep 03, 2013 at 03:16:06PM +0200, Dr. Stephen Henson wrote: The Postfix user (that is email administrator) interface does not require users to know much or anything at all about the various EECDH curves. The administrator chooses one of: # default strong smtpd_tls_eecdh_grade = none | strong | ultra and behind the scenes Postfix TLS library parameters with defaults that only expert users would ever consider changing set: tls_eecdh_strong_curve = prime256v1 tls_eecdh_ultra_curve = secp384r1 The SSL_CONF_cmd interface in OpenSSL 1.0.2 and later might be useful too. It's designed to provide a common format for configuration. For OpenSSL 1.0.2 the EC curve negotiation has been overhauled. Both client and server can set curve preferences and by calling: SSL_CTX_set_ecdh_auto(ctx, 1); the curve to use is handled automatically. That sounds like a substantial improvement. However, I notice that this too is undocumented. :-( It was documented on my hard disk, I just forgot to push it, oops. It's included in commit c3eb33763bf2999843fe4124f3f39dea6edc26e6 Should there also be an SSL_CTX_set_dh_auto(ctx, 1)? With suitable compiled-in MODP groups (perhaps from RFC 5114, though there is I think no gain from the DSA-style subgroups in TLS since q is not sent to the client). There is some gain server side during key generation, but nothing client side. 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 prime EDH parameters
On Tue, Sep 03, 2013 at 04:53:52PM +0200, Dr. Stephen Henson wrote: The SSL_CONF_cmd interface in OpenSSL 1.0.2 and later might be useful too. It's designed to provide a common format for configuration. Thanks, I'll take a look at that when I get a chance. [ I'm still concerned about the DANE support in 1.0.2 by the way, it should IMHO be dropped or fixed, neither seems to be happening. ] It was documented on my hard disk, I just forgot to push it, oops. It's included in commit c3eb33763bf2999843fe4124f3f39dea6edc26e6 Thanks. Any chance that documenting new interfaces will become a requirement for code contributions to OpenSSL? Should there also be an SSL_CTX_set_dh_auto(ctx, 1)? With suitable compiled-in MODP groups (perhaps from RFC 5114, though there is I think no gain from the DSA-style subgroups in TLS since q is not sent to the client). There is some gain server side during key generation, but nothing client side. The more important part of the question (than speed-ups, ...) is whether OpenSSL should use a more complex DH group selection strategy than just export vs not export? Namely, should OpenSSL servers choose DH parameters with strength commensurate to the symmetric key size? What would be the performance implications (would this require DSA-style groups to be practical or is that still too costly with larger primes). Should the GnuTLS developers be left to solve the mess they've created, or is it time to consider moving in the direction they've all-too-boldly embarked upon? To the specific point in your reply, does OpenSSL actually support DSA-style groups (with p, g and q) where DH groups are expected? For example can such groups be returned from the temp DH callback? Certainly the dhparam(1) command does not seem to support groups with q values. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL prime EDH parameters
On Tue, Sep 03, 2013, Viktor Dukhovni wrote: To the specific point in your reply, does OpenSSL actually support DSA-style groups (with p, g and q) where DH groups are expected? For example can such groups be returned from the temp DH callback? Certainly the dhparam(1) command does not seem to support groups with q values. Support in OpenSSL 1.0.2 and later for X9.42 DH parameters (which include q) will be more complete. For previous versions the length parameter in the PKCS#3 DH parameter structure can be set by converting DSA parameters to DH using (for example) the -dsaparam option to the dhparam utility. 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: Verify signature (ECDSA_do_verify) using only x-coordinate in public key (EC_POINT)?
On 3 September 2013 15:16, Jonas Andersson jonasanderssonm...@gmail.com wrote: Hi all, Is there a way to verify a signature with ECDSA_do_verify having only the x-coordinate (in public key) available? Are you sure you *only* have the x-coord and not a point in compressed format? The difference being that with compressed format you get an octet at the front specifying which of the two possible y values to use (the y bit) followed by the full octets for the x coordinate. If you have it in compressed format as an octet string there are functions to load it. You need to make sure that the point conversion form for the curve is POINT_CONVERSION_COMPRESSED. You can set this using EC_GROUP_set_point_conversion_form (not sure off the top of my head what the default is for this). You can then load your compressed point using EC_POINT_oct2point. Alternatively you can use EC_POINT_set_compressed_coordinates_GFp or EC_POINT_set_compressed_coordinates_GF2m (for prime curves or binary curves as appropriate). Hope that helps, Matt __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
compiling for debug on Linux
I know this is a FAQ, but the answers I found all included the response that didn't work. openssl 1.0.1c on Linux: How do I compile and link so the debugger can step into the openssl code? Are there definitive instructions anywhere, or does everyone use trial and error? I'm using a local copy of the source, and do not want to touch /usr/bin. I tried various combinations that worked in the past: ./config with -d -g shared linux-elf --prefix ... ./Configure with the above and -shared debug-linux-elf They either didn't compile, didn't link, or gdb would not step in. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Openssl 1.0.1x build using VS 2012
Check out this page: http://www.openssl.org/docs/crypto/OPENSSL_Applink.html Basically, you just need to #include openssl\applink.c in your application. That file defines a virtual table like list of things related to stdout, stderr, etc. This file only appears to be needed when you start using functions that might access FILEs or the console, like ERR_print_errors_fp. I’m not sure why you are only seeing it in VS2012; maybe you added logging code so you diagnose issues in the new DLL? Patrick Watson, CISSP Software Engineer Data Security Electronic Payment Systems NCR Retail From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Pravesh Rai Sent: Friday, August 30, 2013 1:07 AM To: openssl-users@openssl.org Subject: Openssl 1.0.1x build using VS 2012 Hi, Even though I'm successful in getting the OpenSSL build using VS 2012, but getting following error message: OPENSSL_Uplink(07FED5A31000,08): no OPENSSL_Applink while trying to 'load' libeay32.dll. The problem is solved, if we use another libeay32.dll, which is built using VS 2005. Except for this, all other development usage environment is totally same. Do anybody has any clue on this? Thanks, Pravesh
Re: Openssl 1.0.1x build using VS 2012
Hi All, Got the solution. The problem was due to difference in building environment of Application OpenSSL. Some of the application binaries were built using their older project format, i.e. *.vcproj rest other binaries were built using their newer project format, i.e. *.vcxproj. Thanks to all, who reponded to my query. Thanks, Pravesh On Wed, Sep 4, 2013 at 4:37 AM, Watson, Patrick patrick.wat...@ncr.comwrote: Check out this page: http://www.openssl.org/docs/crypto/OPENSSL_Applink.html ** ** Basically, you just need to #include openssl\applink.c in your application. That file defines a virtual table like list of things related to stdout, stderr, etc. This file only appears to be needed when you start using functions that might access FILEs or the console, like ERR_print_errors_fp. ** ** I’m not sure why you are only seeing it in VS2012; maybe you added logging code so you diagnose issues in the new DLL? ** ** *Patrick Watson, CISSP* *Software Engineer Data Security Electronic Payment Systems NCR Retail* *From:* owner-openssl-us...@openssl.org [mailto: owner-openssl-us...@openssl.org] *On Behalf Of *Pravesh Rai *Sent:* Friday, August 30, 2013 1:07 AM *To:* openssl-users@openssl.org *Subject:* Openssl 1.0.1x build using VS 2012 ** ** Hi, Even though I'm successful in getting the OpenSSL build using VS 2012, but getting following error message: OPENSSL_Uplink(07FED5A31000,08): no OPENSSL_Applink while trying to 'load' libeay32.dll. The problem is solved, if we use another libeay32.dll, which is built using VS 2005. Except for this, all other development usage environment is totally same. Do anybody has any clue on this? Thanks, Pravesh ** **
