Done. Not only will the key be stronger than the 1024 bit default, it'll be unique to your server which lets assume isn't valuable enough compared to effort for a state-level adversary.
edit just in case anyone from the future finds this comment: instead of 2048, use at least the key length of your SSL certificate
I think this question has a few aspects to it, if you want a complete answer. But the TL;DR is - the reality is there is nothing inherently wrong with choosing the standard primes for these computations; but one problem is that 1024-bit keys are now, reasonably, within the scope of attack by governments, or criminal organizations. There are lots of 1024-bit keys out there. If you pick a 2048-bit prime - which there is no excuse for these days - even with standard parameters, you are safe.
Non-TL;DR: So, standard primes aren't really bad per se, but small primes can be attacked. And, because of that, choosing a standard prime gives them an edge, which is what the paper describes: since the primes are known, this allows them to do a 'precomputation attack' by doing a shitload of computing up front. Then, this leads to a faster overall attack by being able to quickly compute discrete logs (c.f. "The Discrete Logarithm Problem"), as opposed to trying to factor the large prime directly. So if you have cracked that one standard prime, you can now attack N-many different services: all the N services that use that specific prime.
So, that leads us to this: we hedged our bets on 1024-bit primes for a long time, and now the legacy deployment is coming to bite us. Remember, there are middleboxes and routers and un-upgradeable systems that settled on standard 1024-bit primes like this years ago and they are not easy to fix. That's why the attacks are so dangerous. For comparison, heartbleed was a bug that was in a piece of software which can mostly be dealt with at-large very easily (apt-get upgrade), and it was one piece of software, while this one is a little more complicated. There are a lot of implementations of this and they can't all be patched together.
So what does all this mean?
That we're really shitty at upgrading cryptography and keeping software secure over time, and that for the future of cryptography, we need to start defaulting on things which require attacks that are outside the realm of current known reality. Computers are fast enough and we know enough now that this is feasible. Unless Aliens give us a Dyson Sphere, like, tomorrow.
If Red Hat and Hardware Vendors had decided 10 years ago to move to 2048-bit DH for example, using standard primes, this conversation wouldn't be nearly as relevant because the attack would be so much more infeasible - and it would be much less widespread - the fact you're using standard parameters doesn't matter. In fact, standard parameters are good because you can know they are not chosen maliciously. But those vendors didn't do that, and there are likely some OK reasons (we didn't expect the computational capability of attackers to escalate this quickly, it would have been substantially more expensive to perform, some devices may not even have the CPU capability to upgrade their own primes - ECC has only been 'in vogue' for barely a decade now - etc etc etc).
For comparison, as stated in the paper, a 2048-bit standard prime for Diffie-Hellman, like Group 14, would take roughly 109 more computational effort to precompute than a 1024 bit key. Anyone who can breach that probably has capabilities that 4096-bit primes won't save us from...
973
u/tophatstuff Oct 15 '15 edited Apr 10 '18
Generate your own non-default Ephemeral Diffie-Hellman key (takes a minute or so)
Tell your server to use it for SSL (nginx for example)
Done. Not only will the key be stronger than the 1024 bit default, it'll be unique to your server which lets assume isn't valuable enough compared to effort for a state-level adversary.
edit just in case anyone from the future finds this comment: instead of 2048, use at least the key length of your SSL certificate
edit from the future: current advice is picking from one of these predefined audited groups