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, x and y coordinates of the public key. So that, any EVM chain - principally Ethereum rollups - will be able to integrate this precompiled contract easily.
“secp256r1” elliptic curve is a standardized curve by NIST which has the same calculations by different input parameters with “secp256k1” elliptic curve used by the “ecrecover” precompiled contract. The cost of combined attacks and the security conditions are almost the same for both curves. Adding a precompiled contract which is similar to "ecrecover" can provide signature verifications using the “secp256r1” elliptic curve in the smart contracts and multi-faceted benefits can occur. One important factor is that this curve is widely used and supported in many modern devices such as Apple’s Secure Enclave, Webauthn, Android Keychain which proves the user adoption. Additionally, the introduction of this precompiled contract could enable valuable features in the account abstraction which allows more efficient and flexible management of accounts by transaction signs in mobile devices. Most of the modern devices and applications rely on the “secp256r1” elliptic curve. The addition of this precompiled contract enables the verification of device native transaction signing mechanisms. For example:
Modern devices have these signing mechanisms that are designed to be more secure and they are able to sign transaction data, but none of the current wallets are utilizing these signing mechanisms. So, these secure signing methods can be enabled by the proposed precompiled contract to initiate the transactions natively from the devices and also, can be used for the key management. This proposal aims to reach maximum security and convenience for the key management.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
As of FORK_TIMESTAMP in the integrated EVM chain, add precompiled contract P256VERIFY for signature verifications in the “secp256r1” elliptic curve at address PRECOMPILED_ADDRESS in 0x100 (indicates 0x0000000000000000000000000000000000000100).
“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:
The signature verifying algorithm takes the signed message hash, the signature components provided by the “secp256r1” curve algorithm, and the public key derived from the signer private key. The verification can be done with the following steps:
The following requirements MUST be checked by the precompiled contract to verify signature components are valid:
r and s values are in (0, n) (exclusive) where n is the order of the subgroup.(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.The P256VERIFY precompiled contract is proposed with the following input and outputs, which are big-endian values:
Input data: 160 bytes of data including:
hashr component of the signatures component of the signaturex coordinate of the public keyy coordinate of the public keyOutput data:
The use of signature verification cost by P256VERIFY is 3450 gas. Following reasons and calculations are provided in the Rationale and Test Cases sections.
“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.
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.
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.
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 0x100 as P256VERIFY is the first precompiled contract presented as an RIP, and the address is the first available address in the precompiled address set that is reserved for the RIP precompiles.
The gas cost is proposed by comparing the performance of the P256VERIFY and the ECRECOVER precompiled contract which is implemented in the EVM at 0x01 address. It is seen that “secp256r1” signature verification is ~15% slower (elaborated in test cases) than “secp256k1” signature recovery, so 3450 gas is proposed by comparison which causes similar “mgas/op” values in both precompiled contracts.
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.
Functional tests are applied for multiple cases in the reference implementation of P256VERIFY precompiled contract and they succeed. Benchmark tests are also applied for both P256VERIFY and ECRECOVER with some pre-calculated data and signatures in the “go-ethereum”s precompile testing structure to propose a meaningful gas cost for the “secp256r1” signature verifications by the precompiled contract implemented in the reference implementation. The benchmark test results by example data in the assets can be checked:
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.
The changes are not directly affecting the protocol security, it is related with the applications using P256VERIFY for the signature verifications. The “secp256r1” curve has been using in many other protocols and services and there is not any security issues in the past.
Copyright and related rights waived via CC0.