Provide verify variants of the recover functions - Crypto Utilities

[ozgunozerk]

What problem does your feature solve?

Using the recover function instead of verify variant for verifying the signatures may breed vulnerabilities due to signature malleability. For example, secp256k1 curve allows also the negative version (s vs -s) due to the underlying elliptic curve math.

This does not pose a great security threat for our library as of yet (OpenZeppelin Stellar Contracts), but it is definitely a good to have, or maybe even, a must have.

What would you like to see?

If there is a verify variant of the recover function, which follows the canonical format to ensure accepting only s but not -s, it would be more secure.

What alternatives are there?

I don't know...

[leighmcculloch]

Providing both verify and recover were considered when the ecdsa curves were added to soroban, and the reasoning for why only recovery was shipped is below. Text below is extracted from @kwantam's message, emphasis is mine.

...

I'm leery of including both pk-recover and sig-verify. First, it's potentially confusing to users (especially since one takes a message and the other takes a digest as currently defined). Second, if the two host functions ever disagree then at best things are very confusing and at worst it causes a security vulnerability.

I'd just declare that ECDSA signatures over secp256k1 are 65 bytes (32-byte r, 32-byte s, 1-byte rec-id), make pk-recover take 2 args rather than 3, and do away with sig-verify. Even if the risk of disagreement is pretty small, the potential savings from sig-verify doesn't seem likely to amount to much---especially since my guess (which could be way off!) is that most people will be using pk-recover anyhow for compatibility with most of the rest of the ecosystem.

...

Ref: stellar/rs-soroban-env#839 (comment)