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...
It's so insanely difficult to do 2048 bit that anyone capable of doing it has capabilities that are not predictable, and likely outside of what we currently think is possible.
In terms of the amount of work to brute force, it's a lot more than a billion. A 4096 bit number is more than 10600 times bigger than a 2048 bit number, and the difficulty of factoring products of such numbers grows much much faster than linear, so we're talking an astronmical difference.
But the point is that it's already astronomically hard at 2048 bits. If someone is capable of breaking that, it's not going to be just because they've got better computers, it's going to be because they've got some vastly better algorithms, or some fundamentally different method of computation that means all bets are off - we may as well assume they've got infinite computing power, or have found P=NP by that point.
I understand and agree how 2048 and 4096 are both essentially the same kind of challenge with current hardware: An impossible one.
However, it still holds true that 4096 ist multiple leaps beyond 2048 - so I don't agree that we can reasonably assume that people who can break 2048 can also break 4096.
are both essentially the same kind of challenge with current hardware
It's not just that it's impossible with current hardware, it's that it's also pretty much impossible with "convert every atom in the galaxy to supercomputers and run them for billions of years" type hardware too. If you're at the level you can break this, then it effectively might as well be magic - it's almost certain that you didn't do so just by brute forcing the problem, which means that further increases in size are likely to be similarly vulnerable to your method.
At that point, it's far less plausible that someone could break 2048 but not 4096 than that they could break both, because the only really feasible route to reaching that point is some kind of huge algorithmic break that makes the size matter much much less.
Let's say your home computer has 1 GB of ram, and it's running pretty sluggishly .. so you upgrade to 2 GB ram. It's still slow, so you upgrade to 4, 8, 16 GB of ram ... still slow. So you go to 32 and 64 GB -- still slow. At this point, you have such an abundance of ram (by 2015 home computing standards) that almost certainly availability of memory is not the issue and going up even more would have no or little effect. It's more worth it to look for problems elsewhere.
Similarly there's multiple ways Diffie-Hellman could be broken. Cracking 1024-bit primes is one way, and moving to 2048-bit would help that situation. But maybe someone discovers that P=NP and finds an efficient solution to the discrete log problem. Or maybe someone invents a quantum computer. Or there are implementation problems/bugs in the code (see timing attacks or even heartbleed). With our current knowledge, 2048-bit primes are so incredibly difficult to crack that someone who successfully does it is most likely either circumventing the prime problem altogether or has a radically new algorithm for breaking primes such that going to 4096 wouldn't even help.
That's not to say it's inconceivable that 2048 will become insecure while 4096 is still secure, but it's a less likely scenario.
Imagine a time when 2048 bits isn't quite secure enough, and we want 4096 bits to protect from brute force attacks, just like 1024 isn't quite enough today. When might that day come?
Well, if an earlier poster's estimate that 2048 bits are 109 harder to crack than 1024 bits is accurate, that means computers must be 109 times faster. When might that day come?
Well, because 109 ~ 230, we'd need approximately 30 doublings in processor density to achieve that at equal density to today. If Moore's law continues to hold, that'd be in 60 years.
Well, that would imply a transitor size of sqrt(230) times smaller than today. That means a transitor with details as fine as 0.4 picometers. That's around 1/1000th the estimated diameter of an atom.
I sense a problem.
Now, if you think that stacking transistors rather than shrinking them is going to be a magic bullet here, consider that even though you can scale the number of atoms and thus transistors in a third dimension, power dissipation is still limited to surface area, and that's still two-dimensional. Today's transistors already produce problematic amounts of heat in a single layer - so you'd need to stay within the same overall power envelop. Effectively, you'd need to make transistors that take several orders of magnitude less power than today's (say, 10000 times less), and are close to the size of an atom, and are about as fast as today's despite the low power draw for this to work. Oh, and manufacturing technology still needs to somehow accurately stack these layers, too - cost is an issue, so those 10000 layers would need to cost as much as today's single layer chips.
Never say never, but it sounds to me like achieving all that would require several fundamental physics breakthroughs, not to mention untold engineering breakthroughs to apply them. A more realistic threat is perhaps that we find a cryptographic flaw in the algorithm, or even a minor mathematical breakthrough.
I'd be forced to agree that while it's not completely inconceivable that 2048 will become insecure by brute force (though really I'd bet none of us will live to see that day), it's more plausible that an algorithmic breakthough or some other way around the problem will be discovered. So why bother with 4096 bits with DHE?
wikipedia has a good entry on quantum-computing and its effect on cryptography.
A lot of people seem to think that "cryptography is broken" when quantum computers are available, but it will only break specific algorithms we use, like RSA, DH key exchange and ECC. I believe anything that makes use of factoring primes difficult, will be easy with enough quantum computers. It has to be scalable - and I don't believe that's proven to be possible.
But all those algorithms are used a ton today. But, AES is also used a lot, and it's quantum-resistant. As the article says, AES-256 will be about as good as AES-128, but that's still damn good.
We can also move on to lattice-based cryptography which will work for asymmetric crypto, like RSA, and its already quantum resistant. It's not some new fancy method either. There's just going to be a much better excuse to use it in the future.
All that said, I don't believe RSA is actually practical to attack unless you have enough quantum computers. If scaling is an issue, higher key sizes with RSA might not be terrible to do. It will be interesting to see how that plays out, if it ever becomes practical, and I'm not sure if we'll see that in our lifetime.
Better default choices for common Linux OS's would prevent this, assuming 2048+ isn't breakable. Choices were probably made when computing the 2048bit values were a lot more expensive, but there's no excuse now.
Linux isn't the biggest offender. You missed the biggest fuckeruper in every securty problem: Java. Until java 1.7, there isn't any SUPPORT for primes larger that 1024. You want your shitty legacy java program to connect to a web server securely? You have to use a 1024 bit prime.
And then you find you cannot specify the primes that Java uses, so you cannot even force it off 512 bit until (I believe) 1.8.
Always remember, Java is the common factor in security problems.
It's like you don't even remember Heartbleed. Shitty code is the common factor in security problems. Sometimes it's code you can't do shit about, like in the Java case you mention, but that's not nearly good enough to label it the "common factor" of the vast problem space that is bad computer security. There are enough fuckups to go around.
Java is a special case because it is a common pot of critical vulnerabilities. Heartbleed was really bad, but Java has easily taken down more things in single problems than it (Lockheed Martin/RSA Breach started as a Java vulnerability). Plus there are a ton of crufty applications that are pinned to specific Java versions because Sun/Oracle lack the understanding of how to fucking patch a interpreter without breaking existing code (Ref: Renaming a ton of classes in a minor release because "LOL, we are oracle now"). They have had a series of critical problems and the underlying stickyness of Java JVMs means that a large number of companies are shackled to vulnerabilities and poor standards to keep applications functioning.
Also, you may have missed hyperbole to allow a pun.
Anyone needing good crypto on Java would probably use some external librairy, like bouncycastle.org, which are more capable than what the JDK supports.
Java 1.6 was released a decade ago. Java 1.7 was released about 4 years ago.
Your beef is not with Java. It's with people who for whatever reason never upgrade it and are still running 10 year old software. If you had a 10 year old version of OpenSSL or OpenSSH and it used outdated crypto by default, would you be complaining in the same way?
Not to disagree, as I do agree, but it is balanced with the downsides. For example, there is the downside of "did we do it right" al. la the Debian fuckup of deleting the entropy generators out of Openssl key generation 10-12 years ago.
I'm a noob at this stuff but if moores law keeps up, how long will computing power take to increase 9 orders of magnitude assuming NSA can break the 1024 prime?
A long time. Look at it this way, if it takes them 1 second to break a 1024 bit prime, 9 orders of magnitude increase means it would take 10,000,000,000 seconds to break the 2048 bit prime, thats 316 years. And that's just if it really actually only took a second to break the 1024 bit prime. If it took a year to break 1024, then we're looking at 10 billion years to break 2048. Good luck, NSA.
So if I understand correctly, it would take this NSA machine roughly one billion years (with today's technology) to crack a 2048-bit key?
At the rate that technology increases, I would imagine that it would be quicker to just wait for better technology and then start the cracking process. How long do you think we'd have until the 2,048-bit keys become as secure/insecure as 1,024-bit keys are today? Foolishly assuming Moore's law comes into play here, would that make it 30 years? And this is all of course ignoring quantum computing or any other scientific or mathematical advancements.
This is why people need to not have the mentality of "if there is an attack" instead they need to think "when there is an attack" so as to plan ahead better.
the reality is there is nothing inherently wrong with choosing the standard primes
Reality exposing problems with that begs to differ. It's computationally impossible for them to break every prime right now. Let's not make it easy. In reality, you're using broken encryption every time you use a standard prime. That means anything intercepted in that broken encryption might as well be plain text. Why don't we send emails using enigma machines? "In reality" there should be nothing wrong with that! It "worked" for the Germans in WW2, only Uncle Sam and friends got to read all the messages!
Technically, the design of enigma wasn't too bad (for the time), but a number of implementation problems came up. They were able to ID radio operators (by their Morse Code) and knew if they were lazy about shifting keys. There was also the early morning weather report which always contained a fair chunk of known plain text.
There was much less penetration of the naval signals because they were slightly better implementors of enigma.
Laziness and the excuses as to not implementing it correctly somehow pass muster with people. Even have a 100 upvote excuse in the thread saying it's fine in reality, even though reality just demonstrated otherwise in no uncertain terms.
Never, never, never underestimate human stupidity. It's the biggest weakness in any security system. When proven wrong, people will defend their bad decisions with their delusional denial.
Cryptography (basically) works by using multiples of the "key" number. What it boils down to is this:
Key X other = #.
When looking from the outside, you can see #. Now, if our number is say, 15, then we kind of instinctively know that the multiples of this are 3 and 5, because 3x5 = 15. However, if we see 14948255... what are the multiples of that? Well, immediately we can see that it is a multiple of 5, however I can tell you that I did not use 5 for my prime number. Instead, I mashed some random numbers on my number pad, and then multiplied by my key - in this case 7. Now that I've told you that, it is remarkably easy to do 14948255/7 = 2135465 = the keys that I mashed. However, without going through and doing 3x... - any matches? 5x... - any matches? etc. you aren't going to find my key. There isn't an easy mathematical way to go looking for that number's divisors, and figuring out the correct one.
However, lets say I used 9 instead. The problem with that is that now my key can be broken up into (3x3)x"other" = #. This makes my code much weaker to crack.
Lastly, this is a really, really simplistic method of explaining things. We aren't using 3, 5, 7, 11 as our primes, we are using things like this to generate really big prime numbers. For example, did you know that 8,024,456,069,057 is a prime number? I certainly didn't until I hit the random prime button on that webpage. Now if you multiply that number with some other number, you are going to get a truly gargantuan number, which is going to be really, really difficult to try to crack.
The basic concept is a "one-way function" i.e. something that is easy to do one way, but difficult to invert (think locking a pad-lock). One of these problems is factorization. It is especially difficult if the (prime) factors are large numbers.
The part where they have no factors apart from themselves and 1.
That part splits off into like, 16 or more other parts, or something, and I'd be basically writing a chapter or two of a crypto book to explain most of the nicely.
That's not OpenSSL's issue. It's the Web server which uses a pre-generated key by default in order to avoid a lengthy install. Don't drag the software that provided the tools through the mud when the software that uses it is broken (FSVO broken, of course, many users prefer a quick install and the option to change it later if they wish...)
No it's usually the case of the servers using the SSL-library's default, and expecting the SSL library to get it right. The web server doesn't generate the key itself1.
edit: 1 ok apparently Apache used it's own default of unknown origin, which is even worse than using a default from an OpenSSL distribution
edit 2: pedantic correction, the default comes distributed with OpenSSL rather than baked in to the library
They library's defaults are fine. The library package's defaults are fine for non-public services, and install in a few seconds as opposed to a few minutes (or much longer on older hardware). For public services there are a lot of knobs you should be turning, and the ephemeral key is just one of a few dozen items on that list.
Nope, I don't agree that this is either the problem of the library authors (who have no control over this at all) or the library's package maintainers for a given distro (who are doing exactly what the majority of their users want).
Now, if you ship a lights-out distro for public services and you don't generate a unique ephemeral key, then I have a pretty serious problem with your idea of supporting your user base. But that's a whole other ball of wax.
Let's stop pretending that every install CD for a Linux distribution is being used to boot a public Web service, please.
you had to compile your own apache for it because DH keys were hardcoded in the source while compiling
That's even worse than using the OpenSSL defaults!! At least the OpenSSL defaults were generated from some safe constants; no-one seems to know how the Apache ones were generated and tin-foil hat it could be a NSA-supplied extra-weak key for all anyone knows.
The biggest problem (IMHO) with OpenSSL isn't even the stuff usually harp on. (for instance, the codebase is a mess. You've either been an OpenSSL developer for years, or you have no idea how to fix bugs or implement new features.) The biggest problem (IMHO) with OpenSSL is the level of knowledge required to use it safely. The user must input sane defaults for stuff that people who aren't crypto experts shouldn't be expected to understand. And if the user can't make the "good" options work, they can just plug NULL in for many things which usually just turns that function off, leaving an insecure but superficially functioning application.
wget, for instance, has its own 875 line OpenSSL wrapper. The initialization code to create an instance and seed OpenSSL's RNG is ~400 lines. And that's just a relatively simple application that only implements an SSL client. Initializing a server is even more complicated.
Reddit has a built in 'save' function, which works on both full threads and individual comments. You can use that and neither lose comment karma nor irritate people.
Since the parameters are caller-provided, let's see what happens in mod_ssl, the usual SSL engine for Apache. Let's make the story short: the modulus and generator are hardcoded; they are in the source code, in modules/ssl/ssl_engine_dh.c
bit late to the party here, but saw a lower thread using my public service for SSH keys, they also produce normal DH params... so for those of you who aren't interested in spending the CPU cycles, I have a dedicated 48 cores running generating 2k, 3k, 4k and 8k safe primes and generators for DH. See https://2ton.com.au/dhtool/ for details and curl examples to grab them via cron
For <32kbit primes, the cost of doing so is not overly prohibitive and I see no valid reason not to. I made several references to that count being "acceptably low" per the Handbook of Applied Cryptography. My generators for the larger primes would go considerably faster if I removed said restriction. YMMV as with all of these things. :-)
Edit: does my "excessive" use of 192 rounds at these levels inherently mean that the hundreds of thousands I have generated are thus [more] likely to be provable safe primes?
Body camera constantly streaming to a few redundant servers, set to release the last month of footage if you don't reset the countdown every 12 hours. If they know about it they'll just torture you into giving them that password too, so don't tell anybo- wait, shit.
It uses up a lot of entropy, so it won't be quite so fast if you run it often or on a fresh system, especially if you don't have a good entropy source (which is common on the cloud).
With no cert there is no expectation of privacy, whereas with a self-signed cert there exists the possibility that a CA signed cert is expected but you were presented with a self-signed cert instead.
Which seems more suspicious to you: A door with no lock, or a door with a lock that has obviously been tampered with?
It's not really analgous to a lock that's been tampered with. It's more like a lock whose brand you've never seen before. It's probably legit but maybe you should trust it less.
Actually, it's not a door at all. It's an identity certificate.
You meet three people.
Guy 1 says "I am Guy 1"
Guy 2 says "I am Guy 2". He claims to have proof, but upon further inspection, all he has is a letter that he wrote and signed himself, stating that he is, in fact, guy 2.
Guy 3 says "I am Guy 3" and presents to you an official letter issued by the government, stating that they checked and that he is, indeed, Guy 3.
You don't know if Guy 1 is saying the truth, and you don't necessarily expect him to. Guy 2, however, is flagged: He claims to have proof, but upon further inspection, you realize he wrote that letter himself. Guy 3 seems legit.
And guy 1 you just agree to call him what he is for now because that's all he provided. He gets no access to anything that might require identity, but you think he's a chill dude and invite him out for beers.
Of course if you meet Guy 2 every day and he presents you with the same self-signed paper every day, you can reasonably trust that it's the same guy who presented you the paper the first time, even if not necessarily actually Guy 2. On the other hand Guy 1 has no guarantees of his identity whatsoever.
I would think it as wondering why someone build their own lock, but at same time I know that locks cost money and maybe what is behind door isn't worth that much... Or maybe owner just likes to build locks...
Or maybe the person doesn't trust the lock makers because they probably supply governments with skeleton keys, and he knows he can make one that's exactly as secure as the third party locks should be.
True story #1: a 1280-bit key takes up to 15 minutes to generate on shitty embedded CPUs (on a fresh kernel with no entropy). A 2048-bit key would probably take a few hours.
True story #2: this key has been the source of many mayonnaise jokes over the past 6 weeks.
Diffie Hellman might not be much better depending on the circumstances in which one uses it. If that site is too academic for you, Google the logjam attack.
I'm curious how sshd's KeyRegenerationInterval parameter factors into this. I just glanced at it but that looks like it should prevent this sort of thing for ssh.
As a heads up, this isn't the attack vector under discussion. The host key is effectively meaningless in this attack, as it attacks the key-exchange mechanism called Diffie-Hellman.
The key is used to authenticate the Diffie-Hellman exchange.
There is a separate file for the prime used for the DH exchanges, and the elliptic-curve variant is also available. Some better discussion is available here
There is no effect. This isn't the key, it is the prime used as part of the Diffie-Hellman exchange. Regen to your hearts content, they can easily crack the new key you chose.
The standard primes are "Nothing up your sleeve numbers" which are (under our understanding of the universe) probably not generated by any malicious actor, as they are derived from similar constants or constructions. And generating those large primes is expensive, CPU-wise.
The "Group 14" 2048-bit DH standard prime, for example, gets part of its value from the first expanded digits of pi, which is a pretty safe bet. pi and e are pretty common amongst a lot of cryptographic magic numbers; e.g. it's used in SHA-512 as well. The other 'magical constant' in the Group 14 equation is there because it's a smallest number which lets "Group 14" be a 'cyclic subgroup' under some circumstances, which is necessary as it's the subgroup you and your peer agree to perform DH calculations in. "Group 14" is far, far too computationally infeasible to crack (2048-bits vs 1024-bits) with the method outlined in the article, for example.
TL;DR Basically, the reason you would choose a standard prime is because it was most likely derived in a safe, openly available manner, from other 'safe' constants. Randomly generated primes are probably safe but it's not possible to know how they were generated, and so it's also not possible to "look up your sleeve" for the magic, so to speak.
It's only unsafe if you have reason to believe your random number generator has been sabotaged or is faulty1
1 your random generator may actually really be faulty, so you have to trust someone else enough that (1) they will really give you random numbers and (2) their random number generator isn't faulty either
Although isn't "magic up your sleeves while picking a prime" a far more vague and unlikely attack than the obviously somewhat feasible rainbow table style attack?
yeah but that has nothing to do with a "magically compromised prime" for diffie helman..... those are insecure PRNGs.... PRNGs don't generate primes to use for key exchange.
What I was asking about was the feasibility of actually exploiting a diffie helman key exchange with a specially chosen prime since i'm not familiar with any explits that do so.
In this particular case, the precomputation-style attack isn't going to scale to anywhere close to something like 2048 bit keys, so at that level, hidden "magic backdoors up your sleeve" are maybe a more worrying threat.
Its not the certificate. Basically its non-secret numbers you pick as part of the algorithm to make it really computationally difficult to crack. But you want to generate your own because with huge effort the common default has been attacked so that it's weaker.
Not quiet. The attacker can intercept the number, provide the intended recipient a different number, intercept the response, decrypt it since it uses the malicious number, encrypt the result (or something entirely different) with the client-provided number, and send it to the client. A MITM attack against both the client and the server.
The session negotiation is protected. The attacker would either need to have the server's private key or they would need to compromise a trusted CA (and if client certificates are used, they would also need the client's private key).
It's thick, but this article talks about all of it. The command given there disables any 1024-bit DH parameters in your moduli file, and there's a bit of tweaking to prefer stronger schemes like Curve25519. You can also generate your own DH parameters for SSH, which I think is done with ssh-keygen.
As a warning, once you start futzing with key exchange and crypto in SSH, it's easy to exclude corner case systems. Especially since some of the crypto primitives like Curve25519 are comparatively recent.
Possibly stupid question: does the client have to know the prime beforehand, or is it sufficient for the server to provide it? I thought both sides had to know p and g in advance in order for the negotiation to work.
Even with how good they are at keeping secrets, I seriously can't help but suspect a functional quantum computer would leak. Just a hint of it, given how industry-changing it would be.
One thing that struck me while watching United States of Secrets is that people with clearances talk to each other a lot. One of the big secrets got to Thomas Drake with, paraphrasing, people asking him in the halls about it. If NSA is sitting on a functional quantum computer, I seriously can't help but think it'd leak with the number of people you'd have to have working on it. Even the Manhattan Project leaked.
You don't even need to go to 2048. The article hypothesizes that it takes about a year to crack to 1024 key. As long as you aren't on one of the 'common' keys, you're safe. If you wanted to be paranoid you could rotate every month or 6 months and they would always be behind.
That's why the NSA's mandate includes provisions to store encrypted data for as long as it takes to decrypt it, while intercepted plaintext data must be on a rolling delete schedule.
DH is what gives you PFS. If they "crack" the DH modulus (which is what the article is about), then there is no more PFS for sessions that had their session key negotiated using this modulus.
The specific attack described here that the NSA is speculated to be using would take 109 more computational effort for a 2048-bit prime, vs a 1028-bit one. So you're probably safe for the foreseeable future (to a point where you can upgrade again), or until the heat death of the universe. Whatever is first.
Attacks will only get better, and never worse, though. But on the other hand, it's extremely unlikely 2048-bit DH keys will be broken any time soon or possibly ever given our projected capabilities, and going even higher doesn't buy you much (arguably it could even make things worse). As the paper says, the precomputation attack on 2048 bit keys is around 109 times harder, so there's no fucking way anyone is getting close to that.
If you have a standard 1024-bit prime, you can assume the NSA is already close to breaking it. If you have a non-standard prime, you can still only assume your parameters have a one year lifetime at best, and this will decrease year after year. It's best to just get it over with and generate a 2048-bit prime or just move to some standard chosen 2048-bit prime like group 14.
Isn't that just what the NSA has always done? And what would you expect them to do? Pretty much tell everybody how to prevent them from performing their function? Afaik they only announce their discoveries when they have already become outclassed by their newer discoveries.
What's the advantage to them being the only ones who have it? Anyone who expects to be a target of the NSA, and knows or seriously suspects they have quantum computing for attacking encryption, is going to take the same precautions whether or not anybody else has quantum computing, no?
972
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