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

[Alyssa Rowan <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 26/06/2014 22:59, Michael StJohns wrote:

> There's been a small but vocal minority agitating for the adoption
> of Curve25519 for use in TLS (and other IETF protocols).

CFRG have selected Curve25519 as the preferred elliptic curve for use
in IETF protocols, as Rich has pointed out.

That is because it is very, very good: it is 8 years old, extremely
fast, and simpler and faster to implement in constant-time, with _far_
fewer special cases, than any Weierstrass-form curve.

> possible IPR issues

"Total number of IPR disclosures found: 0"

As per IETF/IRTF IPR policy, kindly _reference_ any relevant IPR you
are aware of.

To the best of my knowledge, Curve25519 is patent-free: all relevant
patents have expired. No-one has stated anything to the contrary, as
far as I can see, including those at Certicom who are on CFRG (who
would have had to have raised anything relevant, I gather?).

> definite infrastructure issues (e.g. no off the shelf, commercial 
> hardware or software AFAIK),

Please note the extremely liberal license of the very high quality
open-source software implementation in NaCl. It is public domain: you
can take it and use it right now if you want, with zero IPR issues.

Hardware implementations always lag new technologies: ARMv8 only just
got SHA-256, and Intel and AMD don't have anything which specifically
accelerates any crypto except AES.

This is alright, as the software performance of Curve25519 is
extraordinarily good.

It is of course unreasonable to demand implementations exist _before_
specifications. However, adoption has already begun (OpenSSH, Tor,
OpenBSD, Chromium), and perhaps in some places that may surprise you
(the Apple iPhone!).

> documentation issues (not the base curve, but how to incorporate
> curve data into certificates

Curve25519 can be used with signatures, in twisted Edwards form:
please see Ed25519. That has not yet been codified with CFRG or the
PKIX WG, as far as I know, but exists and works very well (OpenBSD
uses it, for example): discussion is still ongoing about details, and
probably needs a refresh/reminder over there.

The use of Curve25519 with ECDHE is covered by the josefsson draft, as
you may remember, back from September 2013:
<https://tools.ietf.org/html/draft-josefsson-tls-curve25519-05>

> [Re: potential trapdoors in NIST curves]

Already very widely discussed, but obviously not relevant to Curve25519.

I know of no backdoors in NIST P256 (secp256r1) or P384 (secp384r1);
but yes, the possibility one exists is alarming, and investigations
into the curve-generation process still leave things remarkably murky.

> how about we just generate new curves:

With blackjack and hookers? :-)

Perhaps the paper at <http://safecurves.cr.yp.to/bada55.html> would be
of interest to you. I would recommend reading it before proceeding any
further with that discussion, especially down to the "Notes on
terminology and security" section.

Brainpool has already generated a set of 'random' primes, but random
primes are extremely slow to implement - and in the case of Brainpool,
the 256-bit curve has extremely unfortunate lack of twist security, so
any implementation that tries to skip validation is in really big trouble.

By adopting Curve25519, we have the opportunity to take advantage of
what we've learned about EC _since_ the engineers at Certicom
generated the NIST curves.

Obviously, I'm part of the 'vocal minority' here, as I'm planning to
use it very soon, because it makes ECDHE both secure and really,
really fast - and that's a huge win for both TLS 1.2 & TLS 1.3!

- -- 
/akr
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJTrRNNAAoJEOyEjtkWi2t6szIP/3/3HjSf7gI/JVNi1MwOW88L
Aw1HirLf3cfCEANlv5GCvWhf8873K82qySgpcqRUhp9DiZrSFiGnUNKjFpcY3tp5
Ph94t6ji0f/x8rBHWGM5FutNqUKf3Hu/Mx4e9AQjRs2jEZwkrKlpKucFJbGjadL7
DEnbDZoAN2veYj93Z0rbG8mqhyVZmapoIGoaR8k0fGO6M0ziLS2X52npHt+z7q56
YzED1ta7DCkjbP0q2Qhi/hBDlOxj+p+MmuOt2NGkRqLqHP3Djr8E16KlFaB90KJW
uOCmZ/jYU2kS86FxXPHzpdkGeOgQgN6b9noARLbv1GkydSuRvZst9t5BTiYVPd8G
PQSTmLiMpvXh8iZ7CKXEb7SRPbqAWkTrIaSkFWJ3HThVotor0wU//x6ARozsGUI1
vtmjTIOaQlGpv0ZYWaYosUY3DE9t+OTcFoBxsknmiiDLDQg/CzknWiELQSf4IVXH
b01+uzGnZv2INk1AMW+0M4AEZlKVRQnpDM/yhHWII0iAQqFEcA3CcBUw6GCjpaMv
xqymfirQsfDjT1vkkEjN5L4grHYLIqPLkydOYucPlXwFD+q2cRoq4kh1ZKZUWMVu
r3Bv68jXcQzNXUz0EsgKKj1ao/KEXlFi1iT3ub1vh6kQrkqpQyh2Few6Fpq/RDPs
awVbNQgAz+44Rb7/vvGX
=CjJs
-----END PGP SIGNATURE-----