BLS: Short Signatures from the Weil Pairing and Later Aggregation

BLS signatures, named after Dan Boneh, Ben Lynn and Hovav Shacham, use bilinear pairings to provide compact digital signatures. The foundational paper is Short signatures from the Weil pairing. This reference distinguishes that original research from later signature aggregation and Ethereum’s implementation. [1]

Last updated: 2026-10-08

Paper and publication history

• Original authors: Dan Boneh, Ben Lynn and Hovav Shacham.
• Publication: ASIACRYPT 2001 extended abstract; expanded journal article in Journal of Cryptology 17(4), 297–319, 2004.
• Scope: short digital signatures and their security under computational Diffie–Hellman assumptions.
• Rights: public access does not establish a public-domain license; no such reuse permission is asserted here.

The original motivation included signatures transmitted over constrained channels or entered by people. Its concrete curve choices and size comparisons belong to that research period. They should not be copied into a modern implementation. [1] [2]

How signing and verification work

A secret scalar multiplies a message-derived curve point to produce a signature. A public key is obtained by multiplying a generator by the same scalar. A bilinear pairing lets a verifier check the relationship without learning the secret. The historical security argument is conditional on the chosen groups and a random-oracle model. A signature authenticates a message under a key; it does not establish that the message is truthful. [2]

Aggregation came later

Boneh, Craig Gentry, Lynn and Shacham developed aggregate signatures in their EUROCRYPT 2003 paper. Independently produced signatures can be combined into a single group element. Certificate chains and secure routing were motivating examples. This later construction should not be presented as though every modern feature was specified in the 2001 paper. [3] [4]

The compact result does not replace the messages, participating public keys or identification of signers. For different messages, the verification equation still includes message-dependent pairing terms. An optimized multi-pairing routine can share work, but aggregation does not imply constant verification cost for an arbitrary number of distinct messages. [4]

Modern schemes and rogue-key protection

The July 2026 CFRG BLS draft describes three schemes: basic aggregation requires distinct messages; augmentation incorporates the public key into each signed message; proof of possession validates control of each signing key. Fast aggregation for one shared message requires successfully verified proofs of possession. Otherwise, a malicious participant can choose a rogue public key that makes an apparent joint signature misleading. These are different security rules, not interchangeable options. [5]

Keys must be valid, non-identity points in the right subgroup, and signatures require their subgroup checks. The draft is a work in progress, not a published RFC. Protocols must identify the precise version and ciphersuite they implement. [5]

Ethereum sizes and use

Ethereum’s Phase 0 specification uses BLS12-381 public keys in G1, compressed to 48 bytes, and signatures in G2, compressed to 96 bytes. A valid aggregate signature remains 96 bytes. The opposite BLS variant minimizes signature size instead, so “all BLS signatures are 48 bytes” is incorrect. [5] [7]

The specification selects the G2 proof-of-possession ciphersuite and cites draft version 04. Its attestation structure stores aggregation bits, attestation data and a signature: the bits identify participating validators. This is not a claim that every validator signs every attestation. Later forks can change surrounding structures. Validator BLS signing keys also have a different role from execution-layer account keys and withdrawal credentials. [7] [8]

Implementation requirements and limits

Hashing a message into a suitable curve point is a defined cryptographic operation, not simply treating a hash as a coordinate. RFC 9380 specifies encodings and requires domain separation between independent uses. Implementations need the correct encoding, subgroup handling and constant-time behavior where required. Incompatible domain tags can invalidate signatures even when both implementations use BLS12-381. [6]

Compact signatures reduce signature payload; they do not remove signer bookkeeping, key registration, private-key protection or application-level authorization checks. Pairing computation has costs, and a signature alone does not prove consensus quorum, data availability or correctness of signed data.

Social Media Sentiment

Not applicable to this historical cryptography reference. No current community mood or popularity ranking is inferred from the paper’s technical use.

Last updated: 2026-10

Related Terms

• Ethereum — the network using BLS validator signatures.
• Proof of Stake — consensus based on validator stake.
• Validator — a participant performing consensus duties.

See Also

• MuSig2 — a different approach to producing a joint Schnorr signature.
• Groth16 — pairing-based proofs rather than an aggregate-signature construction.

Sources

1. Boneh, Lynn and Shacham — Short signatures from the Weil pairing. The authors’ publication record identifies the 2001 extended abstract and 2004 journal article.
2. Boneh, Lynn and Shacham — full paper, PostScript. The author-hosted paper is the original short-signature reference; its historical parameters are not modern deployment guidance.
3. Boneh, Gentry, Lynn and Shacham — EUROCRYPT 2003 publication record. This records the later aggregate-signature paper and its applications to certificate chains and routing.
4. Boneh, Gentry, Lynn and Shacham — Aggregate and Verifiably Encrypted Signatures from Bilinear Maps. Sections 3.1–3.2 describe aggregation, verification and the distinct-message defense against rogue keys.
5. CFRG — BLS Signatures, Internet-Draft version 07 (July 2026). The draft specifies variants, basic and augmented schemes, proof of possession and validation requirements; it is not an RFC.
6. RFC 9380 — Hashing to Elliptic Curves (2023). The RFC explains secure hash-to-curve encodings, domain separation and implementation requirements.
7. Ethereum consensus specifications — Phase 0 beacon chain. The specification defines 48-byte public keys, 96-byte signatures, the POP ciphersuite and attestation aggregation.
8. ethereum.org — Keys in proof-of-stake Ethereum. This explains validator signing keys, their distinction from execution-layer keys and withdrawal credentials.