Secp256r1 support

[maurolacy]

Completes the work done in #1877, which is in turn a follow-up of #1083.

• Rebased from main.
• Added test vectors.
• Reorganised the code a bit for generality.
• Added support for secp256r1_recover_pubkey.
• Added secp256r1_verify endpoint / tests to crypto-verify.
• Fixed lints / made CI pass.

[webmaster128]

Very nice, thank you. I did not do a full review yet but will follow up.

Some high level questions:

• Who needs this implementation for what? I was planning to add it to 2.1 to be prepared for passkey apps.
• Don't we need pubkey recovery here?
• I was thinking not requiring low-S signatures in secp256k1 by default was a mistake as all modern blockchain applications require low-S. Right now in CosmWasm you have to check low-S yourself in the contract if your protocol needs it. Maybe it's a good opportunity to make a better decision here. Any thoughts?

[maurolacy]

• Who needs this implementation for what? I was planning to add it to 2.1 to be prepared for passkey apps.

I just saw the pending / partial long standing PR and decided to jump in.

• Don't we need pubkey recovery here?

Will take a look. Seen some comments about lack of recovery for this, but that may be wrong.

• I was thinking not requiring low-S signatures in secp256k1 by default was a mistake as all modern blockchain applications require low-S. Right now in CosmWasm you have to check low-S yourself in the contract if your protocol needs it. Maybe it's a good opportunity to make a better decision here. Any thoughts?

I think there's a normalisation step related to that. Do you want to fail in case of high S?

[webmaster128]

I think there's a normalisation step related to that. Do you want to fail in case of high S?

For non-Ethereum and non-Bitcoin ECDSA, high S is perfectly valid. It's really up to the application to limit it. This is why we accept both in secp256k1_verify. The comments in https://twitter.com/simon_warta/status/1744814900164059555 are also not really convincing me to change it.

Maybe it is better to just create a secp256k1_verify_strict and secp256r1_verify_strict later on.

[maurolacy]

• Don't we need pubkey recovery here?

Will take a look. Seen some comments about lack of recovery for this, but that may be wrong.

Added to the crypto package. Will work in the rest (imports / mappings) later.

[webmaster128]

Nice work, thanks a lot!

Befor the final merge, we should ensure this new API works for Passkeys. I am asking around how to best find test vectors for that.

[webmaster128]

Thank you for this nice work!