[Ach] ECDHE and DHE

[ianG]

Hi Aaron, some off-topic chitchat


On 6/01/14 17:48 PM, Aaron Zauner wrote:

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

True, absence of evidence is not evidence of absence.

But how do you disambiguate the absence of evidence from blind luck?

 From myth and fantasy?  From FUD & Marketing?  From government policy 
to weaken you and employ techies and corporates on charity programmes 
for dying industries like PKI?

This is why I ask for rain, so as to separate the science of weather 
from the dance of the rainman.


> People might just not have been putting enough effort into
> exploiting weaknesses of NIST/SECG curves. I'm really worried about
> that.


Well, I guess we'll see some more attention on this.  I saw a proof of 
concept on the DUAL_EC backdoor recently (didn't read it tho).


> ECC stuff computes _FAST_ which means backdoored curves can be
> exploited _FAST_ and on a wide scale.


It can only be exploited on a wide scale by those that can map and 
attack your traffic.  For the session stuff, this is pretty much the 
telcos (immoral), national governments (qausi-legal if kept secret) and 
foreign spooks (illegal, espionage).  So even if it were to happen, 
there isn't a scenario where everyone is suddenly at risk of everything. 
  And we know that those who will do these MITMs will also think 
carefully about the costs of being caught.  So even a found-weakness in 
EC is not going to cause the house of cards to come tumbling down.


> 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/


Yep.  Me neither.  What is surprising is that we've been using the stuff 
for 10 years, and now, only now, is someone poking holes in it.

However, still no prize.  If Dan & Tanja found an exploit, I'm pretty 
sure they would shout it from the rooftops.


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


That then is a problem.  So you might as well use whatever is most 
widely deployed.  And count is as a risk experiment.

Ya know, there is huge value in having a body of 768 bit keys out there 
in use, because then we get to find out when it breaches.  The attacker 
envelope is critical information.  We only found attacks on 512b in the 
last 3 years or so.  While the sun shines, make hay...


> The DJB curves look promising,
> although there is only very limited support in software and libraries as
> of today.


Right. We have to separate what's available from hope & dreams.

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

Right.  Not on our table for years, I suspect.  The OODA loop I've 
measured at 3.5 years *when they care* and presuming they really care 
this time, it'll be about the same, not a lot less.  (I'm pretty sure 
about that because as a community they continue to deny the OODA loop 
syndrome they are trapped in.)

   http://financialcryptography.com/mt/archives/001210.html

Lesson on OODA loops and their relevance to security:

   http://financialcryptography.com/mt/archives/000991.html

With boy's own references to WWII, good for both sides :)


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


In this game, we're always waiting...



iang