Edwards and public key validation

[john.hughes at secid.co.uk]

Thanks Billy for getting back to me.

The bigger picture on this is that I have a very comprehensive test harness for testing PKCS#11 devices.  I already have developed and successfully run tests that test Weierstrass curves.  I have successfully tested many PKCS#11 tokens for their implementation of NIST P-* and Brainpool curves against the 4 tests specified in X9.62 (and now in NIST SP 800-186 (yes the draft one).  I use some of the OpenSSL functions to assist this - especially the BN functionality.

Because my test harness doesn't currently support Edwards curves - and OpenSSL and SoftHSMv2 supports them - I thought it would be useful to add Edward testing functionality into my harness.

I can successfully generate ed25519 keypairs using SoftHSMv2 via the PKCS#11 interface - but now adding in tests to validate the  generated public keys - according to NIST SP 800-186.  

I thought I would look at what OpenSSL does internally - including it tests.  That is where I noticed that the Edwards support is not as rich as the support for "normal" EC curves.

In fact to do the four tests in 800-186 I don’t actually need any more functionality - as the BN functions will (I think) do what I need.   Having, said that I can't get the "public key on the curve" test working as yet given the RFC 8032 test vectors.  Hopefully, I will sort it out soon!


Regards

John

>>-----Original Message-----
>>From: Billy Brumley <bbrumley at gmail.com>
>>Sent: 21 February 2021 12:06
>>To: john.hughes at secid.co.uk
>>Cc: openssl-users at openssl.org
>>Subject: Re: Edwards and public key validation
>>
>>Hey John,
>>
>>> I want to implement a function that validates a public key produced by
>>> either ed25519 or ed448 – according to the tests in NIST SP 800-186
>>> appendix D.1.3
>>>
>>>
>>>
>>> There doesn’t appear to be any helper functions to assist in this – at least for
>>Edwards curves.
>>>
>>>
>>>
>>> I have implemented something for Weierstrass curves – and have used helper
>>functions to obtain the curve/group, domain parameters,
>>EC_POINT_is_at_infinity()  etc etc – but nothing for Edwards.
>>
>>I don't believe you actually have to do that for Weierstrass curves.
>>That is why EVP_PKEY_check and EVP_PKEY_public_check exist, and aren't even
>>legacy EC specific -- thrown any PKEY at them (I cannot say 110% it is doing all
>>the validation you want, but check it in the debugger). You can reach it even
>>from the CLI
>>
>>openssl pkey -in key.pem -check
>>
>><tangent>
>>I will reiterate what I wrote recently on the IETF CFRG mailing list regarding
>>OpenSSL's (EC) API, after which many armchair engineers either replied on the
>>list or directly to me, telling me how wrong I
>>was:
>>
>>BBB: "If you (=application developer) are dealing with points directly in OpenSSL,
>>you are probably already doing it wrong."
>>
>>So your message (at least, about Weierstrass curves) is a good example of what
>>I said -- you've apparently rolled your own key validation, when the library is
>>perfectly capable of doing that for you, off the shelf.
>>
>>(John I am not trying to knock on your or any other well-intentioned developer. I
>>am just saying, with OpenSSL, developers should avoid jumping straight to the
>>lowest level API, and consider first what the high level APIs can/should provide
>>you.) </tangent>
>>
>>For ed25519 and ed448, your message (AFAICT, attaching a debugger to openssl
>>pkey ... -check) indicates those function pointers are not set in the ed25519 and
>>ed449 ameths:
>>
>>https://github.com/openssl/openssl/blob/master/crypto/ec/ecx_meth.c#L726
>>
>>(you can see, they are NULL here.)
>>
>>I am going to guess part of the reason is because FIPS186-5 is only draft status
>>therefore OpenSSL has not mainlined anything, with the possibility the standard
>>will (and should, IMO) shift before being finalized. In that sense when you write
>>"NIST SP 800-186 appendix D.1.3" I think it is very misleading because that is not
>>actually a standard -- only a draft as of this writing.
>>
>><tangent>
>>At least in the context of ed25519 and ed448, the D.1.3 validation doesn't really
>>make any sense. This is generally the problem when NIST tries to backport
>>modern cryptography to legacy standards. With these modern curves, the whole
>>idea is you don't have to validate like that
>>-- at least not the computational aspects of legacy EC key validation.
>></tangent>
>>
>>Having said that, I see no harm in discussing to add support for this kind of
>>validation.
>>
>>Would you please raise an issue on GH?
>>
>>Thanks,
>>
>>BBB