Since previously, the DH param was always 1024 bits and usually, key
sizes are 2048, I think that using a 2048 bits DH param adds a
performance impact but I never evaluated it since using a 1024 DHE param
is not unusual (or was not unusual, I am far to be up-to-date on
this). The impact should have been minimal since g is kept to 2 and this
is the important one (DHE is about g^a mod p where g and p are the DH
parameters) but we are nonetheless dealing with far more larger integers
and I suppose that the exponentiation has a performance hit when p gets
larger.
The strength of RSA and DH are equivalent so using the same size
for both is definitively a good practice.
OK thanks for explaining. Can't this be linked to the size of the keys
or anything else ? I'm asking because we can hardly accept to divide
the performance by 4 for users with no solution for them to work around
the issue. We know what they'll do : revert and stay on the previous
version which worked well for them.
In fact, I said that the performance impact should have been low, but
this is false. g is kept to 2, but the a in g^a mod p (a is the secret
number chosen by the server for the DH exchange) is a random number
between 0 and p - 1, so there is a big performance impact to use a 2048
bit DH parameter vs a 1024.
I agree with your explanation and the significative performance impact,
though I did not expect that users would be CPU-bound with a 2048 bits DH
parameter, as most of the requests are typically reusing an existing TLS
session (via TLS session ID or TLS tickets), therefore skipping a new key
exchange.
I think that we have two options:
- leave the situation as it is now, and let users concerned with security
use a static 2048 bits (or larger) static DH parameter in the certificate
file ;
- recommit the patch I submitted as it is, and let users concerned with
the CPU impact use static DH parameter in the certificate file.
I am in favor of the second option, because I think that the level of
security expected when using a 2048 bits RSA is a 2048 DH key exchange
(see rfc3766). Of course this means that users upgrading from a previous
version may see a significant increase in CPU usage, which I agree is bad.
I should probably send a new patch though, because I am afraid that using
a DH parameter larger than 2048 bits (which was the case with the previous
patch for RSA keys larger than 2048) is too much CPU consuming. I wonder
why mod_ssl users does not seem to complain?
--
Rémi Gacogne
Aqua Ray
SAS au capital de 105.720 Euros
RCS Creteil 447 997 099
www.aquaray.fr
14, rue Jules Vanzuppe
94854 IVRY-SUR-SEINE CEDEX (France)
Tel : +33 1 84 04 04 05
