ethdo audit

Introduction

We would like to announce a Request for Proposals (RfP) for a security review of ethdo.

ethdo is a tool to carry out common operations on Eth2, including creating wallets and accounts, generating data for deposits, and sending exit transactions.

Table of Contents

Version of code for audit

The github commit of the code for audit is b6bb1ba46b34e3732c2fc149333682647bb3c817, also marked with the tag v1.5.8.

Scope of audit

As ethdo has a broad range of functionality, it is important to define the scope of the audit. The areas, specific functions and their place in or out of scope of the audit are provided below.

Wallet management

These functions cover wallet creation, import and export, display, etc. The specific functions are:

Account management

These functions cover account creation, import, display, etc. The specific functions are:

Signature operations

These functions cover creation and verification of signatures. The specific functions are:

Validator operations

These functions cover creation, monitoring and operations for validators. The specific functions are:

Deposit operations

These functions cover validation of deposit data. The specific functions are:

Exit operations

These functions cover validation of exit operations. The specific functions are:

Node and chain information

These functions cover fetching and displaying information from an active beacon node. Due to the lack of a standard API at time of writing, they only support the prysm beacon node. The specific functions are:

Store type

ethdo allows multiple backend stores of encrypted information. These are as follows:

Dependencies

Much of the work in ethdo, especially the cryptograhpic work, is carried out by other go modules. The following modules are IN SCOPE for the audit:

In addition to the above modules, many EIPs define standards that ethdo implements. Adherence to these standards where applicable is in scope:

Specific areas of focus

It is expected that the audit will provide full coverage of the features mentioned above, however the following areas are highlighted as particular areas of concern or sensitivity.

Random number generation

All random number generation (HD seeds, ND private keys) is an obvious area to examine.

Creation of HD accounts from seed

Creation of hierarchical deterministic accounts from a well-known seed should be checked against relevant test vectors.

Encryption of secrets

All situations where keys are sensitive data (private keys, HD seeds) are encrypted should be considered.

Deposit data generation

The generation of deposit data is an important part of the Ethereum 2 deposit process. Adherence to the specification regarding generation of each individual component of the deposit is critical.

Process summary

The entire process can be summarised as follows:

  1. Request: EF releases RfP (this post)
  2. Gather: Vendors submit proposals
  3. Deliberate: EF decides which proposal to accept, and comes up with a plan based on the resources and needs of the accepted proposal.
  4. Propose: EF proposes the plan to vendor, and makes adjustments based on vendor’s feedback
  5. Begin: Vendor accepts and work begins

Engagement timeline

The proposed timeline of the engagement is approximately 1 month.

The engagement is broken up into the following stages: a vendor assessment, followed by a break for developer response and mitigation, followed by a review phase from the vendor.

The vendor will then summarize findings and publish the results to help the community understand the work that was done.

Stage Description
1 Vendor assessment period
2 Developer issue response
3 Vendor review issue response
4 Vendor summarises findings

Members of the EF and ethdo contributors will be available at all times to answer questions and comments during the assessment period in order to make life as easy as possible for the vendor.

Deliverables

Deliverable will take the form of Github issues in the relevant Github repository for every security concern found.

As outlined above, the vendor will provide a report distilling the lessons learnt, and summarising the issues submitted.

Fee Structure

Invoices

Based on the timeline of this audit, the chosen vendor will be expected to submit 2 invoices:

Payment method

The vendor will be given the option to be paid in Fiat money (via bank transfer) or ETH.

If the vendor chooses to be paid in ETH, the value of ETH described under the agreement will be the value in USD at NYSE closing time (4 PM EST) on the day prior to the due date (as described at https://www.coingecko.com).

Selection criteria

The selected vendor will have significant expertise in the areas necessary to meet the needs and requirements set forth in this RfP. Particularly:

Experience with the Go programming language
High level familiarity with cryptographic signature schemes
Familiarity with cryptocurrency key management and wallets

The EF and ethdo maintainers have considerable expertise in these domains and is ready to support the vendor.

Bidding instructions

Upon reception of this request, interested vendors are expected to confirm receipt and intention to bid on the engagement.

In this confirmation, they should explain what they need from us in order to get started. As well as bring attention to areas in which they feel they do not have significant expertise. We will use this information to try to provide appropriate entrance material for the engagement.

Proposals must be submitted before September 7th, 12 PM EST. We expect to take 1 week to deliberate and respond.

Please send initial confirmations, and proposals (in PDF format) to the following address: rfp@ethereum.org

Feel free to send us any questions you may have: rfp@ethereum.org

Last changed by  
 
Danny Ryan
2646

Read more

Public eth2 launch health metrics

[toc] Pre-genesis Prior to genesis, we want to ensure all clients agree on genesis info and that the p2p network looks strong genesis root/state/time and fork_digest in agreement nodes of each type successfully peer through discovery and maintain healthy peer counts leading up to genesis Post-genesis Monitor logs, block explorers, and local http endpoints looking for the following events

Mar 15, 2022
Eth2 Phase 0 Pre-Launch Bounty Program

⚠️The bug bounty program is no longer "pre-launch" and instead has a permanent home and stable set of rules. Check it out here!⚠️ We are excited to kick off the Eth2 Phase 0 Pre-Launch Bounty Program. This program is designed to incentivize you to find and report bugs in the core Eth2 Phase 0 specs prior to mainnet launch 🐛. The Ethereum Foundation will run this program from now until just prior to the Phase 0 mainnet launch. After Phase 0 is in production, we will transition Phase 0 bounties to the standard Ethereum Bounty Program. Note: As of 2020/5/6 all rewards have been doubled for a maximum reward of $20k for critical bugs :) Note: As of 2020/6/22, the Solidity eth2 deposit contract and formal verification have been added to the scope of the bounty program

Oct 15, 2021
Sign-in with Ethereum RFP

Introduction The Ethereum Foundation (EF) and True Names LTD (ENS) would like to announce a Request for Proposals (RFP) for the creation of a Sign-In with Ethereum specification, a package using Oauth for easy implementation by web2 services, and a Javascript library for the user-facing part of sign-in. [toc] Scope Survey current practices: Examine existing uses of Sign-In with Ethereum, look at the code, and talk to the developers. Determine what developers are doing and why, how it could be improved, and what best practices have already emerged. Specification: Write a specification for how Sign-In with Ethereum should work, both with and without Oauth. Include best practices and recommended graphics. The specification should be simple and generally follow existing practices. Avoid feature bloat, particularly the inclusion of lesser-used projects who see getting into the specification as a means of gaining adoption. The core specification should be decentralized, open, non-proprietary, and have long-term viability. It should have no dependence on a centralized server except for the servers already being run by the application that the user is signing in to. The basic specification should include: Ethereum accounts used for authentication, ENS names for usernames (via reverse resolution), and data from the ENS name's text records for additional profile information (e.g. avatar, social media handles, etc).

Jul 12, 2021
Phase 0 for Humans [v0.10.0]

Warning: This a work in progress document with many broken links, some unfinished sections, and commands for including code segments. The entirety of the document is subject to change without warning. Introduction This document is an aid to the specification of the state transition function and accompanying data structures for Phase 0 - The Beacon Chain -- the core system level chain at the heart of Ethereum 2.0. The primary Phase 0 specification is particularly terse, only defining much of the functionality via python code and comments. This document aims to provide a more verbose version of the specification, primarily aimed at helping onboard new contributors to Ethereum 2.0. Table of contents [toc]

Jul 1, 2021
Read more from Danny Ryan
Published on HackMD