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

Michael StJohns mstjohns at comcast.net
Fri Aug 4 19:33:13 UTC 2017


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





More information about the security-dev mailing list