Edwards and public key validation

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Edwards and public key validation

john.hughes

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.

 

All I can see is EVCP_PKEY_new_raw_public_key() and EVCP_PKEY_get_raw_public_key() – and that does really help in what I’m trying to do.

 

 

John

 

Reply | Threaded
Open this post in threaded view
|

Re: 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
Reply | Threaded
Open this post in threaded view
|

RE: Edwards and public key validation

john.hughes
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 <[hidden email]>
>>Sent: 21 February 2021 12:06
>>To: [hidden email]
>>Cc: [hidden email]
>>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

Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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 <[hidden email]>
> >>Sent: 21 February 2021 12:06
> >>To: [hidden email]
> >>Cc: [hidden email]
> >>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
>
Reply | Threaded
Open this post in threaded view
|

RE: Edwards and public key validation

john.hughes
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 <[hidden email]>
>>Sent: 23 February 2021 13:42
>>To: [hidden email]
>>Cc: [hidden email]
>>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 <[hidden email]> 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 <[hidden email]>
>>> >>Sent: 21 February 2021 12:06
>>> >>To: [hidden email]
>>> >>Cc: [hidden email]
>>> >>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
>>>