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.

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

Protocol: EIP2333 - BLS12-381 Ethereum Consensus Key Generation #197

Closed
2 of 5 tasks
mratsim opened this issue Aug 4, 2022 · 0 comments · Fixed by #202
Closed
2 of 5 tasks

Protocol: EIP2333 - BLS12-381 Ethereum Consensus Key Generation #197

mratsim opened this issue Aug 4, 2022 · 0 comments · Fixed by #202
Labels
enhancement :shipit: New feature or request

Comments

@mratsim
Copy link
Owner

mratsim commented Aug 4, 2022

Goal: implement https://eips.ethereum.org/EIPS/eip-2333
Requestor: @Milerius for Trustwallet

The goal is to provide EIP2333 primitives:

Simple Summary

This EIP is a method based on a tree structure for deriving BLS private keys from a single source of entropy while providing a post-quantum cryptographic fallback for each key.

Abstract

This standard is a method for deriving a tree-hierarchy of BLS12-381 keys based on an entropy seed. Starting with the aforementioned seed, a tree of keys is built out using only the parent node’s private key and the index of the desired child. This allows for a practically limitless number of keys to be derived for many different purposes while only requiring knowledge of a single ancestor key in the tree. This allows for keys, or families thereof, to be provisioned for different purposes by further standards.

In addition to the above, this method of deriving keys provides an emergency backup signature scheme that is resistant to quantum computers for in the event that BLS12-381 is ever deemed insecure.
A note on purpose

This specification is designed not only to be an Ethereum 2.0 standard, but one that is adopted by the wider community who have adopted BLS signatures over BLS12-381. It is therefore important also to consider the needs of the wider industry along with those specific to Ethereum. As a part of these considerations, it is the intention of the author that this standard eventually migrate to a more neutral repository in the future.

Motivation

Deficiencies of the existing mechanism

The curve BLS12-381 used for BLS signatures within Ethereum 2.0 (alongside many other projects) mandates a new key derivation scheme. The most commonly used scheme for key derivation within Ethereum 1.x is BIP32 (also known as HD derivation) which deems keys greater than the curve order invalid. Based on the order of the private key subgroup of BLS12-381 and the size of the entropy utilised, more than 54% of keys generated by BIP32 would be invalid. (secp256k1 keys derived by BIP32 are invalid with probability less than 1 in 2-127.)

Establishing a multi-chain standard early on

By establishing a standard before the first users begin to generate their keys, the hope is that a single standard is highly pervasive and therefore can be assumed to be the method by which the majority of keys are provided. This is valuable for two reasons, firstly in order for a post-quantum backup mechanism to be effective, there needs to be an enshrined mechanism whereby users can switch to a post-quantum signature scheme with pre-shared public keys (something this EIP provides at 0 extra storage cost). Secondly, this unifies the inter- and intra-chain ecosystem by having common tooling ideally allowing users to switch between key-management systems.

A post-quantum backup

This key derivation scheme has a Lamport key pair which is generated as a intermediate step in the key generation process. This key pair can be used to provide a Lamport signature which is a useful backup in the event of BLS12-381 no longer being considered secure (in the event of quantum computing making a sudden advancement, for example). The idea is the Lamport signature will act as a bridge to a new signature scheme which is deemed to be secure.

EIP2333 depends on:

  • SHA256
    • Hardware-accelerated SHA256
  • HKDF - RFC5869
  • (mod r) with r the BLS12-381 curve order

Implementation:

@mratsim mratsim added the enhancement :shipit: New feature or request label Aug 4, 2022
@mratsim mratsim mentioned this issue Aug 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement :shipit: New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant