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-665: Move to Draft #7515

Closed
wants to merge 12 commits into from
Closed

Update EIP-665: Move to Draft #7515

Changes from all commits
Commits
Show all changes
12 commits
Select commit Hold shift + click to select a range
30427a9
update EIP665
Aug 23, 2023
fbaa597
fixing linter
Aug 23, 2023
9a3879a
fixing EIP walidator
Aug 24, 2023
8e308c4
more linting
Aug 24, 2023
6a968e4
more lint
Aug 24, 2023
f99fd2a
more linting
Aug 24, 2023
cbc3582
missing space
Aug 24, 2023
29440a7
wrong space at http
Aug 24, 2023
6fa22a8
fix references
Aug 25, 2023
7de6c0a
link syntax
Aug 26, 2023
4e23e0c
missing blank lines
Aug 26, 2023
9c7b936
missing reference to [HAM15] fixed
Aug 26, 2023
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
168 changes: 116 additions & 52 deletions EIPS/eip-665.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,16 +1,15 @@
---
eip: 665
title: Add precompiled contract for Ed25519 signature verification
author: Tobias Oberstein <[email protected]>
status: Stagnant
title: Ed25519 Signature Verification
description: Support performant and cheap verification of Ed25519 adding precompiled contracts to the EVM.
author: Renaud Dubois (@rdubois-crypto), Tobias Oberstein <[email protected]>
discussions-to: https://ethereum-magicians.org/t/eip-665-ed25519-signature-verification/15535
status: Draft
type: Standards Track
category: Core
created: 2018-03-25
---

## Simple Summary

Support performant and cheap verification of Ed25519 cryptographic signatures in smart contracts in general by adding a precompiled contract for Ed25519 signature verification to the EVM.

## Abstract

Expand All @@ -20,34 +19,58 @@

## Motivation

Ed25519 and Ed448 (that is, EdDSA using Curve25519 or Curve448) are IETF recommendations ([RFC7748](https://tools.ietf.org/html/rfc7748)) with some attractive properties:
Ed25519 and Ed448 (that is, EdDSA using [Curve25519][Be06] or [Curve448][Ham15]) are [IETF] recommendations ([RFC7748]) with some attractive properties:

Check failure on line 22 in EIPS/eip-665.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-665.md
   |
22 | Ed25519 and Ed448 (that is, EdDSA using [Curve25519][Be06] or [Curve448][Ham15]) are [IETF] recommendations ([RFC7748]) with some attractive properties:
   |
   = help: see https://ethereum.github.io/eipw/markdown-rel-links/

Check failure on line 22 in EIPS/eip-665.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-665.md
   |
22 | Ed25519 and Ed448 (that is, EdDSA using [Curve25519][Be06] or [Curve448][Ham15]) are [IETF] recommendations ([RFC7748]) with some attractive properties:
   |

Check failure on line 22 in EIPS/eip-665.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-665.md
   |
22 | Ed25519 and Ed448 (that is, EdDSA using [Curve25519][Be06] or [Curve448][Ham15]) are [IETF] recommendations ([RFC7748]) with some attractive properties:
   |

Check failure on line 22 in EIPS/eip-665.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-665.md
   |
22 | Ed25519 and Ed448 (that is, EdDSA using [Curve25519][Be06] or [Curve448][Ham15]) are [IETF] recommendations ([RFC7748]) with some attractive properties:
   |

* Ed25519 is intended to operate at around the 128-bit security level and Ed448 at around the 224-bit security level
* EdDSA uses small public keys (32 or 57 octets) and signatures (64 or 114 octets) for Ed25519 and Ed448, respectively
* Ed25519/Ed448 are designed so that fast, constant-time (timing attack resistant) and generally side-channel resistant implementations are easier to produce

Despite being around only for some years, post-Snowden, these curves [have gained wide use](https://ianix.com/pub/ed25519-deployment.html) quickly in various protocols and systems:
Despite being around only for some years, post-Snowden, these curves have gained wide use ([IANIX]) in various protocols and systems:

Check failure on line 28 in EIPS/eip-665.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-665.md
   |
28 | Despite being around only for some years, post-Snowden, these curves have gained wide use ([IANIX]) in various protocols and systems:
   |

* TLS / ECDH(E) (session keys)
* TLS / x.509 (client and server certificates)
* DNSSEC (zone signing)
* OpenSSH (user keys)
* GNUPG/OpenPGP (user keys)
* OpenBSD Signify (software signing)
* FIDO/WebAuthn (passkeys)

One motivation for Ed25519 signature verification in smart contracts is to **associate** existing off-chain systems, records or accounts that use Ed25519 (like above) with blockchain addresses or **delegate** by allowing to sign data with Ed25519 (only), and then submit this Ed25519-signed data anonymously (via any Eth sender address) to the blockchain, having the contract check the Ed25519 signature of the transaction.

Another motivation is the processing of external, Ed25519 proof-of-stake based blockchains within Ethereum smart contracts.

When a transactions contains data that comes with an Ed25519 signature, that proves that the sender of the Ethereum transaction was also in control of the private key (and the data), and this allows the contract to establish an association between the blockchain and the external system or account, and the external system establish the reverse relation.
They gained so much tractions that they have been introduced into NIST standard [FIPS186-5] in 2023.

* One motivation for EdDSA signature verification in smart contracts is to **associate** existing off-chain systems, records or accounts that use Ed25519 (like above) with blockchain addresses or **delegate** by allowing to sign data with Ed25519 (only), and then submit this Ed25519-signed data anonymously (via any Eth sender address) to the blockchain, having the contract check the Ed25519 signature of the transaction.
* Another motivation is the processing of external, Ed25519 proof-of-stake based blockchains within Ethereum smart contracts.
When a transactions contains data that comes with an Ed25519 signature, that proves that the sender of the Ethereum transaction was also in control of the private key (and the data), and this allows the contract to establish an association between the blockchain and the external system or account, and the external system establish the reverse relation.
For example, a contract might check a Ed25519 signed piece of data submitted to the Ethereum transaction like the current block number. That proves to the contract, that the sender is in possession of both the Ethereum private key and the Ed25519 private key, and hence the contract will accept an association between both. This again can be the root anchor for various powerful applications, as now a potentially crypto holding key owner has proven to be in control of some external off-chain system or account, like e.g. a DNS server, a DNS domain, a cluster node and so on.
* A third motivation is to build MPC signature on top of it. As opposed to ECDSA, EdDSA is a Schnorr based scheme, which enables simpler and safer MPC implementations on top of it.
* At last, as part of [FIDO] allowed algorithms, using Ed25519 together with [ERC-4337](./eip-4337.md) will provide secure enclave biometric gated WebAuthn implementations such as Touch ID/Face ID.

Check failure on line 45 in EIPS/eip-665.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-665.md
   |
45 | * At last, as part of [FIDO] allowed algorithms, using Ed25519 together with [ERC-4337](./eip-4337.md) will provide secure enclave biometric gated WebAuthn implementations such as Touch ID/Face ID. 
   |


## Specification

If `block.number >= CONSTANTINOPLE_FORK_BLKNUM`, add a precompiled contract for Ed25519 signature verification (`ED25519VFY`).
The reference for mathematical specification is RFC8032. Reference vectors are provided in [IETF].

Check failure on line 50 in EIPS/eip-665.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-665.md
   |
50 | The reference for mathematical specification is RFC8032. Reference vectors are provided in [IETF].
   |
The ED25519MMA function is implemented in [FCL] as ed_mulmuladd function, with a full description of optimizations described in [Dub17].

Check failure on line 51 in EIPS/eip-665.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-665.md
   |
51 | The ED25519MMA function is implemented in [FCL] as ed_mulmuladd function, with a full description of optimizations described in [Dub17].
   |

Check failure on line 51 in EIPS/eip-665.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-665.md
   |
51 | The ED25519MMA function is implemented in [FCL] as ed_mulmuladd function, with a full description of optimizations described in [Dub17].
   |

If `block.number >= DENCUN_FORK_BLKNUM`, add a precompiled contract for Ed25519 signature verification (`ED25519VFY`).

The proposal adds two new precompiled functions:

* ED25519MMA implements a double scalar multiplication,
* ED25519VFY implements the full EDDSA verification with SHA512 as core hash function.


### ED25519MMA

`ED25519MMA` takes as **input 96 octets**:

1. **u**: the 32-octet first scalar,
2. **v**: the 32-octet second scalar.
3. **public key**: the 32-octet Ed25519 public key Q of the signer

`ED25519VFY` returns as **output 32 octets**:
**R**: the value of R=u.G+v.Q where G is the curve generator and Q a valid point of the curve.

### ED25519VFY

The proposal adds a new precompiled function `ED25519VFY` with the following input and output.

`ED25519VFY` takes as **input 128 octets**:

Expand All @@ -60,79 +83,120 @@
* `0x00000000` if signature is valid
* any non-zero value indicates a signature verification failure

### Address
### Addresses


The address of `ED25519VFY` is **`0x9`.**
* The address of `ED25519MMA` is **`0x10`.**
* The address of `ED25519VFY` is **`0x11`.**

### Gas costs

Gas cost for `ED25519VFY` is **2000**.
* Gas cost for `ED25519VFY` is **3000**.
* Gas cost for `ED25519MMA` is **3000**.


## Rationale

The proposed `ED25519VFY` function takes the signer public key as a call parameter, as with Ed25519, I don't believe it is possible to derive the signers public key from the signature and message alone.
### ED25519VFY

The proposed `ED25519VFY` function uses a zero return value to indicate success, since this allows for different errors to be distinguished by return value, as all non-zero return values signal a verification failure.

`ECRECOVER` has a gas cost of 3000. Since Ed25519 is computationally cheaper, the gas price should be less.
`ECRECOVER` has a gas cost of 3000. Since Ed25519 is computationally cheaper, the gas price shall at least be lesser or equal than ecrecover.
For equity and interoperability, this proposal set the cost to the same price.
Here is the benchmark obtained using openssl implementation on a standard labtop:

```

* Doing 253 bits verify Ed25519's for 10s: 112492 253 bits Ed25519 verify in 10.00s
* Doing 256 bits verify ecdsa's for 10s: 187517 256 bits ECDSA verify in 10.00s

```

### ED25519MMA

Being a necessary part of the whole computation, ED25519MMA shall have a lesser or equal cost as ED25519VFY. Having this intermediate precompile enables to use alternate hashing functions, such as zk-friendly ones (MiMc, Poseidon) or keccak if required for gas cost consumption reasons.

## Backwards Compatibility

As the proposed precompiled contract is deployed at a reserved (<255) and previously unused address, an implementation of the proposal should not introduce any backward compatibility issues.

## Test Cases

Test vectors for Ed25519 can be found in this IETF ID https://tools.ietf.org/html/draft-josefsson-eddsa-ed25519-03#section-6.
Test vectors for Ed25519 can be found in this [IETF], section 6.

Check failure on line 125 in EIPS/eip-665.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-665.md
    |
125 | Test vectors for Ed25519 can be found in this [IETF], section 6.
    |

More test vectors can be found in the regression tests of NaCl (see references).

## Implementation
## Reference Implementation

### libsodium
### solidity

libsodium is a mature, high-quality C implementation of Ed25519, with bindings for many languages.
[FCL] is a library providing optimized ECC implementations for secp256r1 and ed25519 (both being part of FIDO) with in a WebAuthn framework. Current implementation has a 206K gas cost.

Further, libsodium is (to my knowledge, and as of today 2018/04) the only Ed25519 implementation that has gone through a [Security Assessment](https://www.privateinternetaccess.com/blog/2017/08/libsodium-v1-0-12-and-v1-0-13-security-assessment/).

To minimize consensus failure risks, the proposal recommends to use libsodium for adding the precompile in all Ethereum client implementations.
### libsodium

> Note: as an alternative to libsodium, I looked into HACL, an implementation of Ed25519 in F* (a ML dialect) that can be transpiled to C, and that was formally verified for functional correctness and memory safety of the resulting C code. However, this is new and compared to libsodium which is a "know thing" seems risky nevertheless.
[libsodium] is a mature, high-quality C implementation of Ed25519, with bindings for many languages that has gone through a [Security Assessment].

### libsodium bindings

Here is an overview of the language bindings to libsodium for four Ethereum clients this proposal recommends:

| Client | Language | libsodium binding |
|---------------|----------|--------------------|
| Geth | Go | use cgo with C [libsodium] |
| Parity | Rust | [sodiumoxide] |
| PyEthereum | Python | [Pynacl]
| cpp-ethereum | C++ | [libsodium] |

| Client | Language | libsodium binding |
---------------|----------|--------------------|
| Geth | Go | use cgo with C [libsodium](https://github.com/jedisct1/libsodium)|
| Parity | Rust | [sodiumoxide](https://github.com/dnaq/sodiumoxide)|
| PyEthereum | Python | [PyNaCl](https://github.com/pyca/pynacl)|
| cpp-ethereum | C++ | [libsodium](https://github.com/jedisct1/libsodium)|
----------------------------------------------------------------------------

### PRs

Implementations of this proposal are here:

1. [go-ethereum PR #16453](https://github.com/ethereum/go-ethereum/pull/16453)
2. [pyethereum PR #862](https://github.com/ethereum/pyethereum/pull/862)
3. [parity PR #8330](https://github.com/paritytech/parity/pull/8330)
4. [cpp-ethereum PR #4945](https://github.com/ethereum/cpp-ethereum/pull/4945)

## References

* RFC7748 - Elliptic Curves for Security https://tools.ietf.org/html/rfc7748
* Definition of Ed25519: https://ed25519.cr.yp.to/ed25519-20110926.pdf
* Ed25519 - high-speed high-security signatures: https://ed25519.cr.yp.to/
* NaCl - Networking and Cryptography library: https://nacl.cr.yp.to/sign.html
* NaCl Crypto Libraries (which contains Ed25519): https://ianix.com/pub/ed25519-deployment.html
* Test vectors for Ed25519: https://tools.ietf.org/html/draft-josefsson-eddsa-ed25519-03#section-6
* NaCl regression tests: https://ed25519.cr.yp.to/python/sign.py and https://ed25519.cr.yp.to/python/sign.input
* On the recoverability of public keys from signature+message (alone): https://crypto.stackexchange.com/questions/9936/what-signature-schemes-allow-recovering-the-public-key-from-a-signature
* Bernstein, D., "Curve25519: new Diffie-Hellman speed records", DOI 10.1007/11745853_14, February 2006, https://cr.yp.to/ecdh.html
* Hamburg, M., "Ed448-Goldilocks, a new elliptic curve", June 2015, https://eprint.iacr.org/2015/625>
* RFC8080: Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC (https://tools.ietf.org/html/rfc8080)
1. [FCL]
2. [go-ethereum PR #16453]
3. [pyethereum PR #862]
4. [parity PR #8330]
5. [cpp-ethereum PR #4945]

## Security Considerations

edDSA is recognized for its superior efficiency, transparency (nothing my sleeve conception, unlike secp curves), zk and MPC friendly.
While MPC schemes based on ECDSA suffered several 0-Day attacks, Schnorr is used in Musig2 (Taproot, lightning) without issue. For this reason it would be appreciable to have an efficient standardized base for MPC wallets.

### References

* [Be06] Bernstein, D., "Curve25519: new Diffie-Hellman speed records", DOI 10.1007/11745853_14, February 2006.
* [Dub17] Speeding up elliptic computations for Ethereum Account Abstraction, eprint 2023.
* [FCL] FreshCryptoLib, Cryptographic Primitives for Blockchain Systems (solidity, cairo, sage, C and rust)
* [FIDO] Authenticator Allowed Cryptography List.
* [FIPS 186-5] Digital Signature Standard (DSS).
* [RFC7748] Elliptic Curves for Security
* [RFC8032] Edwards-Curve Digital Signature Algorithm (EdDSA)
* [Ham15] Hamburg, M., "Ed448-Goldilocks, a new elliptic curve", June 2015
* [IETF] Test vectors for Ed25519
* [NaCl] Networking and Cryptography library
* [RFC8080] Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC

[Dub17]: https://eprint.iacr.org/2023/939
[FCL]: https://github.com/rdubois-crypto/FreshCryptoLib/blob/master/solidity/FCL_eddsa.sol
[go-ethereum PR #16453]: https://github.com/ethereum/go-ethereum/pull/16453
[pyethereum PR #862]: https://github.com/ethereum/pyethereum/pull/862
[parity PR #8330]: https://github.com/paritytech/parity/pull/8330
[cpp-ethereum PR #4945]: https://github.com/ethereum/cpp-ethereum/pull/4945
[libsodium]: https://github.com/jedisct1/libsodium
[sodiumoxide]: https://github.com/dnaq/sodiumoxide
[FIDO]: https://fidoalliance.org/specs/fido-security-requirements-v1.0-fd-20170524/fido-authenticator-allowed-cryptography-list_20170524.html
[FIPS 186-5]: https://csrc.nist.gov/pubs/fips/186-5/final
[RFC7748]: https://tools.ietf.org/html/rfc7748
[RFC8032]: https://datatracker.ietf.org/doc/html/rfc8032
[NaCl]: https://nacl.cr.yp.to/sign.html
[IETF]: https://tools.ietf.org/html/draft-josefsson-eddsa-ed25519-03#section-6
[Be06]: https://cr.yp.to/ecdh.html
[Ham15]: https://eprint.iacr.org/2015/625
[PyNaCl]: https://github.com/pyca/pynacl
[RFC8080]: https://tools.ietf.org/html/rfc8080
[IANIX]: https://ianix.com/pub/ed25519-deployment.html

## Copyright

Expand Down