Edwards and public key validation

[Billy Brumley]

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