JCA design for RFC 7748
Adam Petcher
adam.petcher at oracle.com
Fri Aug 11 19:17:08 UTC 2017
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
>
>
More information about the security-dev
mailing list