BLS signature aggregation enables thousands of signers to produce a single compact signature, a major efficiency gain for consensus protocols, threshold wallets, and multi-party custody systems. However, this same property creates a vulnerability: if public keys are summed without verification, a late registrant can craft a key that cancels out honest signers' contributions, forging group approval with a single signature.

Introduction

BLS signature aggregation allows many signers to produce a single compact signature, a major efficiency gain for consensus protocols, threshold wallets, and multi-party custody systems. However, this very property creates a vulnerability: if public keys are summed without verification, a late registrant can craft a key that cancels out honest signers' contributions, forging group approval with a single signature. This post explains how the attack works, why it matters, and how to prevent it.

What Happened

An apartment-building analogy illustrates the risk. A fund requires three executives to approve every withdrawal. The bank stores a single total instead of three separate checks. If the last executive sees the first two's numbers, they can pick a value that wipes the others out entirely. In BLS, the identical arithmetic applies: Oscar can register a rogue key R = X - F - C, where X is his valid public key and F, C are Frank's and Carol's. The aggregate becomes his target, and he signs alone. The math holds on real elliptic curves, as demonstrated with a Python BLS library - the aggregate signature verifies without complaint.

Why This Matters

The vulnerability extends beyond BLS; Schnorr-based systems face identical risks when key aggregation is implemented carelessly. Real-world deployments have learned this lesson, and the fixes outlined here are now standard practice in production-grade cryptography. A single unchecked key can undermine the entire assurance model, making it essential to build defenses into the foundation.

Key Takeaways

  • Proof of possession is the first line of defense. Before a key enters the aggregation pool, its owner must sign the key itself. A validator can cache that result and safely aggregate thereafter, with negligible performance cost.
  • Distinct messages prevent cancellation. If each signer uses a unique message - such as their public key prepended to the original message - the attack loses its mathematical footing.
  • Key coefficients derived from hashing the entire group assign unique weights to each participant. Because the weights depend on all keys including the potential attacker's, any attempt to cancel others also changes the attacker's own weight, making the target impossible to hit.
  • Key validation must never be skipped. Public keys should always be checked for the identity point and correct subgroup membership, preventing malformed or malicious entries from entering the system.
  • Aggregation proofs confirm group signing, not member identity. If your system needs to know who signed, carry a participation bitfield alongside the signature.

Conclusion

Adding public keys together isn't the mistake - the mistake is adding them without verifying each participant can actually use their key. The rogue-key attack exploits exactly that gap: a last-registrant sees everyone else's numbers and picks one that makes the group total work in their favor. The good news is that proven defenses exist, and they're cheap to implement when baked into the registration flow. If your system ever adds keys together, the question to ask is simple: what stops a participant from registering a key built by subtracting everyone else's? If the answer is nothing, an attacker already has the blueprint.