On 8/10/2017 12:25 PM, Michael StJohns wrote:
On 8/10/2017 9:44 AM, Adam Petcher wrote:
Does anyone know of a particular use case (that we haven't discuss
already) that would require a provider to support arbitrary curves?
Any other arguments for or against this feature?
There are uses for changing out the base point. PAKE and SPAKE use
similar math (e.g. G^s*sharedSecret is the equivalent of a new base
point).
There are uses for private curves - e.g. when you want to actually be
sure that the curve was randomly generated (sort of the same argument
that got us to Curve25519 in the first place).
There are the whole set of Edwards curves that are mostly not included
in any provider (except possible Microsoft's) as of yet.
Basically, you're trying to argue that there are no better curves (for
the 'new' math) than have already been specified and there never will
be. I think that's a very shortsighted argument.
I expect that new curves will be developed in the future, and the API
should absolutely be designed in such a way that that support for new
curves can be easily added to applications and providers. What I
attempted to argue (I apologize if this was not clear) was that we don't
necessarily need support for arbitrary curve parameters in the initial
API design because:
1) When new, better curves are developed, they will eventually get
names, and then they can be used in exactly the same way as the curves
that exist today.
2) If there is a desire to allow arbitrary curve parameters for
Montgomery/Edwards curves over the API, then we can consider this in the
future as a separate feature. We should ensure that the initial API
design accommodates the addition of this API in the future.
Later, Mike
