SECP256K1: Implement Verify function for hashes

[MarcoDotIO]

What context is your feature request related to?

When using SECP256K1 Data, it is important that we need a verify function for verifying our signature data. Otherwise the struct is rendered essentially useless for signing data.

What solution would you like?

Implement a function called verifySignature() that takes in a signature data object (or a secp256k1_ecdsa_signature object), a pubKey data object (or a secp256k1_pubkey object), and a data object and outputs a bool whether or not the signature is valid.

Any additional context?

None.

[yaroslavyaroslav]

Hi, @MarcoDotIO thanks for your participation in our project. Just one question, how badly do you want this feature?

[MarcoDotIO]

Hi, @MarcoDotIO thanks for your participation in our project. Just one question, how badly do you want this feature?

Hello,

Thank you for the response. I can go ahead and show an implementation of such a use case from the following code snippet from one of my recent projects I was involved with:

https://github.com/OpenDive/SuiKit/blob/cfe13e6984fdbad2c54286969d5d630d295ff069/Sources/SuiKit/Utils/SECP256k1/SECP256K1PublicKey.swift#L83

I'd also recommend having a sign() function that is able to return a non-recoverable signature:

https://github.com/OpenDive/SuiKit/blob/cfe13e6984fdbad2c54286969d5d630d295ff069/Sources/SuiKit/Utils/SECP256k1/SECP256K1PrivateKey.swift#L144

[yaroslavyaroslav]

Thanks you once again for such detailed feedback, could you elaborate it a bit their use cases on the client side?

It's just, we're now loosely maintaining this lib as it's stable and we're currently lacking of Ethereum foundation grants, so in anyway if the team decides that this feature is necessary it'll be added in our backlog, rather than being taken into work immediately.

[MarcoDotIO]

Thanks you once again for such detailed feedback, could you elaborate it a bit their use cases on the client side?

It's just, we're now loosely maintaining this lib as it's stable and we're currently lacking of Ethereum foundation grants, so in anyway if the team decides that this feature is necessary it'll be added in our backlog, rather than being taken into work immediately.

Hello,

Thank you for reaching out and for your comprehensive feedback.

To address your query on client-side use cases:

1. verifySignature():

   • Security: This is fundamental to ensuring that the data received has not been tampered with, thereby providing users and developers with trust and confidence in the data.
   • Authentication: A common use case is to verify if a given piece of data was indeed signed by the holder of a particular public key. This plays a pivotal role in systems that rely on cryptographic authentication mechanisms.

2. sign() with non-recoverable signature:

   • Privacy: Non-recoverable signatures ensure that the signer's identity (i.e., their private key or any derivative data) cannot be inferred from the signature itself, which is beneficial for systems that prioritize user privacy.
   • Flexibility: It allows developers to choose between recoverable and non-recoverable signatures based on their application needs, which can be particularly important in diverse ecosystems like Ethereum.

I understand the constraints you're working under given the current state of funding. However, considering the fundamental importance of these functions in cryptographic systems, and the increasing emphasis on security and privacy in today's digital world, I believe they would be a valuable addition to the library.

I'm available to provide further insights or assist in any way necessary to expedite the implementation of these features if the team sees fit.

Best regards,
MarcoDotIO

[yaroslavyaroslav]

Sorry for being away for a while, and I really value your efforts to participate with our project.

So, in given circumstances, I believe that the most effective way of your participation would be a PR.

It's not just because this would be the easiest one for us to manage, but because we're actually considering this lib as a true open source project, which is mean that we are expecting that new features would be implemented by the requester themselves or being part of our roadmap, that is as I mentioned before is near to be finished for this given major version branch.

So what I'm trying to say here is not just "provide a PR or get out", it's more like even though I share your concern here, the best we can offer from our side is to review the PR as long as general circumstances would change.