Billy You are correct - this is for low level testing of PKCS#11 devices/tokens. Hence just looking at OpenSSL to see if there are any helper functions for Edwards.
There are not. So I have nearly completed development of my own level functions . Now just in the process of testing against some test vectors Regard Johns >>-----Original Message----- >>From: Billy Brumley <bbrum...@gmail.com> >>Sent: 23 February 2021 13:42 >>To: john.hug...@secid.co.uk >>Cc: openssl-users@openssl.org >>Subject: Re: Edwards and public key validation >> >>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 >>>
