Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

Is there a best practice for Diffie-Hellman parameters (p, g, and q) used on a web server?

The server is using ephemeral keys, but should the parameters be rotated on a regular basis? Is it OK for the server to keep them fixed for years (in the source code)? Or should they be generated uniquely for each site?

This server does not appear to be under NIST and FIPS, so I don't believe they need to be fixed for compliance.

share|improve this question
1  
That depends on the security parameters you use to generate the parameters. If you have 2048 bit for $p$ and $224$ bit for $q$ you are definitely on the safe side for the next years. You may look here for an overview. –  DrLecter Dec 9 '13 at 12:33
    
Thanks DrLecter. "2048 bit for p" - nope, its 1024; see ngx_ssl_dhparam, near line 600. "224 bit for q" - the project did not provide q. "depends on the security parameters you use to generate the parameters" - I think I'm going to regenerate them with a known q (all I know at this point is p is not a safe prime because its failing a validation check). –  noloader Dec 9 '13 at 13:01
    
You did not link to any server implementation in your question ;) But clearly the size of the parameters (if you take them for a shorter time or for a longer time) also depends on the expected load. If you use ephemeral keys there is no reason to protect the parameters or use distinct for different sites. –  DrLecter Dec 9 '13 at 13:13
    
Thanks DrLecter. The source file in question can be found at trac.nginx.org/nginx/browser/nginx/src/event/… –  noloader Dec 9 '13 at 22:29
add comment

1 Answer 1

up vote 3 down vote accepted

I will address your question below, however I have a serious concern that I want to bring up first. I glanced at the $p$ used in ngx_ssl_dhparam, and it is not immediately obvious that it was chosen correctly. Unless you know that whoever generated that value knew what they were doing, you should select a different value.

The security of DH depends on, among other things, the factorization of $p-1$. If $p-1$ has a prime factor $q$ (and $g$ wasn't selected such that $g^{(p-1)/q}\equiv 1\ (\bmod p)$), then an attacker, seeing the DH public value $g^e \bmod p$, can determine $e \bmod q$ with $O(\sqrt{q})$ work. This means that if $p-1$ has a number of moderately sized factors (which will often be true of randomly chosen primes), and $g$ wasn't carefully selected, then you'll be leaking a significant amount of information; quite potentially enough to make DH completely insecure.

In your case, we have $g=2$; this would appear to make it unlikely that $g$ was chosen to avoid small factors. And, if $p$ were a safe prime, this would not be much of a concern (because safe primes have no small factors to $p-1$ other than $2$), however you stated (and I have not confirmed) that their specific $p$ is not a safe prime. I do note that, with $g=2$, your group has $g^{(p-1)/2} \neq 1$, and hence you do leak at least one bit of $e$ -- if that were all you leaked, that would not be much of a concern; however it begs the question "what else is being leaked".

I haven't checked if your $p-1$ has small factors; unless you check (or you trust whoever generated it), I would strongly urge that you use a different value of $p$. This specific value of $p$ might be secure, however I don't know that (and I suspect you don't either). When I am asked for recommendations for DH groups, I always send people to the IKE groups; those are all safe primes (and work well with $g=2$, not leaking even that one bit)

Now, to go back and answer your question: no, you shouldn't have to rotate the group parameters on a regular basis. It turns out that solving the problem "given these $N$ DH exchanges over the same group, solve any one of them" is not actually any easier than "given this 1 DH exchange, find the shared secret". That is, if the group is weak when you reuse it for DH, you shouldn't be using that group in the first place.

On the other hand, a 1024 bit value of $p$ is getting to be fairly small nowadays. NFS has been used to factor a 768 bit value recently; it should not be that long before it could practically be used to solve 1024 bit DH problems (which would mean that your group could be broken, even if $p$ was chosen without any inherent weaknesses). I would suggest you consider at least a 1536 bit $p$ (and preferably a 2048 bit value); from what we know, those should be secure for a number of years.


Update: I just double-checked; $p$ is indeed a strong prime, that is, $(p-1)/2$ is also prime. Hence, the concerns I raised about $p-1$ having small factors do not apply; there is a 1-bit leak (because of the factor 2 of $p-1$), however there is no other leakage.

My concern about the size of $p$, and whether that would be secure long-term, still remain. I'll leave in the comments about weaknesses that may arise with $p-1$ having small factors; even if they don't apply in this case, future readers may find it useful.

share|improve this answer
    
Thanks poncho. "p is indeed a strong prime" - my bad. I did not explicitly perform a primality check on (p - 1)/2. Its depressing how much begins to fade over time.... –  noloader Dec 9 '13 at 22:32
    
Thanks again poncho. Here's what I did (that caused me to incorrectly call p 'non-safe'). Set q = (p - 1)/2. Then, set n = g^q mod p. When I checked n, in was not congruent to 1. –  noloader Dec 9 '13 at 22:35
1  
@noloader: $g^{(p-1)/2} \bmod p = 1$ iff $g$ is a quadratic residue modulo $p$ (and, in this specific case, $g$ isn't; $p = 3 \bmod 8$ is enough to determine that with $g=2$). That has nothing to do with whether $q$ is prime or not. –  poncho Dec 9 '13 at 22:46
    
Thanks again poncho. "When I am asked for recommendations for DH groups, I always send people to the IKE groups" - yeah, I used the same in the past. But I'm now wondering if its a good decision given the Snowden revelations of surreptitious committee infiltrations. Plus, I think static parameters are similar to static keys. Once they become fixed, it becomes cost effective for an attacker to break the one instance since the cost can be amortized over the entire user base of the parameters. –  noloader Dec 10 '13 at 0:44
    
@noloader: if you're worried about the NSA having back doors in the selection of the groups, that is unlikely; those groups are of open design, and the majority of the bits come from the binary expansion of $\pi$. –  poncho Dec 10 '13 at 2:05
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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