[openssl-users] Working with large DH parameters
BenBE at geshi.org
Sat May 16 23:29:46 UTC 2015
-----BEGIN PGP SIGNED MESSAGE-----
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
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:
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
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.
>> 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
>> 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
-----END PGP SIGNATURE-----
More information about the openssl-users