Add EIP: Precompiled for secp256r1 Curve Support

[ulerdogan]

Add EIP: Precompiled for secp256r1 Curve Support

The post is about a new EIP which proposes the addition of a new precompiled contract to the EVM that allows signature verifications in the “secp256r1” elliptic curve by given parameters of message hash, r - s components of the signature, and x - y coordinates of the public key.

[eth-bot]

File EIPS/eip-7212.md

Requires 1 more reviewers from @axic, @g11tech, @gcolvin, @lightclient, @Pandapip1, @SamWilsn

[github-actions]

The commit 1d87d6e (as a parent of ec7ea83) contains errors.
Please inspect the Run Summary for details.

[xinbenlv]

LGTM,

The proposal provided reasonable motivation and clear specs about the input and output and tests to validate, gave gas cost and other spec decision in the rationale. Editorially, I think this PR is good enough to merge as a Draft.

Leaving technical feedback, such as the design choice of verifying only v component, to the peer reviews by the client developers.

[jwasinger]

I left a few comments.

[jwasinger]

IMO it's uneccessary to put system-specific benchmark results in the EIP itself.

[ulerdogan]

Hi, thanks for your comments! How do the benchmarks be displayed? I think that it's important to propose gas costs for the precompiled contract. I thought if I am comparing two results to propose gas cost in the same system would be beneficial. Should I include more systems benchmark results or completely remove it?

[xinbenlv]

IMHO The benchmark is being supplied as assets, I personally think it's a good supporting evidence for rationale like the gas cost choice. Hence I think it's good to be there. My two cents. Others might disagree.

[jwasinger]

It would be nice to clarify exactly what we gain from requiring x/y as inputs. It's not clear to me from the explanation here.

And requiring them as inputs requires substantial added call data.

[dcposch]

If I understand correctly,

• v is a sign bit
• the P256 precompile is intended to support hardware signatures
• most of the existing hardware signature mechanisms (Secure Enclave, Webauthn, etc) return only the (r,s) signature

It's easy to recover v -- you try the two possible values, and see which one returns your public key.

So the comparison is something like

v, r, s style

Pros

• Matches ecrecover.
• Less calldata. On the surface, 1 word = 32 bytes less, but actual savings should be a bit more, since the v parameter is mostly 0 bytes and therefore cheaper.

Cons

• Users / libraries have to recover v. This is a bit awkward. Instead of just calling (hardware signing module), it has to call (hardware signing module) > (attempt verification with + v) > (attempt verification with - v). I am not a cryptographer... maybe there's a better way.

v, r, x, y style

Pros

• Better matches the hardware interface. Users/libraries don't have to recover v, they just pass a pubkey (x,y) directly from the hardware enclave.

[xinbenlv]

FYI ERC-2098 by @ricmoo for might be relevant in the same spirit where user / library recovers v for secp256k1.

This is provided to you as a reference and you can gauge the preference by usage / adoption for designing the precompiles

[ulerdogan]

Thanks @dcposch for the explanation of the logic.

Yes, the mechanisms using the curve are returning only r and s, so the verification is possible with inputting public key coordinates x and y.

We need v value to recover public key without the x and y coordinates. The v value can be found by above-mentioned methods, but let me explain my design choice:

• While we are making recovery with the ecrecover, we can reach the public address of the EOA accounts, so it can be directly used in the smart contracts. Unlikely, recovering the secp256r1 public key does not match any default stored types, and we still need to store the account public key.
• Having to find the v value in the implementation part of the signature creates complexity on the application side. So, I didn't want to bring this complexity for the applications. Still, I would love to reassess and edit the EIP to implement recovery after discussion.

[paulmillr]

-1

1. 256r1 is usually more vulnerable to timing attacks than stuff like 25519.
2. 256r1 is not even recommended by nist at this point, 384r1 is.
3. There are some rumors with regards to general security of r1 curves, it's unclear.
4. Adding a new elliptic curve impl into ALL execution layer clients is not a trivial task. I don't think the feature is too useful for this.

[xinbenlv]

@paulmillr thanks for the feedback.
Editor here: for any technical feedback like those you gave, they are recommended to be put in https://ethereum-magicians.org/t/eip-7212-precompiled-for-secp256r1-curve-support/14789 so when this PR is merged, the discussion can continue and also has a higher chance to be seen by other peer reviewers.

[ulerdogan]

**paulmillr ** commented

Hi, thanks for you comment!

Moved it to the EM forum for discussion: https://ethereum-magicians.org/t/eip-7212-precompiled-for-secp256r1-curve-support/14789/5?u=ulerdogan