Path: blob/main/frontier/07-pairings/break/rogue-key-attack-bls.ipynb
483 views
Break: Rogue Key Attack on Naive BLS Aggregation
Module 07 | Breaking Weak Parameters
Craft a malicious public key that lets you forge an aggregate BLS signature.
Why This Matters
BLS signature aggregation is one of the most powerful features of pairing-based cryptography. In the same-message setting, signatures compress into a single curve point, verified with just 2 pairings:
But there is a critical vulnerability: if public keys are not validated, an attacker can construct a rogue key that cancels out all other signers' public keys. This lets the attacker forge an aggregate signature without any honest signer's participation.
This attack was identified by Micali, Ohta, and Reyzin (2001) and is the reason Ethereum 2.0 requires proof of possession during validator registration.
The Scenario
Alice is an honest validator with key pair .
Mallory wants to forge an aggregate signature that appears to come from both Alice and Mallory, even though Alice never signed the message. Mallory's strategy:
Observe Alice's public key .
Choose a secret and set her "public key" to .
The aggregate public key becomes .
Mallory can now sign alone using and produce a valid aggregate signature.
Your job: carry out this attack step by step on a toy curve and verify it works.
Step 2: Alice Signs Honestly, Mallory Constructs the Rogue Key
Alice generates a legitimate key pair and signs a message. Meanwhile, Mallory observes Alice's public key and constructs a rogue public key designed to cancel it out.
Step 3: Mallory Forges the Aggregate Signature
In same-message BLS aggregation, verification checks:
Since , Mallory computes . This satisfies the equation because:
Alice never signed this message!
The Fix: Proof of Possession (PoP)
The defense is simple: before accepting any public key into the aggregation set, require the owner to prove they know the corresponding secret key.
Proof of Possession: each signer produces , where is a hash function distinct from the message hash .
Verification of PoP: check .
Mallory cannot produce a valid PoP for her rogue key because she does not know the discrete log of with respect to .
Exercise: Rogue Key with 3 Signers
Extend the attack to 3 signers. Alice and Bob have honest keys. Mallory constructs:
Set up honest keys for Alice and Bob.
Construct Mallory's rogue key that cancels both.
Forge an aggregate signature that "verifies" for all three.
Confirm that PoP blocks the attack.
Summary
| Aspect | Detail |
|---|---|
| Attack | Rogue key: makes aggregate pk controlled by Mallory |
| Impact | Mallory forges aggregate signatures without other signers' participation |
| Root cause | Naive aggregation does not verify that signers know their secret keys |
| Fix | Proof of Possession (PoP): sign your own public key to prove key knowledge |
| Real world | Ethereum 2.0 requires PoP at validator registration (EIP-2333/2334) |
Key takeaway: aggregation is not free, it requires careful key validation. The pairing equation is mathematically correct, but cryptographic security requires protocol-level defenses beyond the raw math.
Back to Module 07: Bilinear Pairings