Road to secp256r1 support

[webmaster128]

It has become clear that we want ECDSA secp256r1 signature verification support to allow app level signature verification using a popular industry standard curve. Now that if is answered, let' move on to when and how. Given that adding a new crypto API is something we cannot easily revert once contracts rely on it, we need to ensure that the new API is correct and behaves as desired.

Open Questions

• Should we accept low-S and high-S signatures? Yes, because this is how ECDSA works and secp256k1_verify behaves today. An app level protocol may further restrict which sigantures are valid. Those extra checks have to be implemented separately, for now in Wasm.
• Should we implement secp256r1_recover_pubkey? Why not, we have it for the other curve already
• Do we need a DER decoder for signatures (decoding DER in a way that does not allow malleability is pretty hard)?: I'd say no, since this is not trivial and needed for BTC only

Blockers

• Seal trait cosmwasm_std::Api? #2004 because we need to be able to add functions in a point release
• Release CosmWasm 2.0 (secp256r1 should not block 2.0 and we don't want to rush secp256r1)
• Merge secp256k1 test from Project Wycheproof (Add secp256k1_verify/secp256k1_recover_pubkey tests from Project Wycheproof #2000)
• Finalize the secp256r1 implementation (Secp256r1 support #1983)
• Add secp256r1 tests from Project Wycheproof (Add test vectors from Project Wycheproof for secp256r1 #2007)
• Use prehash directly and remove Identity256 (Use prehash directly and remove Identity256 #2012)
• Get clarity on supported recover IDs (Allow recover ID 2 and 3 for secp256r1_recover_pubkey #2057)
• Add default implementations to trait Api using unimplemented!() (Add default implementations for secp256r1_verify/secp256r1_recover_pubkey #2058)
• Add cosmwasm_2_1 feature (Run cosmwasm-check in CI and add cosmwasm_2_1 feature #2065)
• Ensure API is good to verify WebAuthn/FIDO for passkey support (Add Webauthn example using the secp256r1 API #2071)

[aumetra]

The API seems fine. Checking through webauthn-rs, the API is operating on prehashed data, so we don't even assume a message digest. As for the key, that requires a bit more conversion juggling. The EC key has to be converted from its COSE format into SEC1.

This involves:

• Parsing the CBOR and COSE
• Parsing the scalars out of the COSE
• Constructing a non-zero scalar
• Converting it into an p256 secret key
• Encoding it into SEC1
• Passing it to the API

But we can't cover that, really. Unless we want an API that accepts raw scalars (that'd be a big no from me) or implement COSE ourselves (is it worth it? Contracts can do that themselves.)
Otherwise the raw cryptography primitives seem totally usable.

[aumetra]

But then again, I haven't implemented WebAuthn/FIDO myself yet, so I'm not 100% sure.

[webmaster128]

That sounds interesting. Can we try to implement all those conversions in an example contract? That way we can show contract developers what needs to be done without having to expose that functionality as part of our APIs.

Converting it into an p256 secret key

Public key, right? On chain we only do signature verification.

[aumetra]

Public key, right? On chain we only do signature verification.

Ah, yes, public key. Not private key. Mixed them up in my head for a sec

[aumetra]

Seems like the last checklist item is done now. Can we mark this as done? 🎉