Update EIP-7212: Clarifications and improvements

Merged by EIP-Bot.

EIPS/eip-7212.md

@@ -1,8 +1,8 @@
 ---
 eip: 7212
 title: Precompiled for secp256r1 Curve Support
-description: Proposal to add precompiled contract that allows signature verifications in the “secp256r1” elliptic curve.
-author: Ulaş Erdoğan (@ulerdogan), Doğan Alpaslan (@doganalpaslan)
+description: Proposal to add precompiled contract that performs signature verifications in the “secp256r1” elliptic curve.
+author: Ulaş Erdoğan (@ulerdogan), Doğan Alpaslan (@doganalpaslan), DC Posch (@dcposch), Nalin Bhardwaj (@nalinbhardwaj)
 discussions-to: https://ethereum-magicians.org/t/eip-7212-precompiled-for-secp256r1-curve-support/14789
 status: Review
 type: Standards Track
@@ -12,7 +12,7 @@ created: 2023-06-22
 
 ## Abstract
 
-This proposal creates a precompiled contract 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. So that, any EVM chain -principally Ethereum rollups- will be able to integrate this precompiled contract easily.
+This proposal creates a precompiled contract that performs signature verifications in the “secp256r1” elliptic curve by given parameters of message hash, `r` and `s` components of the signature, and `x`, `y` coordinates of the public key. So that, any EVM chain - principally Ethereum rollups - will be able to integrate this precompiled contract easily.
 
 ## Motivation
 
@@ -35,23 +35,23 @@ As of `FORK_TIMESTAMP` in the integrated EVM chain, add precompiled contract `P2
 “secp256r1” is a specific elliptic curve, also known as “P-256” and “prime256v1” curves. The curve is defined with the following equation and domain parameters:
 
 ```
-# curve:
+# curve: short weierstrass form
 y^2 ≡ x^3 + ax + b
 
-# p: specifies reduced elliptic group
+# p: curve prime field modulus
 0xffffffff00000001000000000000000000000000ffffffffffffffffffffffff
 
-# a: elliptic curve coefficient
+# a: elliptic curve short weierstrass first coefficient
 0xffffffff00000001000000000000000000000000fffffffffffffffffffffffc
 
-# b: elliptic curve coefficient
+# b: elliptic curve short weierstrass second coefficient
 0x5ac635d8aa3a93e7b3ebbd55769886bc651d06b0cc53b0f63bce3c3e27d2604b
 
 # G: base point of the subgroup
 (0x6b17d1f2e12c4247f8bce6e563a440f277037d812deb33a0f4a13945d898c296,
  0x4fe342e2fe1a7f9b8ee7eb4a7c0f9e162bce33576b315ececbb6406837bf51f5)
 
-# n: order of the subgroup
+# n: subgroup order (number of points)
 0xffffffff00000000ffffffffffffffffbce6faada7179e84f3b9cac2fc632551
 
 # h: cofactor of the subgroup
@@ -68,7 +68,7 @@ The signature verifying algorithm takes the signed message hash, the signature c
 # pubKey = (public key of the signer private key)
 
 # Calculate the modular inverse of the signature proof:
-s1 = s^(−1)(modn)
+s1 = s^(−1) (mod n)
 
 # Recover the random point used during the signing:
 R' = (h * s1) * G + (r * s1) * pubKey
@@ -81,13 +81,12 @@ r' == r
 
 ```
 
-### Required Checks in the Verification
+### Required Checks in Verification
 
-Some requirements have to be checked to understand if the given signature components are valid:
+The following requirements **must** be checked by the precompile to verify signature components are valid:
 
-- Verify that both `r` - `s` values are greater than 0 and less than the curve order.
-- Verify that s is equal to or less than half of the order of the subgroup to prevent signature malleability.
-- Verify that the point formed by (`x`, `y`) values is on the curve and both components are in between 0 and the `p` value of the curve.
+- Verify that the `r` and `s` values are in `(0, n)` (exclusive) where `n` is the order of the subgroup.
+- Verify that the point formed by `(x, y)` is on the curve and that both `x` and `y` are in `[0, p)` (inclusive 0, exclusive p) where `p` is the prime field modulus. Note that many implementations use `(0, 0)` as the reference point at infinity, which is not on the curve and should therefore be rejected.
 
 ### Precompiled Contract Specification
 
@@ -108,17 +107,23 @@ The use of signature verification cost by `P256VERIFY` is `3450` gas. Following
 
 ## Rationale
 
-The "secp256r1" elliptic curve signatures consists of `v`, `r`, `s` components. Even if recovering the public key on the curve is possible, most of the applications are not generating `v` component of the signature and it causes an uncertainty of the result values. However, the signatures can be verified with only `r` - `s` values. In order to provide an exact and more compatible method, verification is preferred over recovery to propose in a precompiled.
+“secp256r1” ECDSA signatures consist of `v`, `r`, and `s` components. While the `v` value makes it possible to recover the public key of the signer, most signers do not generate the `v` component of the signature since `r` and `s` are sufficient for verification. In order to provide an exact and more compatible implementation, verification is preferred over recovery for the precompile.
 
-The signature values in `r` - `s` and the public key coordinates in the `x`- `y` provides direct computations in signing and verification part, so these formats are chose in the input data format which are 32 bytes.
+Existing P256 implementations verify `(x, y, r, s)` directly. We've chosen to match this style here, encoding each argument for the EVM as a `uint256`.
 
-The `PRECOMPILED_ADDRESS` is chosed in `0x19` as it is the next available address in the precompiled address set.
+This is different from the `ecrecover` precompiled address specification. The advantage is that it 1. follows the NIST specification (as defined in NIST FIPS 186-5 Digital Signature Standard (DSS)), 2. matches the rest of the (large) P256 ecosystem, and most importantly 3. allows execution clients to use existing well-vetted verifier implementations and test vectors.
 
-The gas cost has proposed by comparing the performances of the `P256VERIFY` and the `ECRECOVER` which is implemented in the EVM at `0x01` address. It is seen that “secp256r1” signature verification by `P256VERIFY` is ~15% slower (elaborated in the [test cases](#test-cases) part) than “secp256k1” signature recovery by `ECRECOVER`, so `3450` gas is proposed by comparison which causes similar “mgas/op” values in both precompiles.
+Another important difference is that the NIST FIPS 186-5 specification does not include a malleability check. We've matched that here in order to maximize compatibility with the large existing NIST P-256 ecosystem.
+
+Wrapper libraries **should** add a malleability check by default, with functions wrapping the raw precompile call (exact NIST FIPS 186-5 spec, without malleability check) clearly identified. For example, `P256.verifySignature` and `P256.verifySignatureWithoutMalleabilityCheck`. Adding the malleability check is straightforward and costs minimal gas.
+
+The `PRECOMPILED_ADDRESS` is chosen as `0x19` as it is the next available address in the precompiled address set.
+
+The gas cost is proposed by comparing the performance of the `P256VERIFY` and the `ECRECOVER` precompile which is implemented in the EVM at `0x01` address. It is seen that “secp256r1” signature verification is ~15% slower (elaborated in [test cases](#test-cases)) than “secp256k1” signature recovery, so `3450` gas is proposed by comparison which causes similar “mgas/op” values in both precompiles.
 
 ## Backwards Compatibility
 
-No backward compatibility issues found as the precompiled contract will be added to `PRECOMPILED_ADDRESS`, one of the next address in the precompiled address set.
+No backward compatibility issues found as the precompiled contract will be added to `PRECOMPILED_ADDRESS` at the next available address in the precompiled address set.
 
 ## Test Cases
 
@@ -169,7 +174,7 @@ geomean                                               33.00        7.000
 
 ## Reference Implementation
 
-Implementation of the `P256VERIFY` precompiled contract is applied to go-ethereum client to create a reference. Also, an “secp256r1” package has already been included in the Besu Native library which is used by Besu client. Other client implementations are in the future roadmap.
+Implementation of the `P256VERIFY` precompiled contract is applied to go-ethereum client to create a reference. Also, a “secp256r1” package has already been included in the Besu Native library which is used by Besu client. Other client implementations are in the future roadmap.
 
 ## Security Considerations