[Ach] ECDHE and DHE

ianG iang at iang.org
Mon Jan 6 08:46:16 CET 2014


On 6/01/14 00:29 AM, Jeff Hodges wrote:
> Putting DHE ahead of ECDHE is not great. The prohibitive cost of DHE
> without elliptical curves means that the major web services that
> currently support DHE would probably have to remove its support
> completely if they weren't able to soften the blow by having ECDHE
> cipher suites preferred. Asking smaller websites, that have much less
> security risk and much more opportunity cost for that CPU and network
> time, is not kind.
>
> It is known that the NIST parameters are not ideal, and folks running
> *DHE cipher suites look forward to ChaCha20/Poly1305. However, that
> won't be a choice for a non-trivial amount of traffic for some time;
> longer, I believe, than Better Crypto's time-to-publish.
>
> It is unfortunate, but the choice that more likely gets readers to
> deploy the Better Crypto recommendations appears to be supporting ECDHE
> cipher suites first and prepping the readers for a world of
> ChaCha20/Poly1305.


Cautious +1.

I think I am inclined to agree that we may as well recommend the better 
EC stuff.

There is a cloud over all of the standardised curves.  But so far, there 
is no rain.  If there were rain, if we knew what failures there were, we 
might be able to respond.  Say, with RSA only.

But in the meantime, find the best EC version and use that (I can't say 
what that is likely to be, my knowledge doesn't extend nearly as well 
into public key stuff).



Chacha20/Poly1305 modes are very experimental, also they and are aimed 
as a short term AE compromise before CAESAR delivers.  What presumably 
is happening is that the TLS people are also looking at the Curve* 
family and intending to slot one of those in as a wide-scale replacement 
for standardised curves.  But both of these could be a long long way 
off;  the delivery cycle for TLS changes is minimum 3.5 years [0]. 
There is IMHO little point in factoring these improvements into the 
equations, the schedule is too hard to judge, we have to wait and see.



iang



[0] http://financialcryptography.com/mt/archives/001210.html



More information about the Ach mailing list