Re: SSL_CTX_set_tmp_ecdh_callback() semantics in 1.0.1?
On 7/1/2014 2:42 AM, Jeffrey Walton wrote: On Mon, Jun 30, 2014 at 4:32 PM, Jakob Bohm jb-open...@wisemo.com wrote: Because there is no documentation for SSL_CTX_set_tmp_ecdh_callback() in OpenSSL 1.0.1 and older, I am afraid I have to ask: 1. Is the EC_KEY* returned by the callback supposed to be allocated for each invocation or is it supposed to be a static shared by all invocations? Static is fine. If the latter (a common object), are there any threading issues when multiple threads are running SSL connections simultaneously? Well, there is a CRYPTO_LOCK_EC for the static lock. Is this something that requires code outside openssl on my part, or is it automatic on the major platforms? The locking documentation was always a bit ambivalent about its applicability to modern library and OS versions (as opposed to early SSLeay versions on equally old platforms). 2. What does the keylength parameter to the ECDH callback represent: A) An RSA/DH keylength (e.g. 2048 for 128 bit security) B) An EC keylength (e.g. 130 for 128 bit security) C) A symmetric keylength (e.g. 128 for 128 bit security) The keylength parameter is munged. You have to translate it from DH/RSA bit lengths. That is, a keylength of 1024 needs to be translated to a 160-bit curve (both have a 80-bit security level), a keylength of 2048 needs to be translated to a 224-bit curve (both have a 112-bit security level), and a keylength of 3072 needs to be translated to a 256-bit curve (both have a 128-bit security level), etc. 3. Are there particular cut-off-points for the keylength parameter which correlates with the largest of the predefined EC groups likely to be supported by the client (e.g. according to the cipher suite collection offered). I use N + 4. For example: if(keylength = 160 + 4) return ECSH160(); // Returns EC_KEY* else if(keylength = 192 + 4) return ECSH192(); // Returns EC_KEY* else if(keylength = 224 + 4) return ECSH224(); // Returns EC_KEY* ... This example seems to contradict your reply to #2. Should I compare the keylength parameter received by the callback to 160+4 etc, or to 1024+24 etc. But P-256 seems to be most popular for interop. I am actually trying to choose between P-256 and a larger one, using the keylength as an indication if the larger one can be expected to interop. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, 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 Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: SSL_CTX_set_tmp_ecdh_callback() semantics in 1.0.1?
On Tue, Jul 1, 2014 at 12:36 PM, Jakob Bohm jb-open...@wisemo.com wrote: On 7/1/2014 2:42 AM, Jeffrey Walton wrote: ... I use N + 4. For example: if(keylength = 160 + 4) return ECSH160(); // Returns EC_KEY* else if(keylength = 192 + 4) return ECSH192(); // Returns EC_KEY* else if(keylength = 224 + 4) return ECSH224(); // Returns EC_KEY* ... This example seems to contradict your reply to #2. Should I compare the keylength parameter received by the callback to 160+4 etc, or to 1024+24 etc. But P-256 seems to be most popular for interop. I am actually trying to choose between P-256 and a larger one, using the keylength as an indication if the larger one can be expected to interop. Ah, my bad. If keylength is greater than 512, then I translate it from DH/RSA to EC sizes. Then I drop into that code. 512 is an edge case: is it DH/RSA 512; or is it effectively P-521? Right now, I think I have that all defined out with `#define 0` and simply use P-256 to maximize interop. Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: SSL_CTX_set_tmp_ecdh_callback() semantics in 1.0.1?
On Tue, Jul 01, 2014, Jeffrey Walton wrote: Ah, my bad. If keylength is greater than 512, then I translate it from DH/RSA to EC sizes. Then I drop into that code. 512 is an edge case: is it DH/RSA 512; or is it effectively P-521? Right now, I think I have that all defined out with `#define 0` and simply use P-256 to maximize interop. The ecdh callback code is a bit of a mess. It followed the symantics of DH which don't fit well with ECDH. It has the form: EC_KEY *(*ecdh_tmp_cb)(SSL *ssl,int is_export,int keysize); where is_export indicates whether it is an export length cipher suite and keysize is the algorithm strength of the selected ciphersuite. That parameter isn't any help as what you really need to know if the set of curves supported by the peer. If you return a curve the peer doesn't support the handshake will typically be aborted. For that reason it's usual to avoid the ecdh callback altogether and just specify a commonly supported curve such as P-256 and pass it to SSL_CTX_set_tmp_ecdh. Then if the peer doesn't support that curve ECDH is disabled and a ciphersuite not using ECDH will be used instead. OpenSSL 1.0.2 fixes this ugliness: you just call SSL_CTX_set_ecdh_auto(ctx, 1) and the highest preference common curve is automatically used. 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: SSL_CTX_set_tmp_ecdh_callback() semantics in 1.0.1?
On Mon, Jun 30, 2014 at 4:32 PM, Jakob Bohm jb-open...@wisemo.com wrote: Because there is no documentation for SSL_CTX_set_tmp_ecdh_callback() in OpenSSL 1.0.1 and older, I am afraid I have to ask: 1. Is the EC_KEY* returned by the callback supposed to be allocated for each invocation or is it supposed to be a static shared by all invocations? Static is fine. If the latter (a common object), are there any threading issues when multiple threads are running SSL connections simultaneously? Well, there is a CRYPTO_LOCK_EC for the static lock. 2. What does the keylength parameter to the ECDH callback represent: A) An RSA/DH keylength (e.g. 2048 for 128 bit security) B) An EC keylength (e.g. 130 for 128 bit security) C) A symmetric keylength (e.g. 128 for 128 bit security) The keylength parameter is munged. You have to translate it from DH/RSA bit lengths. That is, a keylength of 1024 needs to be translated to a 160-bit curve (both have a 80-bit security level), a keylength of 2048 needs to be translated to a 224-bit curve (both have a 112-bit security level), and a keylength of 3072 needs to be translated to a 256-bit curve (both have a 128-bit security level), etc. 3. Are there particular cut-off-points for the keylength parameter which correlates with the largest of the predefined EC groups likely to be supported by the client (e.g. according to the cipher suite collection offered). I use N + 4. For example: if(keylength = 160 + 4) return ECSH160(); // Returns EC_KEY* else if(keylength = 192 + 4) return ECSH192(); // Returns EC_KEY* else if(keylength = 224 + 4) return ECSH224(); // Returns EC_KEY* ... But P-256 seems to be most popular for interop. Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
