Re: [Cfrg] Elliptic Curves - poll on security levels (ends on February 17th)

[Phillip Hallam-Baker <[e-mail]>]

On Wed, Feb 11, 2015 at 9:23 AM, Paterson, Kenny <[e-mail]>
wrote:

> Phillip,
>
> On 11/02/2015 13:59, "Phillip Hallam-Baker" <[e-mail]> wrote:
>
> >Knowing if we are going to do p=~512 or not makes a big difference to
> >what I would think we should be doing on p=~256.
>
> We're settled on Curve25519 and close relatives at the p=~256 (128-bit
> security level).
>
> The question about 192-bit and 256-bit security was intended to be
> regarded as being independent of that choice. From your message, it seems
> you don't think it is. Can you expand?


As I see it the problem with ECC is that people pushed it long before the
market was ready for it. A lot of FUD was thrown about and a lot of
confusion resulted. We ended up with 25+ curves.

The only reason to add another curve in my view is to enable the industry
to move from the RSA/discrete log era to a new era. But we can only do that
if the new proposal beats the existing standards embedded in legacy code on
every single feature.


So X25519 is definitely not going to be enough on its own. We are going to
need a high security curve as well. And that curve has to beat the p-512
curves on performance and implementation robustness and match them on
algorithm security.

So just doing X25519 ends up muddying the waters and missing an
opportunity.


Now when we get to the next stage and deciding which X25519 to implement,
whether this program is intended to provide an algorithm set some of us can
regard as definitive or is just another curve beauty contest makes a big
difference. If we are only doing the latter then pick DJB's parameters and
we are done because what we are doing isn't important enough to be worth
introducing something new.

If we are going for definitive parameters then I would like us to have
exactly two choices: everyday and indisputable. Where the indisputable
curve is the backup curve, curve for long term stored data, etc. And I
would like the two to use different approaches if there is a security
difference and the same approach otherwise (yes I know the curves are
isomorphic but the complexity of the operations isn't necessarily so).





>
> >If we are not doing p=~512 then this is adding one more point to the zoo,
> >no biggie. If we are doing p=~512 and NOT p=~384 then we are sending a
> >signal that we are shutting the zoo down and starting over.
> >
>
> I don't really understand what you are saying here, as none of it is about
> the 128-bit security level which is where your message started from.
>
> Sorry, but I am confused.


If we are only doing a 128 bit security level then we are building a new
attraction for the existing zoo. To pull the zoo down and replace it we
need 128 bit and 256 bit.




>
> >
> >To give an opinion on the plan, I want to know what the backup plan is
> >likely to look like. That does not mean agreeing every detail of the
> >backup plan.
>
> If there's no consensus on doing curves at 192-bit and 256-bit security
> level, then the plan would be to abandon work on such curves until after
> we've delivered recommendations to the TLS WG. The chairs' current
> thinking would be to then come back to this later on. (Of course, at that
> point, people might decide that IETF is not the place to put their
> efforts, and that NIST's activity is the place to be. So be it.)
>

The order of operations that makes sense to me is

0) Decide on the next charter/ order of deliverables now

1) Advise TLS on a 128 bit security level curve for key agreement ASAP

2) Advise TLS on the 256 bit curve

3) Advise on the 128 bit and 256 bit signatures


Reason for doing 2 before 3 is that we are as close to a decision as we
will ever be. Delaying the argument now just means starting it all over
again.

The signatures part is going to be lots of bit twiddlin' details and best
do both curves together so they get done the same way.