The Ethereum Foundation (EF) and Protocol Labs (PL) would like to announce a Request for Proposals (RfP) for a security review of blst.
blst (pronounced ‘blast’) is a BLS12-381 signature library written in C and assembly focused on performance and security.
The Boneh–Lynn–Shacham (BLS) signature scheme allows a user to verify that a signer is authentic.
Signatures are elements of an elliptic curve group, and a pairing is used for verification.
The scheme has a variety of important properties. For our purposes, two distinguishing ones are:
Signature aggregation. A collection of signatures (signature_1, …, signature_n) can be aggregated into a single signature. Moreover, the aggregate signature can be verified using only 2 pairings, as opposed to 2n pairings, when verifying n signatures separately (verifying a signature requires 2 pairing operations). Furthermore the most expensive part of pairing computation, the final exponentiation, can be done once per aggregate.
Threshold signatures. Threshold signatures allows verifiers to check that a threshold number of nodes have signed something. Specifically, threshold signatures allow for a private key to be spread across multiple nodes. Any subset of these nodes, as long as they are more than some threshold number, can then sign a message, without bringing their private keys together.
A pairing is a bilinear map defined between groups. In the context of BLS signatures, it is a map e: G1 x G2 --> GT where G1, G2, and GT are distinct subgroups of the same prime order.
Pairings greatly expand what elliptic curve-based protocols can do, enabling things like threshold signatures, for example.
In eth2, validators are organised into committees to do their work. A vote cast by a validator is called an attestation. And an attestation is comprised of many elements, specifically:
Attestations are designed to be easily combined such that if two or more validators have attestations with the same votes, they can be combined by adding the signatures fields together in one attestation. This is what we mean by aggregation.
This is the mechanism by which eth2 scales the number of validators. By breaking the validators up into committees, validators need only to care about their fellow committee members and only have to check very few aggregated attestations from each of the other committees.
Eth2 makes use of the aggregation property of BLS signatures to reduce the computational cost. On the specific curve chosen (BLS12-381), signatures are 96 bytes each.
BLS12-381 is part of a family of curves described by Barreto, Lynn, and Scott. It’s a curve that’s both secure and optimized for pairing operations.
The 12 is the embedding degree of the curve.
The 381 is the number of bits needed to represent a coordinate (in Fq) on the curve: the field modulus, q. In other words, the 381 means that the prime in the finite field Fq is of 381 bits. The size of this number is guided both by security requirements and implementation efficiency.
Note that the BLS (Barreto-Lynn-Scott) in BLS12-381 is different from the BLS (Boneh–Lynn–Shacham) in BLS signature scheme. The BLS signature scheme works with many curves, BLS and non-BLS.
Full description
u = -0xd201000000010000
k = 12
q = 0x1a0111ea397fe69a4b1ba7b6434bacd764774b84f38512bf6730d2a0f6b0f6241eabfffeb153ffffb9feffffffffaaab
r = 0x73eda753299d7d483339d80809a1d80553bda402fffe5bfeffffffff00000001
E(Fq) := y^2 = x^3 + 4
Fq2 := Fq[i]/(x^2 + 1)
E'(Fq2) := y^2 = x^3 + 4(i + 1)
For a more thorough introduction to the curve, and it’s properties, see here.
The BLS signature requirements for phase 0 are described in the beacon chain spec here.
The relevant IETF standardization efforts are BLS12-381 curve, Hash-To-Curve draft 9, and BLS Signatures draft 2.
A ciphersuite describes the building blocks (a curve, mapping a message to a point on the curve, a signature scheme, magic constants/ID, etc) underpinning a crypto protocol.
For our purposes the relevant ciphersuites are:
BLS12381G2_XMD:SHA-256_SSWU_RO
BLS_SIG_BLS12381G2_XMD:SHA-256_SSWU_RO_POP_BLS_POP_BLS12381G2_XMD:SHA-256_SSWU_RO_POP_The github commit of the code for audit will be determined at the start of the audit. The blst code is developed in the open at https://github.com/supranational/blst
The audit should focus on assessing the security and correctness of the Go and Rust binding implementations, along with the underlying C code found in the src directory. Optionally, the assembly found in the asm directory can also be considered to be in scope, but proposals will be accepted that do not audit this code.
Root - Contains various configuration files, documentation, licensing, and a build script
The library is intended to be compliant with the following IETF draft specifications:
The goal of the audit should be to improve the assurance that the cryptography code is correct and well implemented. Additionally, because this library will be used in a consensus system, it is critical that identical outputs are returned for both the Rust and Go bindings.
The entire process can be summarised as follows:
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, PL, and blst 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.
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.
Based on the timeline of this audit, the chosen vendor will be expected to submit 2 invoices:
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).
The selected vendor will have significant expertise in the areas necessary to meet the needs and requirements set forth in this RfP. Particularly:
Expertise in applied cryptography and cryptographic systems
Expertise in low level, optimised code
Experience with the C, Rust, and Go programming languages
Experience with assembly programming
The EF, PL, and blst maintainers have considerable expertise in these domains and are ready to support the vendor.
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 18th at 5pm PST. 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