Slashdot Mirror

If you stupidly standardize on "use Diffie Hellman for key exchange" and then it turns out that there's a critical flaw in Diffie Hellman, then you're basically an idiot who's written a useless standard.

For the record, the current problems isn't that there's a critical flaw in the Diffie Hellman key exchance itself - there's no fundamental problem in the way Diffie Hellman works.
The problem are the implementation (who are rather lazy in their approach to pick random prime).

Or to put an example: it doesn't matter if AES is the currently most un-crackable and resistant encryption algorithm when everybody repeats one of the vowel 8 times in a row to pick an 8 caracter password:
you'll just defeat it by bruteforcing using a dictionnary only containing 6 entries (on for each vowel).

Same actually happened for DH:
DH works, but some implementation only use small primes, and nearly everbody uses one of the few precomputed prime that comes out of the box.
And the largest part of the work for cracking depends on this prime, so if there's only small number of primes used in the wild, you just need to spend your cracking efforts on those few primes, and bam! you've insta-cracked the communication of everyone clueless enough to use the same prime.

Same also happened with DSA a few year back. It also depends on prime number, cracking DSA also relies on guessing the prime. If everybody picks just one of the few prime of some default list instead of computing a completely random prime, this dramatically reduce the size of the dictionary you need to use to brute force the key. It's possible to crack the private key just by trying the few common prime used by everyone.

So it's not really a standard, just a way to say "insert proprietary module here, which may or may not actually be compatible with the content".

It is certainly a standard: it's a standard that defines the interface for the DRM plugin. It contains the proprietary module needed to only the plugin, instead of all of Silverlight or all of Flash, and so is a huge win.

You don't ever want to specify the crypto used in a standard anyhow, because crypto changes faster than standards. I worked on the standard for encrypted tape drives. You don't specify stuff like "use AES", you specify stuff like "describing supported encryption methods" and "process to select the protocol used for key exchange". If you stupidly standardize on "use Diffie Hellman for key exchange" and then it turns out that there's a critical flaw in Diffie Hellman, then you're basically an idiot who's written a useless standard. (Or insert DVD/Bluray crack here, but I know little of those).

So, the most you ever do is standardize the interface to select the crypto bits (and the data exchange and that trivial stuff), not the behavior of the crypto bits, unlike the rest of a standard.

...Interdiction is where it's at: https://www.techdirt.com/artic...

Or maybe use IPSec / SSH with DH Group 19 - that's not looking too clever either: https://weakdh.org/imperfect-f...

All in all, if your threat model includes the NSA then reviewing 30m LOC may seem like a good place to start but in practice.....

SSL isn't a good example of a protocol done right by amateurs.

The fact that SSL didn't generate a barrage of FUD from certain three-letter agencies is the surest sign that SSL sucks butt.

Ref: https://weakdh.org/imperfect-f...

(oh, and I find it hilarious that the above is in an https link).

This is the original logjam attack from May this year.

Even the PDF points to the same site:
https://weakdh.org/

maybe there is some security flaw with DHE that I haven't read about yet and that is why its turned off

Logjam. TLDR; about 100k hours of CPU time can build a dictionary to crack most session keys in less than 90 seconds for 512bit primes.

Logjam is a protocol attack that tricks the victim(s) into using small-ish prime (i.e. 512-bit) for the Diffie-Hellman key Exchange (DHE). Their demonstration which required they were able to do a large amount of pre-computations (100k hours of CPU time ==> 11 years-worth if using a single CPU) which allowed them to crack individual session keys in less than 90 seconds.

Since browsers, servers, and libraries should be patched to the protocol vulnerability, back in May 2015, and servers are encouraged to use be (re-)configured to use 1024-bit or larger Diffie-Hellman groups. Entirely disabling DHE is not necessary, and to conclude that DHE is broken is to misunderstand the situation.

Likewise, while Triple-DES is largely a legacy symmetric encryption algorithm these days, as far as I know, there has been no indication that is is weaker than its perceived strength of 112-bits keys (due to a meet in the middle attack). No one is encouraged to deploy anything new with 3DES support, existing usage is not considered insecure. AFAIK it is still acceptable to US NIST for secure non-classified government usage, and with PCI (online US credit card gateway requirements).

maybe there is some security flaw with DHE that I haven't read about yet and that is why its turned off

Logjam. TLDR; about 100k hours of CPU time can build a dictionary to crack most session keys in less than 90 seconds for 512bit primes.

I asked my mom to to break crypto with open-source software...

She'd also have to be in a position to intercept the traffic to begin with. The article's problem-description is rather silly, indeed.

I also do not see, who would still be allowing weak ciphers on their servers — after all the earlier SSL-vulnerabilities we went through in the last 6 months, that is... But the report on the matter estimates 8.4% of the top million web-sites and 3.4% of all HTTPS-using sites as still vulnerable. Shrug...