Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Update EIP-7212: Move to Moved #8101

Closed
wants to merge 4 commits into from
+3 −256
Closed

Update EIP-7212: Move to Moved #8101

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
5847475
removes EIP7212 as it is RIP7212 now
CarlBeek Jan 9, 2024
5ec547f
rm -rf ./assets/eip-7212/
CarlBeek Jan 9, 2024
cddec09
Adds back info about 7212 being moved, not removed
CarlBeek Jan 9, 2024
bb45897
change category from EIP -> RIP
CarlBeek Jan 9, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
187 changes: 3 additions & 184 deletions EIPS/eip-7212.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,188 +1,7 @@
---

Check failure on line 1 in EIPS/eip-7212.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

preamble is missing header(s): `title`, `description`, `author`, `discussions-to`, `type`, `created` 

error[preamble-req]: preamble is missing header(s): `title`, `description`, `author`, `discussions-to`, `type`, `created`
--> EIPS/eip-7212.md
 |
 |
 = help: see https://ethereum.github.io/eipw/preamble-req/
eip: 7212
title: Precompile for secp256r1 Curve Support
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
category: Core
created: 2023-06-22
category: RIP

Check failure on line 3 in EIPS/eip-7212.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

preamble header `category` has an unrecognized value 

error[preamble-enum-category]: preamble header `category` has an unrecognized value
 --> EIPS/eip-7212.md:3:10
  |
3 | category: RIP
  |          ^^^^ must be one of: `Core`, `Networking`, `Interface`
  |
  = help: see https://ethereum.github.io/eipw/preamble-enum-category/

Check failure on line 3 in EIPS/eip-7212.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

preamble header `category` is out of order 

error[preamble-order]: preamble header `category` is out of order
 --> EIPS/eip-7212.md
  |
3 | category: RIP
  |
  = help: `category` should come after `status`
  = help: see https://ethereum.github.io/eipw/preamble-order/

Check failure on line 3 in EIPS/eip-7212.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

preamble header `category` is only allowed when `type` is `Standards Track` 

error[preamble-req-category]: preamble header `category` is only allowed when `type` is `Standards Track`
 --> EIPS/eip-7212.md:3:1
  |
3 | category: RIP
  | ^^^^^^^^^^^^^ defined here
  |
  = help: see https://ethereum.github.io/eipw/preamble-req-category/
status: Moved

Check failure on line 4 in EIPS/eip-7212.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

preamble header `status` has an unrecognized value 

error[preamble-enum-status]: preamble header `status` has an unrecognized value
 --> EIPS/eip-7212.md:4:8
  |
4 | status: Moved
  |        ^^^^^^ must be one of: `Draft`, `Review`, `Last Call`, `Final`, `Stagnant`, `Withdrawn`, `Living`
  |
  = help: see https://ethereum.github.io/eipw/preamble-enum-status/
---

Check failure on line 6 in EIPS/eip-7212.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

body is missing section(s): `Abstract`, `Specification`, `Rationale`, `Security Considerations`, `Copyright` 

error[markdown-req-section]: body is missing section(s): `Abstract`, `Specification`, `Rationale`, `Security Considerations`, `Copyright`
--> EIPS/eip-7212.md
 |
 |
 = help: must be at the second level (`## Heading`)
 = help: see https://ethereum.github.io/eipw/markdown-req-section/
## Abstract

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.

## Motivation

“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:

1. **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.
2. **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.
3. **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.
4. **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.

## Specification

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 `0x0b`.

### Elliptic Curve Information

“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: short weierstrass form
y^2 ≡ x^3 + ax + b

# p: curve prime field modulus
0xffffffff00000001000000000000000000000000ffffffffffffffffffffffff

# a: elliptic curve short weierstrass first coefficient
0xffffffff00000001000000000000000000000000fffffffffffffffffffffffc

# b: elliptic curve short weierstrass second coefficient
0x5ac635d8aa3a93e7b3ebbd55769886bc651d06b0cc53b0f63bce3c3e27d2604b

# G: base point of the subgroup
(0x6b17d1f2e12c4247f8bce6e563a440f277037d812deb33a0f4a13945d898c296,
0x4fe342e2fe1a7f9b8ee7eb4a7c0f9e162bce33576b315ececbb6406837bf51f5)

# n: subgroup order (number of points)
0xffffffff00000000ffffffffffffffffbce6faada7179e84f3b9cac2fc632551

# h: cofactor of the subgroup
0x1

```

### Elliptic Curve Signature Verification Steps

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) (mod n)

# 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

```

### Required Checks in Verification

The following requirements **MUST** be checked by the precompiled contract to verify signature components are valid:

- 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

The `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 `hash`
- 32 bytes of the `r` component of the signature
- 32 bytes of the `s` component of the signature
- 32 bytes of the `x` coordinate of the public key
- 32 bytes of the `y` coordinate of the public key
- **Output data:** 32 bytes of result data and error
- If the signature verification process succeeds, it returns 1 in 32 bytes format.

### Precompiled Contract Gas Usage

The use of signature verification cost by `P256VERIFY` is `3450` gas. Following reasons and calculations are provided in the [Rationale](#rationale) and [Test Cases](#test-cases) sections.

## Rationale

“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 `0x0b` 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` 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](#test-cases)) than “secp256k1” signature recovery, so `3450` gas is proposed by comparison which causes similar “mgas/op” values in both precompiled contracts.

## Backwards Compatibility

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

Functional tests are applied for multiple cases in the [reference implementation](#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](#reference-implementation). The benchmark test results by example data in the assets can be checked:

- [P256Verify Benchmark Test Results](../assets/eip-7212/p256Verify_benchmark_test)
- [Ecrecover Benchmark Test Results](../assets/eip-7212/ecrecover_benchmark_test)

```
# 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

```

## Reference Implementation

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

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

Copyright and related rights waived via [CC0](../LICENSE.md).
This file was moved to https://github.com/ethereum/rips/blob/master/RIPS/rip-7212.md

Check failure on line 7 in EIPS/eip-7212.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

non-relative link or image 

error[markdown-rel-links]: non-relative link or image
 --> EIPS/eip-7212.md
  |
7 | This file was moved to https://github.com/ethereum/rips/blob/master/RIPS/rip-7212.md
  |
  = help: see https://ethereum.github.io/eipw/markdown-rel-links/

Check failure on line 7 in EIPS/eip-7212.md

View workflow job for this annotation

GitHub Actions / Markdown Linter

First line in a file should be a top-level heading [Context: "This file was moved to https:/..."] 

EIPS/eip-7212.md:7 MD041/first-line-heading/first-line-h1 First line in a file should be a top-level heading [Context: "This file was moved to https:/..."]
42 changes: 0 additions & 42 deletions assets/eip-7212/benchstat_compare_test
View file
Open in desktop

This file was deleted.

15 changes: 0 additions & 15 deletions assets/eip-7212/ecrecover_benchmark_test
View file
Open in desktop

This file was deleted.

15 changes: 0 additions & 15 deletions assets/eip-7212/p256Verify_benchmark_test
View file
Open in desktop

This file was deleted.

Loading