Re: [Cfrg] Task looming over the CFRG

[Watson Ladd <[e-mail]>]

On Mon, May 5, 2014 at 10:58 AM, Igoe, Kevin M. <[e-mail]> wrote:
> As most the folks who read this list have noticed, a virtual interim meeting
> of the CFRG
> was held on Tues 29 April to discuss the way forward for elliptic curve
> cryptography
> in the IETF.  This was driven by an earnest plea from the TLS WG for firm
> guidance from
> the CGRG on the selection of elliptic curves for use in TLS.  They need an
> answer before
> the Toronto IETF meeting in late July.  TLS needs curves for several levels
> of security (128,
> 192 and 256), suitable for use in both key agreement and in digital
> signatures.

Digital signatures is a bit hairy because of the issue of certs: you
end up needing to support more curves than you would think you would
going in. But yes, we should discuss adopting more Schnorr-like
mechanisms then ECDSA: the patents that forced ECDSA to look the way
it did are long gone. However, that's not what the current TLS draft
is about: it's purely addressing key exchange. Certificate changes
will be a bit more work.

>
>
> The consensus of the attendees was that it would be best for TLS to have a
> single
> “mandatory to implement” curve for each of the three security levels.
>
>
>
> Though the attendees were reluctant to make a formal commitment, there
> was clearly a great deal of support for the Montgomery curve curve25519
> (FYI, the
> 25519 refers to the fact that arithmetic is done modulo the prime 2**255 –
> 19 ).
>
>
>
> curve25519 only fills one of the three required security levels.  We still
> need
> curves of size near 384 bits and 512 bits.

My suggestion: we look at the safecurves website and find curves.
Right now Curve41417 and Ed448 are both contenders for the 384 size:
it will come down to efficiency, which requires some coding to be
done. I understand both have implementations, and it comes down to who
can optimize the best.

For the 512 size M-511 looks good to me. Maybe some prime shapes are
more optimized, etc, but 2^384 is in a dry spot for primes: the best I
got was 2^384-317, which is a large enough epsilon to cause problems
on small radix machines.

>
>
>
> NIST curves: I doubt TLS will be willing to revisit the question of elliptic
> curves once the
> CFRG has made their recommendation.  Another option to consider is advising
> TLS to
> use of the NIST curves in the short term, buying time for the CFRG to do an
> unrushed
> exploration of the alternatives, drawing academia and other standards bodies
> into the
> discussion.

How much more time do we need? We can hold meetings ad nauseam, but I
don't think our alternatives will change that much, or the various
factors causing us to lean one way or the other. Put it another way:
do you foresee any information in the next 12 months that would change
the status of Curve25519? If not, why not make the decision now, or at
least plan to end Toronto with the decision made?

Sincerely,
Watson Ladd
>
>
> P.S.  It has been suggested that the CFRG hold a session at the Crypto
> conference in
> Santa Barbara in an effort to draw in more participation from the academic
> community.
> No guarantees we can pull this off, but it is worth the attempt. Thoughts?
> Volunteers?
>
> P.P.S. We need to start lining up speakers for the CFRG session at IETF-90
> (Toronto).
>
>
> ----------------+--------------------------------------------------
> Kevin M. Igoe   | "We can't solve problems by using the same kind
> [e-mail]  | of thinking we used when we created them."
>                 |              - Albert Einstein -
> ----------------+--------------------------------------------------
>
>
>
>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> http://www.irtf.org/mailman/listinfo/cfrg
>



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin