Re: [openssl-users] Working with large DH parameters
On Sat, May 16, 2015 at 7:29 PM, Benny Baumann be...@geshi.org wrote: There is a limit of 1: #define OPENSSL_DH_MAX_MODULUS_BITS 1 I suggested replacing this compile time constant by a SSL_CTX option, but due to the lack of configuring this without having to change all programs there's no patch for this yet... A related issue is there are no more bits available in the options. SSL_OP_SAFARI_ECDHE_ECDSA_BUG re-purposed an exiting bit. Jeff ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Working with large DH parameters
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, Am 04.05.2015 um 19:13 schrieb Kurt Roeckx: On Mon, May 04, 2015 at 09:00:21AM -0500, jack seth wrote: There is a limit of 1: #define OPENSSL_DH_MAX_MODULUS_BITS 1 I suggested replacing this compile time constant by a SSL_CTX option, but due to the lack of configuring this without having to change all programs there's no patch for this yet. On a side-note: This limit also affects DSA keys, but not RSA. Second note: RSA is unlimited when used as server cert, but limited at 4096 bit when providing client certs. This leads to quite annoying situations with XMPP when the server needs to authenticate itself with the server cert at the remote host: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747453 Suggested solution here (discussed off-list with Rich recently) is to have this limit in the SSL_CTX and provide a way to configure the default for new connections externally (such that the program can still override this value, but an admin can configure this without the program needing to care about this setting). BUT: While I understand why this line isn't simply removed (patch attached at the linked debian BTS issue, I'd prefer that OpenSSL did in each situation allow you to set at least 256 bit security equivalent values (16384 for RSA, DSA, DH, 521 for ECC). Yes, doing 16384 Bit DHE isn't fast, but 10k is just about 192 bit and for client cert auth you only get 144 bit (y = 1.2x^.5 + 4.47x^[1/3] | x,y 0 Bit). I suggest you do not change this. It just gets slower without adding security. As shown above: It limits security at 144 Bit in certain situations ... A feature you can't disable is a bug and thus should be fixed ;-) I have no idea why it would freeze with something larger than 13824. I occationally use 13337 Bit DH with non-OpenSSL clients which takes about 5-10 seconds for the handshake; OpenSSL-based clients barf as noted above. Production usually uses 8k keys for both cert and kex. I'm not sure what is logging the size, but it might be using DH_size()*8 to log it. I don't think their currently is an API that returns it in bits. Kurt Thanks for the response. Could you elaborate on why a larger size doesn't add security? For the sake of discussion, lets ignore how slow it would be. According to section 5.6.1 of http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf you would need 15360+ bit to have security equal to AES256. Is NIST wrong here? If so, why? Everything in the chain would need to be providing 256 bit of security, there are no ciphers that support more than 192 as far as I know. The limitation here is with the MAC of the cipher suite as the largest one specified for use in a cipher suite is SHA384 providing 192 bit. Combined with ECDHE_ECDSA_WITH_AES256_SHA384 (CBC) you get 192 bit, but won't like the CBC in it. With GCM you usually get 128 bit for the MAC. Not sure for Chacha20/Poly1305: Chacha20 provides 256 bit theoretically, but I'm not sure with Poly1305 (as far as I'm reading the specs you get something around 64-128 bit, but not sure here). Once you're at 128 or above it's also far more likekly that something other than the crypto is the weakest part, like a human. ACK. Kurt Regards, BenBE. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJVV9LpAAoJEPHTXLno4S6tGe0QAKrZcQhWSCpFTi8hzW1GVPxC fHzN2ndzCiVhOz0uPgM0i/m3qbHqpaCi98mmynH9YKhboyzg+Z1v1RkjInlQWx4m mXUB254/mN3TIBtLvSF8LFltzjxLDXzvDMzJdQ7a8kDyfEPKf708KLZltbRTXkct gN+MoaGvNaa1HiSo0AVQ/zmRy8xCyTToeGZZICM7i5DEJYzylen3tUImGiuNiE8q NwtJRJ/tE/6O/Rj9ULO/R7Q/hqdq9yb5TPXMI2tGS816zu3tWehtIhollxxXsRGN pjqvCELpKTrD5GmUt+KxDeyf4/GEMZKDaZ0EhDN2hlxZTEH1Mzl6lM5lU5g9+pyO tt858/isCz5KH8iiOGy3wr86onjZdAGBfpg/Pp44aiYH2C1j35XSBzsrFnDCcOyy kMDuXTYbW+PcLVqG6qb2cYyidsdCvbf3vLQ8aCoZP4P9Udr/fiYzvlJMbZudoTQ4 CNdrWqjZyIh/o3TeIJv1bojDRjIUuOi5zIPF2MPaveoFAyr3rdaT0Va2XK49ayka Z7oU+vzTZXlv6TXEOqBw0YAWiEN+I4oKwmuasCnvj6QPQfenL3lC0rIgqGyEWrkT kSHVrwKNKvQWDiN0if0v+FnQ0yrTle8SN9KCvrOXI2a4+eo5Wslfm0X/i1+3GXaN PysMd2ipmAXriAlvAVTg =r1dk -END PGP SIGNATURE- ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Working with large DH parameters
There is a limit of 1: #define OPENSSL_DH_MAX_MODULUS_BITS 1 I suggest you do not change this. It just gets slower without adding security. I have no idea why it would freeze with something larger than 13824. I'm not sure what is logging the size, but it might be using DH_size()*8 to log it. I don't think their currently is an API that returns it in bits. Kurt Thanks for the response. Could you elaborate on why a larger size doesn't add security? For the sake of discussion, lets ignore how slow it would be. According to section 5.6.1 of http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf you would need 15360+ bit to have security equal to AES256. Is NIST wrong here? If so, why? ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Working with large DH parameters
On Mon, May 04, 2015 at 09:00:21AM -0500, jack seth wrote: There is a limit of 1: #define OPENSSL_DH_MAX_MODULUS_BITS 1 I suggest you do not change this. It just gets slower without adding security. I have no idea why it would freeze with something larger than 13824. I'm not sure what is logging the size, but it might be using DH_size()*8 to log it. I don't think their currently is an API that returns it in bits. Kurt Thanks for the response. Could you elaborate on why a larger size doesn't add security? For the sake of discussion, lets ignore how slow it would be. According to section 5.6.1 of http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf you would need 15360+ bit to have security equal to AES256. Is NIST wrong here? If so, why? Everything in the chain would need to be providing 256 bit of security, there are no ciphers that support more than 192 as far as I know. Once you're at 128 or above it's also far more likekly that something other than the crypto is the weakest part, like a human. Kurt ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Working with large DH parameters
On Mon, May 4, 2015 at 10:00 AM, jack seth bird_...@hotmail.com wrote: There is a limit of 1: #define OPENSSL_DH_MAX_MODULUS_BITS 1 I suggest you do not change this. It just gets slower without adding security. I have no idea why it would freeze with something larger than 13824. I'm not sure what is logging the size, but it might be using DH_size()*8 to log it. I don't think their currently is an API that returns it in bits. Thanks for the response. Could you elaborate on why a larger size doesn't add security? For the sake of discussion, lets ignore how slow it would be. According to section 5.6.1 of http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf you would need 15360+ bit to have security equal to AES256. Is NIST wrong here? If so, why? Also see https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe. The largest integer field size called out in the standards is 8192. (Corrections, please). Usually, when you want those kinds of security levels, you switch to EC. But like Kurt said At higher security levels, the attackers go around the crypto and not through it. Phishing emails to ladies in HR and Accounts Receivable is more effective and very inexpensive ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Working with large DH parameters
On Tue, Apr 28, 2015 at 09:26:25AM -0500, jack seth wrote: Ok I have been doing some experiments with OpenVPN and I can connect using 1 bit DH parameters. Any bigger than that up to at least 13824 I get the following 'modulus too large' error on the client log: TLS_ERROR: BIO read tls_read_plaintext error: error:05066067:Diffie-Hellman routines:COMPUTE_KEY:modulus too large: error:14098005:SSL routines:SSL3_SEND_CLIENT_KEY_EXCHANGE:DH lib Wed Apr 22 07:08:58 2015 TLS Error: TLS object - incoming plaintext read error Wed Apr 22 07:08:58 2015 TLS Error: TLS handshake failed Something interesting/weird also happened. I tried to test 10001, 10002, and 10004 bit DH to find the exact place I would get the 'modulus too large' error. But the server log reported the DH parameters being 10008 instead. I did a test at 15104 that gave the same error but then I tried two more times and the client just sat at the 'initial packet point' like it does with the 16384 bit parameters. So somewhere between 13824 and 16384 it switches between the error above and just sitting there 'frozen'. Questions: 1. Can the modulus error be cured? 2. Do you think the same modulus error is going on when the client appears to freeze with parameters larger than 13824 or is something else going (i.e. why does it freeze instead of giving the 'modulus error')? 3. Why does the server log report 10001, 10002, 10004 bit DH as 10008? There is a limit of 1: #define OPENSSL_DH_MAX_MODULUS_BITS1 I suggest you do not change this. It just gets slower without adding security. I have no idea why it would freeze with something larger than 13824. I'm not sure what is logging the size, but it might be using DH_size()*8 to log it. I don't think their currently is an API that returns it in bits. Kurt ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Working with large DH parameters
Can someone offer an opinion on my questions below? Thanks! From: bird_...@hotmail.com To: openssl-users@openssl.org Subject: Working with large DH parameters Date: Tue, 28 Apr 2015 09:26:25 -0500 Ok I have been doing some experiments with OpenVPN and I can connect using 1 bit DH parameters. Any bigger than that up to at least 13824 I get the following 'modulus too large' error on the client log: TLS_ERROR: BIO read tls_read_plaintext error: error:05066067:Diffie-Hellman routines:COMPUTE_KEY:modulus too large: error:14098005:SSL routines:SSL3_SEND_CLIENT_KEY_EXCHANGE:DH lib Wed Apr 22 07:08:58 2015 TLS Error: TLS object - incoming plaintext read error Wed Apr 22 07:08:58 2015 TLS Error: TLS handshake failed Something interesting/weird also happened. I tried to test 10001, 10002, and 10004 bit DH to find the exact place I would get the 'modulus too large' error. But the server log reported the DH parameters being 10008 instead. I did a test at 15104 that gave the same error but then I tried two more times and the client just sat at the 'initial packet point' like it does with the 16384 bit parameters. So somewhere between 13824 and 16384 it switches between the error above and just sitting there 'frozen'. Questions: 1. Can the modulus error be cured? 2. Do you think the same modulus error is going on when the client appears to freeze with parameters larger than 13824 or is something else going (i.e. why does it freeze instead of giving the 'modulus error')? 3. Why does the server log report 10001, 10002, 10004 bit DH as 10008? ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
