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 <bbrum...@gmail.com> >>Sent: 21 February 2021 12:06 >>To: john.hug...@secid.co.uk >>Cc: openssl-users@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
