Testing Edwards curves

[johughes99]

I'm just adding in some tests for Edwards curves in my testing tool. Just want to raise a few points (which did get me confused for a while).

• When generating a keypair for Edwards curves you must specify the CKK_EC_EDWARDS key type in the public and private key templates. Unfortunately the latest version of the 3.0 PKCS#11 current mechanism spec specifies that you should use CKK_EC.

• I generated a edwards25519 curve key pair successfully - but only using the OID specified in RFC8410. However, the method of using a printable string (as shown in the PKCS#11 current mechanism example) causes a CKR_GENERAL_ERROR. Not sure whether the printable string CHOICE is not supported at all in SoftHSMv2. If it is then the curveName "edwards25519" is not supported.

• CK_MECHANISM_INFO reports a min key size of 256 and 456 (256 = curve 25519 and 456 = curve 448). However, this does not match the values of 255 and 448 specified in section 2.3.10 of the 3.0 PKCS#11 current mechanisms. RFC 8072 says the private key sizes should be 32 and 57 bytes respectively - which matches what SoftHSMv2 reports. So is the PKCS#11 spec is wrong?

[johughes99]

As an update - I also tried the printable strings id-Ed25519 and id-Ed448. This also gave CKR_GENERAL_ERROR. Hence, my assumption is that SoftHSM does not support the curveName option in CKA_EC_PARAMS.

[rijswijk]

SoftHSM requires the DER encoding of the printableString as per the latest PKCS #11 3.0 spec, this change was merged with #526. Regarding the mechanism info: once #522 is merged that should also be resolved.

[johughes99]

That's what i was doing, for example:

CK_BYTE X25519_NAME[] = {0x13, 0x09, 0x69, 0x64, 0x2D, 0x58, 0x32, 0x35, 0x35, 0x31, 0x39};

[rijswijk]

That OID is not the one from the PKCS #11 spec, you should probably have a look at the EDDSA test cases in the SoftHSM source code (which has the OIDs), e.g.: here

[johughes99]

0x13, 0x09, 0x69, 0x64, 0x2D, 0x58, 0x32, 0x35, 0x35, 0x31, 0x39 is the ASN.1 printable string of "id-X25519" - as taken from RFC8410 - not an OID

The PKCS#11 spec in 2.3.5 example gives the ASN.1 printable string as curve25519 - which isnt one of the value curve names in RFC8410 (or I believe in 8032). Let me check the test code....

[rijswijk]

Yes, sorry, not OID, but the printableString values in the code are curve25519 and edwards25519, and those were taken from the PKCS #11 3.0 spec AFAICS

[johughes99]

Yes - I just looked. I think they very confusing thing in the latest PKCS#11 specs is that they are not very explicit on what they are pulling in from RFC8032 and RFC8410. They do seem to be using RFC8410 in terms of the 4 OIDS - but not clear on what they are pulling in from RFC8032 - other that the algorithm definitions. For instance, in RFC 8032 they refer to it as Curve25519 (ie capitalized "C"). However, they do seem to be more precise in the definitions of edwards25519 and edward448. So should we use the last two - and not curve25519?

[johughes99]

Looking at PKCS#11 specs again -they do seem to be defined - :-)

Let me check through all this again - and retest

[johughes99]

All fine. Using the curve names edwards25519 and edwards448 works just fine.

What about support for the Montgomery curves? On testing these with either the OIDs or the curve names curve25519 and curve448 I get the error CKR_MECHANISM_INVALID.

Is the CKM_EC_MONTGOMERY_KEY_PAIR_GEN mechanism not supported yet - even though the tests seem to include support for them?

[rijswijk]

The mechanism is indeed not supported, and there are currently also no plans to support it. Can you indicate why you need it?

[johughes99]

No I don't need it. Its just an observation.