Hey John, (Apologies I missed the reply all.)
Your Weierstrass tests are likely redundant with what EVP_PKEY_check etc are doing under the hood. You should also be aware, with Weierstrass curves, it is impossible to get a point that is not on the curve through the OpenSSL API. (As far as I know.) If you really want those Edwards tests, that functionality does not exist yet in the library. Even if you roll your own at the application level with BN functions, I would still suggest opening an issue on GH because the missing function pointers I mentioned are library deficiencies. When those get properly populated, you can eventually throw away any application level code doing validation. (If you are saying, your application exists solely for the purpose of direct low level testing of PKCS11 devices / generating test vectors, and does not pass this PKCS11 functionality through e.g. an OpenSSL engine, then please just ignore me. Although in that case I would kindly suggest OpenSSL might not really be the best tool for you. Unless you are doing some kind of differential testing.) Hope it helps, BBB On Sun, Feb 21, 2021 at 3:40 PM <john.hug...@secid.co.uk> wrote: > > 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 >
