Proposal to add precompiled contract that allows signature verifications in the “secp256r1” elliptic curve.
|Authors||Ulaş Erdoğan (@ulerdogan), Doğan Alpaslan (@doganalpaslan)|
Table of Contents
- Backwards Compatibility
- Test Cases
- Reference Implementation
- Security Considerations
This proposal creates a precompiled contract that allows signature verifications in the “secp256r1” elliptic curve by given parameters of message hash,
s components of the signature, 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 precompile 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:
- Apple’s Secure Enclave: There is a separate “Trusted Execution Environment” in Apple hardware which can sign arbitrary messages and can only be accessed by biometric identification.
- Webauthn: Web Authentication (WebAuthn) is a web standard published by the World Wide Web Consortium (W3C). WebAuthn aims to standardize an interface for authenticating users to web-based applications and services using public-key cryptography. It is being used by almost all of the modern web browsers.
- Android Keystore: Android Keystore is an API that manages the private keys and signing methods. The private keys are not processed while using Keystore as the applications’ signing method. Also, it can be done in the “Trusted Execution Environment” in the microchip.
- Passkeys: Passkeys is utilizing FIDO Alliance and W3C standards. It replaces passwords with cryptographic key-pairs which is also can be used for the elliptic curve cryptography.
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.
FORK_TIMESTAMP in the integrated EVM chain, add precompiled contract
P256VERIFY for signature verifications in the “secp256r1” elliptic curve at address
“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: y^2 ≡ x^3 + ax + b # p: specifies reduced elliptic group 0xffffffff00000001000000000000000000000000ffffffffffffffffffffffff # a: elliptic curve coefficient 0xffffffff00000001000000000000000000000000fffffffffffffffffffffffc # b: elliptic curve coefficient 0x5ac635d8aa3a93e7b3ebbd55769886bc651d06b0cc53b0f63bce3c3e27d2604b # G: base point of the subgroup (0x6b17d1f2e12c4247f8bce6e563a440f277037d812deb33a0f4a13945d898c296, 0x4fe342e2fe1a7f9b8ee7eb4a7c0f9e162bce33576b315ececbb6406837bf51f5) # n: order of the subgroup 0xffffffff00000000ffffffffffffffffbce6faada7179e84f3b9cac2fc632551 # h: cofactor of the subgroup 0x1
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:
# h (message hash) # pubKey = (public key of the signer private key) # Calculate the modular inverse of the signature proof: s1 = s^(−1)(modn) # Recover the random point used during the signing: R' = (h * s1) * G + (r * s1) * pubKey # Take from R' its x-coordinate: r' = R'.x # Calculate the signature validation result by comparing whether: r' == r
Some requirements have to be checked to understand if the given signature components are valid:
- Verify that both
svalues 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 (
y) values is on the curve and both components are in between 0 and the
pvalue of the curve.
P256VERIFY precompiled contract is proposed with the following input and outputs, which are big-endian values:
- Input data: 160 bytes of data including:
- 32 bytes of the signed data
- 32 bytes of the
rcomponent of the signature
- 32 bytes of the
scomponent of the signature
- 32 bytes of the
xcoordinate of the public key
- 32 bytes of the
ycoordinate of the public key
- 32 bytes of the signed data
- Output data: 32 bytes of result data and error
- If the signature verification process succeeds, it returns 1 in 32 bytes format.
The “secp256r1” elliptic curve signatures consists of
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
s values. In order to provide an exact and more compatible method, verification is preferred over recovery to propose in a precompiled.
The signature values in
s and the public key coordinates in the
y provides direct computations in signing and verification part, so these formats are chose in the input data format which are 32 bytes.
PRECOMPILED_ADDRESS is chosed in
0x19 as it is the next available address in the precompiled address set.
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 part) than “secp256k1” signature recovery by
3450 gas is proposed by comparison which causes similar “mgas/op” values in both precompiles.
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.
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
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:
# results of geth benchmark tests of # ECRECOVER and P256VERIFY (reference implementation) # by benchstat tool goos: darwin goarch: arm64 pkg: github.com/ethereum/go-ethereum/core/vm │ compare_p256Verify │ compare_ecrecover │ │ sec/op │ sec/op │ PrecompiledP256Verify/p256Verify-Gas=3450-8 57.75µ ± 1% PrecompiledEcrecover/-Gas=3000-8 50.48µ ± 1% geomean 57.75µ 50.48µ │ compare_p256Verify │ compare_ecrecover │ │ gas/op │ gas/op │ PrecompiledP256Verify/p256Verify-Gas=3450-8 3.450k ± 0% PrecompiledEcrecover/-Gas=3000-8 3.000k ± 0% geomean 3.450k 3.000k │ compare_p256Verify │ compare_ecrecover │ │ mgas/s │ mgas/s │ PrecompiledP256Verify/p256Verify-Gas=3450-8 59.73 ± 1% PrecompiledEcrecover/-Gas=3000-8 59.42 ± 1% geomean 59.73 59.42 │ compare_p256Verify │ compare_ecrecover │ │ B/op │ B/op │ PrecompiledP256Verify/p256Verify-Gas=3450-8 1.523Ki ± 0% PrecompiledEcrecover/-Gas=3000-8 800.0 ± 0% geomean 1.523Ki 800.0 │ compare_p256Verify │ compare_ecrecover │ │ allocs/op │ allocs/op │ PrecompiledP256Verify/p256Verify-Gas=3450-8 33.00 ± 0% PrecompiledEcrecover/-Gas=3000-8 7.000 ± 0% geomean 33.00 7.000
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.
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.
Please cite this document as:
Ulaş Erdoğan (@ulerdogan), Doğan Alpaslan (@doganalpaslan), "EIP-7212: Precompiled for secp256r1 Curve Support [DRAFT]," Ethereum Improvement Proposals, no. 7212, June 2023. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7212.