Edwards and public key validation

[Billy Brumley]

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.hughes at 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 <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
>