Re: Size of ephemeral DH keys
On Tue, Aug 14, 2012 at 12:23 PM, no_spam...@yahoo.com wrote: Is there a correlation between the strength (size) of the asymmetric keys used to do the authentication and the strength (size) of the ephemeral DH keys generated/used to protect the session key (during the key exchange)? Yes, there is. On first glance, in s3_srvr.c, it seems like the tmp_dh_callback() function is only ever passed keylength == [512, 1024] - the result of the SSL_C_EXPORT_PKEYLENGTH() macro. And a DH key of length 1024-bits is roughly equivalent to a 80-bit symmetric key. It seems strange that it would be using a 80-bit key to protect the exchange of a 128- or 256-bit symmetric session key. That's a classic Security Level mismatch. I'm probably missing something in the OpenSSL implementation. The documentation for SSL_CTX_set_tmp_dh_callback() says that the tmp_dh_callback is called with the keylength needed... But surely this can't be only 512 or 1024...? Is it up to the application to decide to use a larger key size based on the information from the SSL structure passed in? No, OpenSSL is doing things per the standards. The standards are the problem here. More generally, is there a standard that defines or set of best practices that recommends the strength of ephemeral DH keys based on the cipher suite, strength (size) of the keys used for authentication, etc.? Yes, FIPS, ECRYPT, NESSIE, etc: * SP800-57, Part 1, Recommendation for Key Management, Section 5.6.1 * SP 800-131, Recommendation for the Transitioning of Cryptographic Algorithms and Key Lengths * ECRYPT2 Yearly Report on Algorithms and Keysizes (2010) Also see http://www.cryptopp.com/wiki/Security_Level. Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Size of ephemeral DH keys
Thank you for the information and links. [stuff deleted] I'm probably missing something in the OpenSSL implementation. The documentation for SSL_CTX_set_tmp_dh_callback() says that the tmp_dh_callback is called with the keylength needed... But surely this can't be only 512 or 1024...? Is it up to the application to decide to use a larger key size based on the information from the SSL structure passed in? No, OpenSSL is doing things per the standards. The standards are the problem here. I don't understand this comment. Are you suggesting that my application ONLY use what OpenSSL supplies as the value of the keylength parameter? And NOT use larger-than-1024-bit DH key sizes? Don't the standards and/or research suggest that larger key sizes SHOULD be used when appropriate? I guess what I'm asking is: what is the proper method for using larger ephemeral DH key sizes in OpenSSL? What I'm envisioning is something like the following: if the cipher suite and authentication key size info contained in the SSL structure require something stronger than 1024-bit ephemeral DH keys, use something bigger. And perhaps have an application override that can force the tmp_dh_callback to use 1024-bit for backwards compatibility. Does this make any sense? Or is the right answer not to use ephemeral DH cipher suites? The trade off being the lack of PFS for a more consistent security level. [stuff deleted] Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Size of ephemeral DH keys
On Tue, Aug 14, 2012 at 3:00 PM, no_spam...@yahoo.com wrote: Thank you for the information and links. [stuff deleted] I'm probably missing something in the OpenSSL implementation. The documentation for SSL_CTX_set_tmp_dh_callback() says that the tmp_dh_callback is called with the keylength needed... But surely this can't be only 512 or 1024...? Is it up to the application to decide to use a larger key size based on the information from the SSL structure passed in? No, OpenSSL is doing things per the standards. The standards are the problem here. I don't understand this comment. Are you suggesting that my application ONLY use what OpenSSL supplies as the value of the keylength parameter? And NOT use larger-than-1024-bit DH key sizes? Don't the standards and/or research suggest that larger key sizes SHOULD be used when appropriate? The standards are sufficiently vague, and often [mildly] offends all parties. OAuth 2.0 editor resigns and takes name off spec, http://www.h-online.com/open/news/item/OAuth-2-0-editor-resigns-and-takes-name-off-spec-1654984.html. I guess what I'm asking is: what is the proper method for using larger ephemeral DH key sizes in OpenSSL? Ah, my bad. I'm not sure how to configure it on the client or the server. What I'm envisioning is something like the following: if the cipher suite and authentication key size info contained in the SSL structure require something stronger than 1024-bit ephemeral DH keys, use something bigger. And perhaps have an application override that can force the tmp_dh_callback to use 1024-bit for backwards compatibility. Does this make any sense? Yes. Or is the right answer not to use ephemeral DH cipher suites? The trade off being the lack of PFS for a more consistent security level. No, DHE is good since it ensures forward secrecy. Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Size of ephemeral DH keys
On Tue, Aug 14, 2012, no_spam...@yahoo.com wrote: Is there a correlation between the strength (size) of the asymmetric keys used to do the authentication and the strength (size) of the ephemeral DH keys generated/used to protect the session key (during the key exchange)? On first glance, in s3_srvr.c, it seems like the tmp_dh_callback() function is only ever passed keylength == [512, 1024] - the result of the SSL_C_EXPORT_PKEYLENGTH() macro. And a DH key of length 1024-bits is roughly equivalent to a 80-bit symmetric key. It seems strange that it would be using a 80-bit key to protect the exchange of a 128- or 256-bit symmetric session key. I'm probably missing something in the OpenSSL implementation. The documentation for SSL_CTX_set_tmp_dh_callback() says that the tmp_dh_callback is called with the keylength needed... But surely this can't be only 512 or 1024...? Is it up to the application to decide to use a larger key size based on the information from the SSL structure passed in? The actual key length is only meaningful if the is_export parameter is non-zero. This a legacy from the days when there were export restrictions on strong crypto. If is_export is zero you are free to use whatever parameter length you consider appopriate but there is no guarantee the peer will support very large values. It is more common practice to use a fixed set of DH parameters through the SSL_CTX_set_tmp_dh API instead of using the callback. 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
