-----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 10000: #define OPENSSL_DH_MAX_MODULUS_BITS >>> 10000 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-----
