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

[Andrey Jivsov <[e-mail]>]

Here is an idealistic, but not unfeasible proposal that could lead to 
easier/broader adoption.

One way to attempt to unify the diverse world of ECC curves is to focus 
on the underlying field, as opposed the curve itself. Consider Fp 
operations with p=2^255-19 or p=2^256-189. In other words, for 
n={256,384,512}, chose the closest C: p=2^n-C is a prime and make this p 
"MUST". People who demand random primes will have to play along and 
accept less "randomness" in their curves.

This makes it more likely that the standard bodies, including national 
standards, agree to commit to a unified Fp, even when they are unable to 
embrace a single curve. This is a more realistic goal than to expect 
that one curve will satisfy everybody.

The performance in the Fp dominates the higher-level operation in ECC 
field. In software, Fp operations will be special-cased for p and 
various CPU architectures. It seems to me that such a fixed Fp will work 
as an incentive to add hardware support (for Fp). This allows the ECC 
code to have an interoperable, potentially hardware-assited layer, that 
is shared between all the curves (for the same n).


While we are on this, why was the Curve25519 not made to be Curve256189? 
(I don't think that 19 v.s. 189 would matter on x86) I suppose that the 
rest of the paper carries over unchanged (other than that the choice of 
the floating point registers is dated by now for modern x86 CPUs.)

Thank you.