Try it Live
Run BLS12-381 examples in the interactive playground
Security Considerations
Security properties and best practices for BLS12-381 implementations.Security Level
Target: 128-bit classical security, 64-bit post-quantum security| Attack | Complexity |
|---|---|
| Discrete log (G1) | ~2^128 |
| Discrete log (G2) | ~2^128 |
| Pairing inversion | Computationally infeasible |
| MOV attack | Prevented (embedding degree 12) |
Known Attack Vectors
Rogue Key Attack
Problem: Adversary can construct malicious public key that causes aggregated signature verification to pass for messages they didn’t sign. Attack:- Honest user has public key
pk₁ - Adversary computes
pk₂ = G1 - pk₁(where G1 is generator) - Aggregated key:
pk₁ + pk₂ = G1 - Adversary can forge signatures for the “aggregate”
Subgroup Attack
Problem: Points not in the correct prime-order subgroup can break security. Mitigation: Always validate points are in the correct subgroup:Invalid Curve Attack
Problem: Accepting points from different curves enables key recovery. Mitigation: Strict point validation before any operation.Side-Channel Resistance
Constant-Time Operations
All operations must be constant-time to prevent timing attacks:Memory Access Patterns
Avoid data-dependent memory access:Implementation Checklist
Point Validation
- Check point is on curve (satisfies curve equation)
- Check point is in prime-order subgroup
- Reject point at infinity where invalid
- Validate encoding format (compressed/uncompressed)
Scalar Validation
- Check scalar is in valid range [0, r-1]
- Reduce scalars modulo curve order
- Handle zero scalar correctly
Signature Validation
- Verify signature is valid G2 point
- Check signature is in correct subgroup
- Validate against correct domain separator
- Reject malformed or oversized inputs
Key Management
- Use cryptographically secure random number generator
- Implement proof of possession for aggregation
- Secure key storage (HSM recommended for validators)
- Key derivation follows EIP-2333
Domain Separation
Always use distinct domain separators to prevent cross-protocol attacks:Aggregation Security
Safe Aggregation Rules
- Same message: Only aggregate signatures over identical messages
- Proof of possession: Require PoP before allowing key in aggregation
- Distinct signers: Ensure no duplicate public keys
- Domain binding: Include domain in signed message
Unsafe Patterns
Library Recommendations
Production Use
BLST (Supranational) - Recommended for production:- Audited by Trail of Bits, NCC Group
- Assembly-optimized
- Constant-time implementation
- Used by all major Ethereum consensus clients
Testing Only
Noble-BLS12-381 - Pure JavaScript for testing:- Not constant-time
- Slower performance
- Useful for test vector generation
Audit History
| Library | Auditor | Date | Findings |
|---|---|---|---|
| BLST | Trail of Bits | 2020 | No critical issues |
| BLST | NCC Group | 2021 | All issues resolved |
| py_ecc | Least Authority | 2020 | Reference implementation |
Related
- BLS12-381 Overview - Curve fundamentals
- Usage Patterns - Implementation patterns
- Performance - Benchmarks

