-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add secp256r1
curve host fns
#807
Comments
Related to #684 so we may add them together. |
Moved to Post Soroban V1. |
secp256r1 could enable passkey wallets without requiring signature transmutation |
EIP-7212 adds motivation. Including these examples:
|
For the benefit of anyone else who didn't immediately recognize this curve, in most APIs and documentation it is referred to as P256, or P-256, or NIST P-256, or Ecdsa P-256, and to a lesser frequency prime256v1. In the Webauthn specification it is referred to as It's one of the curves we discussed adding support to Stellar signers in CAP-43. The same benefits and motivations detailed in that proposal would also apply here. The big one being support by hardware security modules. |
I think supporting just I found some reports of some Windows machines only supporting RSA, and technically the Webauthn spec encourages at least supporting the following three schemes/algos:
Ref: https://w3c.github.io/webauthn/#dom-publickeycredentialcreationoptions-pubkeycredparams Where:
However, from best I can tell Ed25519 is not commonly supported, and a test we did confirmed ES256 is available on Windows in browners. Also, supporting RSA would be challenging from a cost perspective as the keys and signatures are large. Keys and signatures would be 256-512 bytes. We could support a limited set of passkeys that already support Ed25519 today, such as some Yubikeys. |
secp256r1 should be prioritized to support mobile wallets on Soroban. It makes account recovery UX of managed non-custodial wallets significantly easier than it is today. |
We should do a quick survey of all libraries out there (other than p256) and do some due diligence before picking one. |
### What Resolves #807 by adding a new host function `verify_sig_ecdsa_secp256r1` for ECDSA signature verification using secp256r1 curve. The function accepts following inputs: - `public_key: BytesObject` containing the 65-byte SEC-1 uncompressed ECDSA public key - `msg_digest: BytesObject` a 32-byte hash of the message - `signature`: the 64-byte signature `(r, s)` serialized as fixed-width big endian scalars The function is gated behind protocol 21 (`min_supported_protocol = 21`). PR with the associated XDR changes: stellar/stellar-xdr#178, stellar/rs-stellar-xdr#355 #### Metering and Calibration Two new cost types have been newly added: - `Sec1DecodePointUncompressed`: constant cost type representing the cost to decode the `public_key` - `VerifyEcdsaSecp256r1Sig` : constant cost type represent the cost of ECDSA sig verification A prevous cost type `ComputeEcdsaSecp256k1Sig` has been renamed to `DecodeEcdsaCurve256Sig`, which represents the cost of deserializing both the `secp256k1` and `secp256r1` signatures. Calibration: - each new cost type mentioned above have been benchmarked and calibrated. - plus a few experimental types have been added to answer key questions regarding the host interface (will provide a supplemental doc soon). #### Testing Unit tests have been added to test against various forms of invalid inputs. In addition, two set of test vectors has been added in integration test: - [NIST test vectors](https://csrc.nist.gov/groups/STM/cavp/documents/dss/186-3ecdsatestvectors.zip) - Google's [wycheproof](https://github.com/C2SP/wycheproof) test vectors
secp256r1
seems to be a reasonably popular curve, so it would be nice to add host-side support for it.The text was updated successfully, but these errors were encountered: