[Ach] ECDHE and DHE

[Aaron Zauner]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Jeff, Ian

ianG wrote:
> 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.
We're aware of that and it has resulted in a lot of discussion prior to
publication of the draft on our website.

>> 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.
Yep. Probably. Although we intend to update the paper over time (i.e.
have something like a release cycle with versioning of the paper).

> 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.
Well. Only because there is no rain does not mean there is not a
problem. People might just not have been putting enough effort into
exploiting weaknesses of NIST/SECG curves. I'm really worried about
that. ECC stuff computes _FAST_ which means backdoored curves can be
exploited _FAST_ and on a wide scale. I just don't feel comfortable with
the curves one finds in e.g. OpenSSL or PolarSSL. Don't get this wrong:
ECC is a wonderful idea and I'd like to see more (well tested)
curves pushed to SSL libraries.

Take a look at http://safecurves.cr.yp.to/

> 
> 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).
As far as I can tell there is no "best EC version" available. The issue
persists as most libraries have implemented those curves a few years ago
and there hasn't been any change to that. The DJB curves look promising,
although there is only very limited support in software and libraries as
of today.

> Chacha20/Poly1305 modes are very experimental, also they and are
> aimed as a short term AE compromise before CAESAR delivers.
Google recently pushed a draft of an RFC regarding ChaCha20/Poly1305 in
TLS, Chrome does already support it. And as far as I know they are
working on NSS and OpenSSL support.

> 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.
Correct.


Aaron
-----BEGIN PGP SIGNATURE-----

iQIcBAEBAgAGBQJSysIxAAoJEOTbZJL9ubXVrJUQAK9FZAtD2CZGdA8vcUHQI37v
T7QvfZXuNCIp+zW8uiFafHQ1IuJafDTSdgqu1+3MDi5fp9/yuS/tye7F3Kcm0jpe
mH0Wjbt9WI6DakOL9Mp3U/dPZzUAPwnQbJl/hrokeXFIwkmZhs+QGlYjGjziTOUx
NQjJWc2egbXlHb+C0XtWH06/+rRaWxqZnpQpw2rd/IyuJ1RFJyGFMnujpRh4mO5v
Z0E1PfIkxBgRiuEyyIaVtqzgM4KKOuKy4OIDbbFQM0Smchzb2ZbMIP5RCLMwArpX
zHduU5mNhvx66uJtOBSDkbLrFPfF1vSPBvZfx7ZcIkuAoHp24Uf1j+NkaGczPupg
JCAsYQqm7uGsKO34TjVWUwdQxOsRSvpTsvHhDrdE7PLcmv76SRaQusz1z7+A/Z2C
1LVaKqInJ2dnNse4Xv5s3YFKm7SCufH+W8ChLQkqNfEvoOP2pY4L+IDejxatAK/6
p/3uPb42TfUFECrvFcwiXhbNWZAXJWDpV42ppWebcikZh4gkUI1XJ5lzFzo++Gx7
oS3fihrocjBV1e0ISku7POU+VCbuXdlkhdgcOjyYApSRMwQkN0RKDao4cvXk24Cz
2pfbscB/ASR+mvinQq3zTZRmDUU6WDInlklTil7LDAP40A9RlQLYULOYr6+YKpTx
ssdwRNUoWCs3mBvx9bkU
=QSgh
-----END PGP SIGNATURE-----