Edwards and public key validation

Tue Feb 23 13:45:28 UTC 2021

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 <bbrumley at gmail.com>
>>Sent: 23 February 2021 13:42
>>To: john.hughes at secid.co.uk
>>Cc: openssl-users at 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.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
>>>