8

Having generated 2048-bit DH params, do I need to regenerate them regularly? If so, how frequently should I do this?

9

Generally speaking, no, you do not have to recreate the parameters regularly.

Diffie-Hellam gets broken through solving the discrete logarithm problem (technically, there is no proof that one must solve DL to break DH, but that's still the best known method). It so happens that if you are able to break one instance of DL, then you can reuse much of the work to break other instances of DL, provided they all use the same modulus (i.e. the same "DH parameters"). In the case of the recent "Logjam attack" this was put to use: since some client and servers agree to use a weak modulus (of 512 bits) and, moreover, they all appear to use the same modulus, the attackers, after having broken DL once (through significant effort), can now do the same again for that specific modulus in quasi-real-time, which then makes MitM practical.

The initial "if" is a big one, though. Normally, you would use DH parameters that are large enough to utterly prevent that initial DL-breaking effort to take place. You don't want attackers to expand an initial success into easy MitM, but you don't want them to achieve that initial success either. Using a 2048-bit modulus sets you already quite far in the "can't break it" zone. See this site for details. Also, even in a sci-fi scenario where your DH gets broken, this will still be your parameters, and the attack effort won't be applicable to other servers -- which means that breaking efforts on the DH parameters of other people will not impact you. By using parameters you generate yourself, you already obtain the bulk of the protection. In fact, even with a 512-bit modulus, using your own parameters instead of the "standard" ones would already offer a great deal of protection, because while the initial break of a 512-bit modulus is feasible, it still is a substantial effort that attackers are unlikely to make if it only unlocks access to a single server (yours).


Another way to view that question is to consider the server key. In SSL/TLS with DHE, the client and server do a Diffie-Hellman key exchange, but the server also signs what it sends (usually with RSA). The server's key must also not be broken by attackers, since otherwise that attacker could impersonate the server and, again, run easy MitM attacks. Thus, regardless of what you do with the DH parameters, you still need to take care of your server key; in other words, it is not useful to make the DH part really stronger than the (RSA) signature part. This extends to the notion of key renewal: if you feel that you must renew your RSA key every three years (that's an example) then you may want to renew your DH parameters at the same schedule. It is useless to renew it more often than that. Similarly, since DH and RSA keys appear to offer similar resistance for the same length, you will want to use a 2048-bit DH modulus if you also use a 2048-bit RSA key.

Technically, key renewal is useless, but people tend to believe that key renewals grants supreme security benefits in some fuzzily-specified way, and they are quite fond of it. If you feel that you need to renew your RSA key on a regular basis, so that you may sleep better at night, then go for it. The same psychological reasons would apply to the DH parameters, so if renewal is your thing, then renew the parameters the same day.

(If we want to go into tricky details then we may argue that the server RSA key is for a different security model than the DH parameters, since signatures are for immediate server authentication, while the DH must resist recording and ulterior breaking, possibly years after, depending on the type and worth of the data that is protected. However, a past recorded conversation is, by definition, unimpacted by later renewals, so this argument does not ultimately apply to the present question.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.