> Breaking a second 1024-bit prime would allow passive eavesdropping on connections to nearly 20% of the top million HTTPS websites.

I'll point out that agwa's comment is relevant here in mitigation. Without any control over what primes are used on the server side, the only resolution would be to detect the server is using such a prime and then avoid communicating with that server until they've patched their systems. Perhaps someone who knows more about this could comment on how we could go about notifying websites they are using venerable primes?

Maybe a Chrome plugin attached to an IPFS client could be one method to warn on access of sites using default primes.

Nearly this entire comment is name-calling in the sense of the HN guidelines when they say: When disagreeing, please reply to the argument instead of calling names. E.g. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."

When posting to HN, please edit that out and stick to the substance.

https://news.ycombinator.com/newsguidelines.html

https://freedom-to-tinker.com/blog/haldermanheninger/how-is-...

Does the NSA have the means for such an attack? The article argues convincingly that they do.

Does the NSA have the motive for such an attack? Yes, if their mission is to gain access to as much of the signals traffic in the world as possible -- and I think that's been pretty well shown to be true.

Does the NSA have the opportunity for such an attack? Certainly, the Snowden papers have shown that the NSA has access to a wide variety of communications channels.

So, I think it's a perfectly sane argument to say that if the NSA haven't performed this attack already, they will certainly do so at some point in time against some target. And, if they are not, state intelligence organizations under other flags, such as China, will -- and China has shown a clear interest in attacking not just military but also commercial targets within the USA.

And how about not asking things such as "Am I the only sane one here?" then? You're surrounded with very smart people on this website, most of which will tell you that it's not insane to assume the worst of the NSA, and yet you hop around calling people crazy. If you're not going to do this for the sake of reason, at least do it for the sake of humility.

You want a sensible discussion, you start.

This is an asinine pair of questions to ask because they are logically unanswerable and interdependently blaming. If someone were to answer "yes, you are the only sane person here", then you've successfully elevated yourself to a level by which you can judge. If someone were to answer "no, you aren't the only sane person here" you get the sequential treatment applied to the rhetorical question "So you can see this response is (then) hysterical?" and you still get to judge.

Clearly you think I'm hysterical, regardless of whether it was asked as a question or not.

I have every right to voice my opinions and questions about how we can trust the tools we use for our craft on a day-to-day basis. I also have the right to the expectation the tools aren't being mass-monitored by our government as a cheap and insecure way of doing their job: law enforcement. I am grateful to be fortunate enough to understand how we technically implement these levels of trust in our tools and feel it is part of my social responsibility to share my views on these matters with my peers. I don't believe in allowing criminals to break laws, but I also feel that making things less secure by trying to monitor everyone for criminal activity is not the answer because I also think it's prohibitively expensive to eliminate all criminal activity. Maybe that makes me hysterical...but at least I don't speak for others.

I made ZERO blaming statements in my comment. I asserted that, from what I understand of the parent article, we have reason to suspect the government has cracked, or has the ability to crack, large primes. We know for a fact that a lot of software uses the default primes, so the logic goes that the government has the ability to monitor a portion of what we would normally consider secure SSL traffic. That individuals have little way of mitigating this "venerability" is an important one here because it may depend on us working together to determine the attack coverage and exposure. Without knowing those things, we're really at a loss to what could possibly going on with monitoring.

I will also point out that, if those cracked prime solutions exist, they will eventually fall into the wrong hands.

Moving to 2048 or 4096, or to ECC, thus seems like a prudent step whether you believe such intercept capabilities actually exist or not.

But it's not. That's the problem. There's no evidence whatsoever of it doing that.

Also, I'm not a pervert who gets kicks from listening to others' conversations. They apparently are.

Here is a comment written in the vars configuration file for easy-rsa 2.2.2:

    # Increase this to 2048 if you
    # are paranoid.  This will slow
    # down TLS negotiation performance
    # as well as the one-time DH parms
    # generation process.
    export KEY_SIZE=1024

[1]https://github.com/OpenVPN/easy-rsa

(I'm not sure Apache even defaults to enabling forward secrecy by default, without which you're not exposed to DH at all).

As of Apache 2.4.7, the default DH parameters have the same number of bits as your RSA key, and since CAs have required at least 2048 bit RSA for a few years now, you'll be fine.

OpenSSH does ship parameters that are larger than 1024 bits (in addition to 1024 bit parameters), and with the "group-exchange" kex, sufficiently-secure parameters should be negotiated with clients, although I haven't looked too closely to see if this might be vulnerable to downgrade attacks.

Last I looked nginx used fixed 1024 bit parameters, which is very bad. I don't know if this has changed or if there's a bug report.

  agwa wrote:
  > Last I looked nginx used fixed 1024 bit parameters, which is very bad.
  > I don't know if this has changed or if there's a bug report.