NEP-635: P256 host function

[bowenwang1996]

Proposal to add ECDSA P256 signature verification as a host function in the runtime. Implementation in near/nearcore#14927

[mitinarseny]

Hey @bowenwang1996, thank you for this proposal!

We (Near Intents team) are super-excited to have it on mainnet soon, as it would drastically reduce gas costs of verifying p256 signatures in WASM, while leaving more gas for other operations.

I left a couple of comments, would appreciate your feedback.

[mitinarseny]

AFAIK, all ECDCA signatures MUST be calculated over a digest of cryptographic hash function, while it's up to signing standard which hash function to use: e.g. webauthn uses SHA-256. Do you think it's worth to mention it here?

[mitinarseny]

As far as I checked: the value will be truncated or padded with zeros inside of <VerifyingKey<C> as PrehashVerifier<Signature<C>>>::verify_prehash if the length is not equal to <C as Curve>::FieldBytesSize, which is 32 bytes for NistP256

[gagdiez]

Thank you @bowenwang1996 for submitting this NEP. I would now request @near/wg-protocol to assign two reviewers

т(see expectations below).

Just for clarity, Technical Reviewers play a crucial role in scaling the NEAR ecosystem as they provide their in-depth expertise in the niche topic while work group members can stay on guard of the NEAR ecosystem. The discussions may get too deep and it would be inefficient for each WG member to dive into every single comment, so NEAR Developer Governance designed this process that includes subject matter experts helping us to scale by writing a summary with the raised concerns and how they were addressed.

Technical Review Guidelines

• First, review the proposal within one week. If you have any suggestions that could be fixed, leave them as comments to the author. It may take a couple of iterations to resolve any open comments.
• Second, once all the suggestions are addressed, produce a Technical Summary, which helps the working group members make a weighted decision faster. Without the summary, the working group will have to read the whole discussion and potentially miss some details.
  Technical Summary guidelines:
• A recommendation for the working group if the NEP is ready for voting (it could be approving or rejecting recommendation). Please note that this is the reviewer's personal recommendation.
• A summary of benefits that surfaced in previous discussions. This should include a concise list of all the benefits that others raised, not just the ones that the reviewer personally agrees with.
• A summary of concerns or blockers, along with their current status and resolution. Again, this should reflect the collective view of all commenters, not just the reviewer's perspective.

Here is a nice example and a template for your convenience:

### Recommendation
Add recommendation
### Benefits
* Benefit
* Benefit
### Concerns
| # | Concern | Resolution | Status |
| - | - | - | - |
| 1 | Concern | Resolution | Status |
| 2 | Concern | Resolution | Status |

Please tag the @near/nep-moderators once you are done, so we can move this NEP to the voting stage. Thanks again.

[IkerAlus]

For the reviewer of this NEP, I think it would be nice to mention that this crate was audited recently: https://reports.zksecurity.xyz/reports/near-p256/

Particularly since the maintainers of this crate still claim this crate has never been independently audited: https://github.com/RustCrypto/elliptic-curves/tree/master/p256#%EF%B8%8F-security-warning

even though they have added the suggested changes from the audit: RustCrypto/elliptic-curves#1155

[gagdiez]

I feel this would also be relevant for future readers, I will go ahead and add a small comment on the NEP itself

[gagdiez]

@near/wg-protocol sorry to ping again, still waiting on two SME reviewers (cc @walnut-the-cat)

[birchmd]

@gagdiez we had a discussion about this NEP at our monthly Protocol Working Group review call. We decided that it is ok to skip the separate SME review for this proposal and move straight to voting. This because it is using a commonly used and well-specified signature algorithm while also making use of a library that has been audited. Essentially, we fell the SME review has implicitly already taken place in the form of the popularity of this algorithm (e.g. in passkeys) and in the audit of the crate.

To that end, as my role as a WG member, I vote to approve this proposal. My only minor comment is that we should accept @mitinarseny 's comments about making clear the msg passed to the verify function should come from some cryptographically secure hash function (the exact one chosen is dependent on the signature scheme), and enforcing input lengths at the SDK level.

[gagdiez]

@birchmd completely understandable, I think it would still be quite nice if we could get another member from the @near/wg-protocol to state their vote, as @bowenwang1996 is already the one proposing the NEP maybe @mfornet could give their thumbs up?

[graphite]

Giving my thumbs up here as well. I incorporated the suggestions from @mitinarseny and @r-near as @birchmd suggested. I believe in the current state this NEP should be accepted.

[gagdiez]

Both @birchmd [1] and @graphite [2] who are members of the @near/wg-protocol gave their approval, which means we have reached enough quorum for it to be accepted as a Protocol NEP

For anyone reading this in the future, we did skip the protocol meeting to vote, as this NEP proposes to add a well-known cryptographical operation using audited crates, which means that it has been implicitly reviewed by multiple subject matter experts

• [1] NEP-635: P256 host function #635 (review)
• [2] NEP-635: P256 host function #635 (comment)