PKCS #11 TC looks into OKP versus EC for CFRG support

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

PKCS #11 TC looks into OKP versus EC for CFRG support

Anders Rundgren
https://lists.oasis-open.org/archives/pkcs11/201708/msg00006.html

C'mon (Oracle) Guys, what's *your* plan; is JDK open source or not? :-)
Yeah, I know that open source <> open ideas but the world needs a direction.

Feel completely free dismissing OKP, it is the silence that's killing us.

Cheers,
Anders
https://github.com/cyberphone/java-cfrg-spec

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PKCS #11 TC looks into OKP versus EC for CFRG support

Michael StJohns
On 8/4/2017 3:05 PM, Anders Rundgren wrote:

> https://lists.oasis-open.org/archives/pkcs11/201708/msg00006.html
>
> C'mon (Oracle) Guys, what's *your* plan; is JDK open source or not? :-)
> Yeah, I know that open source <> open ideas but the world needs a
> direction.
>
> Feel completely free dismissing OKP, it is the silence that's killing us.
>
> Cheers,
> Anders
> https://github.com/cyberphone/java-cfrg-spec
>

Anders asked me to take a look at this a while back and I haven't
actually had much time.  However, I think the approach he's crafted for
OKP is probably wrong for Java.

What I think I would do instead is create
java.security.spec.ECFieldMontgomery and
java.security.spec.ECFieldEdwards.   I'd place the indication of whether
the curves are for Signature or Key Agreement at the field level - maybe
as a sub interface or marker interface.

  For the ECPoint data I'd leave Y as a NULL - Y does exists and can be
calculated, but all of these appear to use a compressed encoding.   I'd
encode the public and private data as BigIntegers - this would mean
converting from little endian to big endian and back again when doing
the PKCS8 encoding stuff, but a lot easier than adding a whole new class
of top level interfaces.

As far as I can tell, it should be possible to represent the four curves
using the current API (minus the field info) and I'd suggest doing
exactly that.  Tagging the ECField differently will isolate the changes
without breaking previous implementations.   I think this is then also
extensible as other curves come along.

My thoughts - Mike


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PKCS #11 TC looks into OKP versus EC for CFRG support

Anders Rundgren
On 2017-08-04 21:33, Michael StJohns wrote:

> On 8/4/2017 3:05 PM, Anders Rundgren wrote:
>> https://lists.oasis-open.org/archives/pkcs11/201708/msg00006.html
>>
>> C'mon (Oracle) Guys, what's *your* plan; is JDK open source or not? :-)
>> Yeah, I know that open source <> open ideas but the world needs a
>> direction.
>>
>> Feel completely free dismissing OKP, it is the silence that's killing us.
>>
>> Cheers,
>> Anders
>> https://github.com/cyberphone/java-cfrg-spec
>>
>
> Anders asked me to take a look at this a while back and I haven't
> actually had much time.  However, I think the approach he's crafted for
> OKP is probably wrong for Java.

"Wrong" is hardly the right word here; the proposals simply have quite different objectives.

I (FWIW) didn't give internal operations and structures much considerations; the emphasis was on clarity and conformance with other related specs.

Your proposal focuses on reuse by finding similar patterns which of course isn't "wrong" either.

In terms of code size I believe the difference will turn out to be insignificant but that's of course at this stage just a guess.

However, documentation- and support-wise OKP has a clear advantage.  Maybe Oracle should start there and see where it leads...

Anders

>
> What I think I would do instead is create
> java.security.spec.ECFieldMontgomery and
> java.security.spec.ECFieldEdwards.   I'd place the indication of whether
> the curves are for Signature or Key Agreement at the field level - maybe
> as a sub interface or marker interface.
>
>    For the ECPoint data I'd leave Y as a NULL - Y does exists and can be
> calculated, but all of these appear to use a compressed encoding.   I'd
> encode the public and private data as BigIntegers - this would mean
> converting from little endian to big endian and back again when doing
> the PKCS8 encoding stuff, but a lot easier than adding a whole new class
> of top level interfaces.
>
> As far as I can tell, it should be possible to represent the four curves
> using the current API (minus the field info) and I'd suggest doing
> exactly that.  Tagging the ECField differently will isolate the changes
> without breaking previous implementations.   I think this is then also
> extensible as other curves come along.
>
> My thoughts - Mike
>
>

Loading...