[openssl-users] Working with large DH parameters

[Benny Baumann]

-----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-----