I think &quot;close to a minute&quot; is far too optimistic for the time required :-( -- note that the prime for DH is supposed to be a safe prime.<p><a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Safe_prime" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Safe_prime</a><p>You can contrast<p><pre><code>  openssl dhparam -5 2048
</code></pre>
which generates 2048-bit Diffie-Hellman parameters, to<p><pre><code>  openssl genrsa 4096
</code></pre>
which generates a 4096-bit RSA key (containing two 2048-bit primes) and note that the second is dramatically faster than the first. On-the-fly DH parameter generation is <i>really</i> slow.<p>However, generating 1024-bit parameters is probably fast enough to do on launch or install. Under the authors&#x27; estimates this might be fairly safe today because the adversary will have to spend many millions of dollars to attack your individual service (and you could change the parameters once a day or something if you wanted). But I think the authors agreed that large predistributed parameters make a better tradeoff for most cases.<p>There is an RFC about to issue listing such parameters<p><a href="https:&#x2F;&#x2F;datatracker.ietf.org&#x2F;doc&#x2F;draft-ietf-tls-negotiated-ff-dhe&#x2F;" rel="nofollow">https:&#x2F;&#x2F;datatracker.ietf.org&#x2F;doc&#x2F;draft-ietf-tls-negotiated-f...</a><p>Edit: I possibly shouldn&#x27;t refer to &quot;the authors&quot; in the third person here, because you are the lead author.<p>Further edit: &quot;Close to a minute&quot; is actually not a bad estimate, but the variance is <i>very</i> high! So it can easily be considerably worse.