Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p,

Not sure but Weierstrass version of Curve25519 may‎ be a MAY in FIPS 186-4, ANSI X9.62/63, IEEE 1363, SEC1. I can check next week. Because major security properties like hard DLP are preserved between the two versions, those SDOs effectively have no major security concerns with Curve25519 . Only the Suite B and NIST/CSEC FIPS 140-* CAVP might narrow the curve set allowed enough to exclude the Weierstrass equivalent of Curve25519. 

Didn't IETF, maybe PKIX, opt for a MUST on named curves only? That was for interoperability reasons, right? Again, I can check next week.

The reason I'm offering this info now even though I'm not 100% sure, is that I see some arguments here contrasting ANSI and IETF, so I'm advising those arguers to be sure to know what those specs do or have done.

My personal view is that Curve25519 security should be good overall, actually  better than P256 in a few aspects, but slightly worse in others, so not theoretically optimal security. 

Certicom has a variety of‎ IPR, and has made several declarations and letters of assurance to IETF and to other SDOs. My guess is that any IPR that might possibly pertain to Curve25519, has already been declared to IETF, at least to the TLS WG. Certicom is reviewing this, but since Matt Campagna left, we've lagged a little on IPR stuff, sorry.

Best regards, 

-- Dan
From: Watson Ladd
Sent: Saturday, June 28, 2014 7:05 PM
To: tls@ietf.org
Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p,

On Jun 28, 2014 3:55 PM, "Michael StJohns" <msj@nthpermutation.com> wrote:
>
> On 6/28/2014 6:24 PM, Salz, Rich wrote:
>>>
>>> *sigh* If the IETF is really going to get into the business of standardizing
>>> > crypto, we need to get the process for doing so right the first time rather
>>> > than just plugging it in to TLS and hoping we don't have to redo it over and
>>> > over again.
>>
>> Agree.  But again, it's "back into the business"  Because we did it before with TLS1, IPsec, and ECC curves therein.
>
>
> Um... huh?  Can you provide specifics about which cryptographic algorithms  we standardized?  This is news to me.

Camellia, RC4, HMAC. Of course we still screwed up TLS 1.0 by ignoring lessons from IPSEC.

>
> And I'm not talking about "here's how you use ECDSA for TLS or ECDH for  for IPSEC" documents, but something comparable to SP800-56A or FIPS186-4 or X9.63.

What's magical about ANSI? Furthermore,  we aren't developing an algorithm, but documenting one that already exists, the way RFC 6090 claimed to.

There is nothing magical that makes using AES secure. You always have to know what you are doing.

So I don't see picking curve25519 as inherently riskier then decisions we make every day in this WG.
>
> Mike
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p,

Attachment: smime.p7s