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

[Nigel Smart <[e-mail]>]

I think the "hype" around the possible issue re random
number choice in the NIST curves is just scare mongering
etc.

The argument against the NIST curves that they are easy
to poorly implement is also I think slightly a bit of
scare mongering. For Curve25519 you use a non-standard
DH exchange (to some extent), it is not of prime order
(bringing in more issues), cannot be directly used for
standard signatures (modifications do exist), and the code
to use it is not the same as for other curves (thus
creating code bloat, issues for programming error etc).

Thus in my view using Curve25519 would create the same
problems which the proponants are trying to solve.

Saying people can just use NaCl is also a bit of an
issue. I doubt everyone should base there security on
a single library (no matter who wrote it). We have
seen the issue with OpenSSL that just because something
is open source does not mean many eyes have looked at
it. And I suspect more eyes have looked at OpenSSL
than have looked at NaCl (of course the eyes looking
at OpenSSL have probably mainly rolled).

My recommendation would be to stick to
   i) Prime field curves in Weierstrass form with A=-3
  ii) Pick curves with prime order groups (no subgroups)
iii) Pick curves used in other standards so as to aid
      interoperability/code re-use)

Now the NIST curves meet this spec, as will others.

Nigel
-- 
Prof. Nigel P. Smart         | Tel [phone]
Computer Science Department, | Fax [phone]
Woodland Road,               | Email [e-mail]
Bristol, BS8 1UB, UK         | http://www.cs.bris.ac.uk~nigel