Fewer IPsec Connections At Risk From Weak Diffie-Hellman (threatpost.com) 28
msm1267 writes: A challenge has been made against one of the conclusions in an academic paper on cryptographic weaknesses that may be the open door through which intelligence agencies are breaking encrypted connections. The paper, 'Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice,' claims that a massively resourced agency such as the NSA could build enough custom hardware that would crack the prime number used to derive an encryption key. Once enough information is known about the prime, breaking Diffie-Hellman connections that use that same prime is relatively trivial. In the paper, the team of 14 cryptographers and academics who wrote it claim that upwards of 66 percent of IPsec VPN connections can be passively decrypted in this manner. Paul Wouters, a founding member and core developer of the Libreswan Project, as well as a Red Hat associate, said that researchers are jumping to a conclusion because of the way they scanned and tested VPN servers, and that the number is likely too high.
Key Exchange (Score:3, Interesting)
All key exchange algorithms are vulnerable.
You can't negotiate a key without secrecy in the first place. Certs don't cover that because the CA model is inherently broken.
Re: (Score:3)
Re: Key Exchange (Score:5, Insightful)
The NSA will just store your 2 hours of traffic and decrypt it later.
Re: Key Exchange (Score:4, Informative)
That won't work.unless the NSA/GCHQ get lucky. The premise of the original article was that a relatively small number of primes are precomputed at huge expense and the results stored in a relatively small database (a few GB in size). If you are changing that prime every two hours to one that the NSA have not precomputed then they are going to be unable to keep pace with the required precompution to continue decrypting your communication.
As long as it takes the NSA longer to precompute the prime you are using than you are using the prime for you are good to go.
Now of course if I where the NSA I would be designing custom hardware to do the precompute, and would expect it to be way way faster than the original analysis suggested. It's like the difference between doing bitcoin mining on a CPU compared to custom silicon.
Re: (Score:2)
> every installation
And there lies the problem, the installation could be years old.
Re:Key Exchange (Score:4, Insightful)
All key exchange algorithms are vulnerable.
And all absolutes are false.
Re: (Score:2)
I don't know why you'd say that applies to IPSEC VPNs:
- Create your own CA.
- generate the public/private key on each VPN device/machine
- send the CSR (public key) to your own CA
- then create certs for each CSR (a certificate is public key signed by CA)
- put the CA cert on each VPN device/machine
- put the certs on each VPN device/machine
Where is the problem ?
Well, sounds like he's right (Score:3)
While their vulnerability numbers are probably off by a magnitude or two, that doesn't negate the idea behind the paper - just the importance.
Re: (Score:2)
The encryption is fine. The original key generation process is flawed. Regenerate keys correctly, and the traffic is secure(*) again.
(*) At least to the point that (according to TFA) it should take the various TLA’s about a year per key of Very Expensive computer time to break.
Re: (Score:1)
Re: (Score:2)
So the new meme is s/Lee/Schneier/g now?
Elliptic Curve (Score:2)
Re: (Score:2, Informative)
We have Diffie-Helman (DH) [wikipedia.org], Ephemeral Diffie-Hellman (DHE), Elliptic Curve Diffie–Hellman (ECDH) [wikipedia.org], and Elliptic Curve Ephemeral Diffie-Hellman (ECDHE).
Re: (Score:2)
Note, however, that they also consider DH-2048 acceptable. I believe the general consensus is that it will be secure until about 2020.