BBS+ Signatures

What's distinctive

A BBS+ signature is over a vector of messages, not a single byte string. Given a signature on (m_1, m_2, …, m_L):

• The holder can derive a presentation that reveals any subset D ⊂ {1, …, L} and proves the rest exist without disclosing them.
• The verifier learns the disclosed messages, the public key of the issuer, and a zero-knowledge proof that an issuer-signed vector satisfies the predicate.
• The verifier learns nothing about the unrevealed messages beyond what the disclosed ones imply.
• The current BBS draft has 80-byte signatures over BLS12-381. The BBS+ construction shown below has one G1 point and two scalars, totaling 112 bytes.

This is the cryptographic backbone of "show me your driver's license but only the over-21 bit and your photo, nothing else" — the mDL / EU Digital Identity Wallet pattern.

Origin and naming

• BBS (Boneh, Boyen, Shacham), Short Group Signatures, CRYPTO 2004 — the underlying short signature.
• BBS+ (Au, Susilo, Mu, Constant-Size Dynamic k-TAA, SCN 2006; Camenisch and Lysyanskaya developed the credential-system framing in CL signatures, with BBS+ as a successor) — extends BBS to a vector of messages with efficient zero-knowledge proof of knowledge.
• The signing equation, in BLS12-381 notation:

σ = (A, e, s) where A = (g_1 · h_0^s · h_1^{m_1} · … · h_L^{m_L})^{1/(x + e)}

with x the issuer's secret key, e and s per-signature randomness, and h_0, …, h_L public generators. Verification uses a pairing equation; possession can be proven in zero knowledge via a Schnorr-style sigma protocol.

What you can do with a BBS+ signature

The unlinkability is the headline. With a conventional X.509 certificate or a JWT, every presentation is bit-identical and trivially linkable; BBS+ presentations are freshly randomized every time.

IETF standardization

The CFRG track:

• draft-irtf-cfrg-bbs-signatures (initially submitted 2022 by Looker, Lodder, Kalos, Whitehead and others). Active as of 2026.
• Defines BBS over BLS12-381, with hash-to-curve per RFC 9380.
• Specifies signing, deterministic verification, proof generation (the ZK presentation), and proof verification.
• A separate BBS Blind Signatures draft adds blind issuance — issuer signs without seeing the messages.
• A Pseudonyms with BBS draft adds verifier-binding for sybil control without compromising cross-verifier unlinkability.

The drafts have iterated several times — implementers should pin to a specific draft revision.

Cipher suites in the draft

Both fix the curve and message-encoding to BLS12-381 G1 for the disclosed-attribute side. Selecting BLS12-381 ties BBS+ deployments to the same curve as Ethereum's BLS aggregate signatures and Filecoin / Zcash, which simplifies tooling.

Production and pilot deployments

Hyperledger AnonCreds

The published AnonCreds v1 specification uses CL signatures and revocation accumulators. Its properties should not be attributed to a deployed BBS+ replacement.

W3C Verifiable Credentials with BBS+

The W3C VC Data Model is signature-agnostic. A BBS+-signed VC profile lets the holder derive a redacted VC for each verifier. Reference work and demos by the DIF (Decentralized Identity Foundation) and MATTR.

BBS+ vs SD-JWT

The two compete head-to-head for selective-disclosure credentials.

BBS+ vs CL signatures

CL (Camenisch-Lysyanskaya) signatures predate BBS+ and were the original choice in AnonCreds 1.0. BBS+ is preferred now because:

• Smaller signatures (single curve point vs RSA-large).
• Faster verification on modern hardware.
• Cleaner integration with BLS-curve tooling (no separate RSA setup).

CL is still in older AnonCreds deployments and in some legacy academic credential systems.

Aggregation and threshold

The BBS draft specifies signatures and selective-disclosure proofs. It does not define general issuer-signature aggregation or threshold issuance. Multi-issuer or threshold constructions require additional protocols and security analysis.

Trade-offs

Strengths

• Unlinkable presentations across verifiers.
• Selective disclosure without trusted hardware.
• Compact signatures and proofs.
• Composable with predicate proofs (range, equality, set membership).

Limitations

• Pairing-based — broken by quantum. No drop-in PQ replacement; lattice-based selective-disclosure schemes (e.g., LaBRADOR-derived constructions, BBS-inspired lattice variants) are research-stage with much larger artifacts.
• Implementation maturity. Fewer production-grade libraries than SD-JWT. Reference implementations exist in Rust (pairing-crypto, bbs), TypeScript (@mattrglobal/bbs-signatures), and Go.
• Side-channel surface. Pairing arithmetic is delicate; constant-time pairing implementations are not as ubiquitous as constant-time elliptic-curve code.
• Revocation. BBS+ alone does not provide revocation; it must be paired with an accumulator (see Authenticated Data Structures) or a status list (StatusList2021).
• Issuer compromise. A leaked issuer key forges all credentials; revocation/rotation strategies are critical.

Pitfalls

• Don't reuse domain separators. The hash-to-scalar and hash-to-curve domain tags are part of the cipher suite — mixing suites breaks unlinkability and security.
• Don't expose e or s. They are per-signature randomness; revealing them links the presentation to the original signature.
• Pin draft versions. The CFRG draft has changed parameter encodings between revisions.
• Watch unlinkability scope. Network metadata (TLS session, IP) trivially de-anonymizes BBS+ presentations. Use Tor / mixnets for full unlinkability across verifiers.

Primary sources

• Anonymous Attestation Using the Strong Diffie Hellman Assumption Revisited
• Revisiting BBS Signatures
• CFRG: The BBS Signature Scheme
• W3C Verifiable Credentials Data Model v2.0
• AnonCreds specification
• RFC 9901: Selective Disclosure for JSON Web Tokens
• W3C BBS cryptosuite
• Short Group Signatures
• Constant-Size Dynamic $k$-TAA
• BBS Pseudonyms

Also in Identity, Social and Trust