Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to Protect Yourself from NSA Attacks on 1024-bit DH

eff.org

Post reply on HN
Print view View original

21–30 of 140 posts

Re: How to Protect Yourself from NSA Attacks on 1024-bit DH

#21

Post by MrRadar »

decisiveness wrote: post #12
diafygi wrote: post #2

Does anyone have links to bugs for the affected programs to make 2048 the minimum by default? It seems like we shouldn't have to continue to manually configure secure settings. OpenVPN? SSH? Nginx? Apache? Where are the bugs to make these not use insecure dhparams by default?

Easy-rsa[1] (OpenVPN's key/cert generation/signing tool) version 3 will generate a 2048 bit diffie hellman key by default. Previous versions of easy-rsa used 1024 bit as default. 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…

From what we know as long as it is a custom 1024-bit DH key and you're not being actively targeted by the NSA you are probably okay. That said, you should still upgrade to 2048-bit (or higher, if you're paranoid) ASAP.

Re: How to Protect Yourself from NSA Attacks on 1024-bit DH

#23

Post by rtb »

agwa wrote: post #8
ikawe wrote: post #6

The article says: You want to make sure that you don't see the text "_DHE_" in the list of ciphersuites.` And the article links to https://www.howsmyssl.com/ , which shows me these in my list of cipher suites: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 TLS_DHE_RSA_WITH_AES_128_CBC_SHA But the heading says: "Your SSL client is Probably Okay." Is https://www.howsmyssl.com/ out of date…

There's nothing inherently wrong with the DHE ciphersuites, as long as the server provides secure parameters. Since weakdh is really a server-side issue, and howsmyssl.com is a client-side test, a warning doesn't really make sense.

... but clients can guard against weak server-side DHE by rejecting DHE ciphersuites. So I think the GP was correct that this diagnostic should be updated.

Re: How to Protect Yourself from NSA Attacks on 1024-bit DH

#24

Post by olympus »

This recent publication illustrates a problem that we have trying to keep our communications secure. If we all use a single "strong" prime number with our crypto then the NSA has a huge incentive to pre-compute results from that single strong number. Now that we know that the NSA is doing this, we won't all use a proven strong number, and we will all start to do key exchanges with another method, and it will become the common thread that the NSA can attack.

So the NSA will pretty much always attack whatever common procedure we all use and find the weak point. If we all used different methods for key exchanges and encryption then we will all be fractured and the NSA can easily pick off their targets individually. What's the answer to this problem? Is there crypto that we can all use that the NSA won't be able to crack even if they have a strong incentive to do so? And why aren't we all using if such a solution exists?

Re: How to Protect Yourself from NSA Attacks on 1024-bit DH

#25

Post by MrRadar »

ikawe wrote: post #6

The article says: You want to make sure that you don't see the text "_DHE_" in the list of ciphersuites.` And the article links to https://www.howsmyssl.com/ , which shows me these in my list of cipher suites: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 TLS_DHE_RSA_WITH_AES_128_CBC_SHA But the heading says: "Your SSL client is Probably Okay." Is https://www.howsmyssl.com/ out of date…

The Qualys SSL Labs tester checks for weak DH parameters as part of its report: https://www.ssllabs.com/ssltest/

Re: How to Protect Yourself from NSA Attacks on 1024-bit DH

#27

Post by tptacek »

olympus wrote: post #24

This recent publication illustrates a problem that we have trying to keep our communications secure. If we all use a single "strong" prime number with our crypto then the NSA has a huge incentive to pre-compute results from that single strong number. Now that we know that the NSA is doing this, we won't all use a proven strong number, and we will all start to do key exchanges with another method, and it will become t…

Not really. This precomputation attack only works because attacks on 1024 bit discrete logs were already plausible.

We don't choose cryptographic parameters to make the NSA's job harder; we choose them to make the job implausible.

So it's exactly the wrong message to take from this paper that we should mix up parameters more; rather, the message is: don't use weak moduli.

Re: How to Protect Yourself from NSA Attacks on 1024-bit DH

#28

Post by tptacek »

kordless wrote: post #7
diafygi wrote: post #2

Does anyone have links to bugs for the affected programs to make 2048 the minimum by default? It seems like we shouldn't have to continue to manually configure secure settings. OpenVPN? SSH? Nginx? Apache? Where are the bugs to make these not use insecure dhparams by default?

FWIU of the situation, we have reason to suspect the government has 'cracked' the default large primes that are commonly used by a bunch of different software packages, including web servers. Assuming they have, the challenge is then defined as determining which applications and sites tend to use these standardized or hard-coded primes. > Breaking a second 1024-bit prime would allow passive eavesdropping on connectio…

The problem (defined as narrowly as possible) should be as simple as finding every application that uses 1024 bit Diffie Hellman and making it use 2048 bit Diffie Hellman instead.

Re: How to Protect Yourself from NSA Attacks on 1024-bit DH

#29

Post by olympus »

tptacek wrote: post #27
olympus wrote: post #24

This recent publication illustrates a problem that we have trying to keep our communications secure. If we all use a single "strong" prime number with our crypto then the NSA has a huge incentive to pre-compute results from that single strong number. Now that we know that the NSA is doing this, we won't all use a proven strong number, and we will all start to do key exchanges with another method, and it will become t…

Not really. This precomputation attack only works because attacks on 1024 bit discrete logs were already plausible. We don't choose cryptographic parameters to make the NSA's job harder ; we choose them to make the job implausible . So it's exactly the wrong message to take from this paper that we should mix up parameters more; rather, the message is: don't use weak moduli.

> don't use weak moduli.

By this do you mean don't use 1024 bit keys? Would using 2048 bit (or larger) mean that the NSA wouldn't be able to buy a computer that could do the computation within a year?

Why don't we all use 2048 bit keys then? Is the communication and processing overhead so high that we'd rather be vulnerable?

Edit to add: I'm not an expert, but I'm competent enough to force a certain level of crypto on my computer and to know not to trust the communication when a website forces a fallback to a lower level. But sometimes I wish there was a level of explanation (of why we want to do certain things) that was above what you would give to "Joe off the street" and below the explanation that you would give to a graduate student in cryptography.

Re: How to Protect Yourself from NSA Attacks on 1024-bit DH

#30

Post by arielweisberg »

schoen wrote: post #18
arielweisberg wrote: post #13

How can you tell if the commercial VPN service you are using is vulnerable? The client on mine is very easy to use, but has no debug output/log or console that I can find so I don't know what it is doing.

Do you know what VPN protocol it is? I wonder if it would be easy to figure out in Wireshark if you had a recording of the beginning of a session.

QUIC is what WireShark says I am looking at. I can see the DNS lookup, and then a stream of encrypted UDP packets with not much plain text in the payloads.

I get what the other poster says about asking the provider, but I wouldn't have much confidence in the answer.

Post reply on HN