[tptacek]

Curve25519 is what's going to happen. The IETF/IRTF process is a clusterfuck of monumental proportions, and has slowed adoption down, but Chrome and Firefox will support Curve25519.

The NIST P- curves in TLS ECDHE have sound implementations in Chromium and Firefox. Nobody should be using conventional DH in preference to ECDHE; if you can't trust a browser's P-curves, you can't trust their GCM either.

[ultramancool]

> if you can't trust a browser's P-curves, you can't trust their GCM either.

Is that true though? I mean, from what I've read GCM seems much easier to implement than a full ECDH. I mean, have a look at some of the things published by Bernstein and Lange, https://www.hyperelliptic.org/tanja/vortraege/20130531.pdf

They do certainly have a horse in the race, but it's still interesting. They and others have also raised concerns about potential backdoors in the NIST curves, which is, while still unproven another reason why one might avoid them. They failed to do things as basic in the cryptographic community as using "nothing up my sleeve" numbers, it just seems sketchy at best to me. The random curves at least. The others are probably still just fine but the random ones are the most popular in TLS.

[tptacek]

GCM is extremely tricky to implement safely.

ECDH itself is very easy to implement; it's just DH (which is probably the simplest algorithm in cryptography), but in a different group.

ECC (the group) is hard to implement safely. The NIST P-curves are tricky to implement relative to Curve25519.

But there's also a lot more study of how to safely implement the NIST P- curves than there is for how to make a constant-time GCM.

I don't know. They seem like comparably difficult tasks.