A selective proof is not automatically smaller.

9 min read

When attributes require independent signatures, BBS can replace N signatures with one multi-message signature, but its selective-disclosure proof grows with every hidden message. The useful crossover depends on what the comparison actually carries.

A multi-message signature compresses issuance. A selective-disclosure proof does something different. It replaces the original signature with a proof whose size increases with every message kept hidden.

That distinction is easy to lose in a product comparison. An 80-byte BBS signature is smaller than a concatenation of many 64-byte Ed25519 signatures. The corresponding BBS presentation is not 80 bytes, however. Under the BLS12-381 ciphersuites in the January 2026 CFRG draft, its cryptographic proof is $272 + 32 U$ bytes, where $U$ is the number of undisclosed messages. The disclosed values, their positions, the issuer key reference and the protocol envelope remain outside that number.

Whether BBS is smaller depends on the stage, baseline and number of messages revealed.

Compare objects with the same job

Let:

$N$ be the total number of independently addressable attributes.
$R$ be the number disclosed to a verifier.
$U = N - R$ be the number kept undisclosed.
$M_{D}$ be the encoded bytes of disclosed messages.
$M_{H}$ be the encoded bytes of hidden messages.
$E$ be everything outside the primitive, including identifiers, indexes, lengths, freshness values and framing.

Three common objects answer different questions:

Object	Cryptographic bytes	What it permits
$N$ Ed25519 signatures	$64 N$	Each attribute can be verified independently if each signed message contains sufficient context
One CFRG BBS signature	80	One issuer signature authenticates the complete vector of $N$ messages
One CFRG BBS disclosure proof	$272 + 32 U$	A holder proves possession of a signature while revealing $R$ messages and hiding $U$ messages

The Ed25519 values are fixed by RFC 8032: a public key is 32 bytes and a signature is the concatenation of two 32-byte values. The BBS draft defines a signature as one compressed G1 point and one scalar. Its BLS12-381 ciphersuites encode those as 48 and 32 bytes, giving 80 bytes.

The same draft defines a disclosure proof as three G1 points, four fixed scalars and one response scalar for every undisclosed message. That gives:

$P_{B B S} (U) = 3 (48) + (4 + U) (32) = 272 + 32 U$

The BBS public key is a compressed G2 point, or 96 bytes. It is not part of the primitive signature or proof. The verifier still has to receive it, resolve it by identifier or retrieve it from a trusted cache.

Terminology matters. The CFRG draft calls the construction BBS and serializes a signature as $(A, e)$ . Legacy BBS+ encodings can have different components and cannot inherit these figures without demonstrating the same structure.

Issuance crosses over almost immediately

At issuance, assume that all $N$ message bytes travel in either design and that the verifier or holder already has the issuer public key. Ignoring envelope differences:

$B_{E d, i s s u e} = M_{D} + M_{H} + 64 N$

$B_{B B S, i s s u e} = M_{D} + M_{H} + 80$

BBS has the smaller signature component for $N \geq 2$ .

Signed attributes $N$	Concatenated Ed25519 signatures	One BBS signature	Ed25519 minus BBS
1	64 B	80 B	-16 B
2	128 B	80 B	48 B
5	320 B	80 B	240 B
10	640 B	80 B	560 B
20	1,280 B	80 B	1,200 B

If each object must carry its public key, the totals become $32 + 64 N$ for Ed25519 and $96 + 80 = 176$ bytes for BBS. The crossover then moves to $N \geq 3$ . In a provisioned verifier, that difference normally disappears because a key identifier is carried instead of the key itself.

Ordinary Ed25519 can also sign one canonical vector with one 64-byte signature. Independent signatures are justified only when attributes must be separable, independently updated or independently presented.

Presentation reverses the size driver

Suppose the Ed25519 design really does sign each attribute independently. A holder can disclose $R$ attribute-signature pairs and omit the rest. With cached issuer keys and equal envelopes:

$B_{E d, p r e s e n t} = M_{D} + 64 R$

$B_{B B S, p r e s e n t} = M_{D} + 272 + 32 U$

The disclosed message bytes cancel. BBS is smaller only when:

$272 + 32 (N - R) < 64 R$

$R > \frac{N + 8.5}{3}$

BBS grows with hidden messages. Concatenated Ed25519 grows with disclosed messages. Even with $U = 0$ , the BBS proof remains 272 bytes. It first beats the all-disclosed Ed25519 baseline at $N = R = 5$ : 272 bytes against 320.

$N$ total	$R$ disclosed	$U$ hidden	BBS proof	Ed25519 signatures	Smaller primitive
8	2	6	464 B	128 B	Ed25519 by 336 B
8	6	2	336 B	384 B	BBS by 48 B
12	4	8	528 B	256 B	Ed25519 by 272 B
12	7	5	432 B	448 B	BBS by 16 B
20	5	15	752 B	320 B	Ed25519 by 432 B
20	10	10	592 B	640 B	BBS by 48 B

If the public key must travel with each presentation, BBS pays 96 bytes and Ed25519 pays 32. The condition becomes:

$R > \frac{N + 10.5}{3}$

That key difference can reverse a close result, so trust provisioning should be separated from presentation transport.

A single vector signature creates another crossover

A compact Ed25519 design signs one canonical vector. A verifier cannot validate a subset unless the complete vector is supplied or another disclosure construction is added.

For an offline presentation that carries the full vector, compare:

$B_{E d, v e c t o r} = M_{D} + M_{H} + 64 + E_{E d}$

$B_{B B S, p r e s e n t} = M_{D} + 272 + 32 U + E_{B B S}$

BBS saves bytes when:

$M_{H} > 208 + 32 U + (E_{B B S} - E_{E d})$

With five hidden messages and equal envelopes, the omitted encoded values must total more than 368 bytes. That is an average above 73.6 bytes per hidden message. Five 96-byte values total 480 bytes, so the BBS presentation saves 112 bytes at the primitive-plus-message layer. Five 20-byte values total 100 bytes, so the BBS presentation costs 268 bytes more.

Encoded length matters more than attribute count. Hiding a portrait or address can repay the proof overhead. Hiding five one-byte flags cannot.

The envelope can decide the result

The preceding equations deliberately isolate primitives. A field protocol carries more.

Consider the $N = 12$ , $R = 7$ , $U = 5$ row. Assume seven disclosed values average 24 bytes and a compact binary envelope uses 45 bytes for version, algorithm, key identifier, nonce, counts, indexes, lengths and framing.

Component	BBS presentation	Independent Ed25519 presentation
Disclosed messages	168 B	168 B
Proof or signatures	432 B	448 B
Assumed envelope	45 B	45 B
Total with cached key	645 B	661 B
Public key if included	96 B	32 B
Total with public key	741 B	693 B

The 16-byte BBS advantage becomes a 48-byte disadvantage when both keys are included. These are accounting examples, not benchmarks.

Text encoding adds another layer. Base64url without padding represents 432 proof bytes in 576 characters. It represents 448 concatenated Ed25519 signature bytes in 598 characters. JSON property names, quotes and structural data then add more.

The W3C bbs-2023 cryptosuite demonstrates why a primitive constant is not a credential size. Its derived proofValue includes the proof, a compressed label map, indexes and a presentation header. It CBOR-encodes the components, adds a three-byte header, then uses multibase base64url without padding. The disclosed JSON-LD document travels beside it. The reliable wire budget is the final serialized presentation.

Privacy is not reducible to bytes

Independent Ed25519 signatures support selective transmission, but stable signature bytes can become correlation handles. Signing true or Engineer is unsafe unless the message binds the issuer, subject, attribute name, schema version, validity and domain. Repeating that context increases $M_{D}$ or $E_{E d}$ .

BBS proofs are randomized and designed to be unlinkable at the cryptographic layer. That property is a reason to select BBS even when its proof is larger. It does not make the complete interaction unlinkable. Disclosed high-entropy values, a reused presentation header, network metadata or a distinctive document structure can still correlate presentations.

The proof length itself also reveals information. Because it grows by 32 bytes per hidden message, a verifier can infer the number of undisclosed messages when it knows the disclosed count. The CFRG draft recommends common-length padding where this leakage matters. Each hidden padding message adds another 32-byte response, so privacy padding has a measurable transport cost.

A verifier challenge belongs in the presentation header when replay resistance is required. The draft recommends a verifier-supplied random value for most uses. That nonce is protocol data, not part of the $272 + 32 U$ proof formula, even though it is cryptographically bound to the proof.

Pin the specification before implementation

The formulas use draft-irtf-cfrg-bbs-signatures-10, published in January 2026 and expired in July. It is not an RFC. The W3C BBS cryptosuite was a Candidate Recommendation Draft on 2 September 2026 and still cites draft version -05. The relevant primitive structures match here, but both documents remain work in progress.

A production profile should pin the draft version, ciphersuite, point encoding, message-to-scalar procedure and credential format. A claim of “BBS+ support” is not an interoperable format definition.

BBS is also not post-quantum secure. Its selective-disclosure and unlinkability properties do not change the discrete-logarithm security assumption behind signature unforgeability.

The practical conclusion

BBS compresses a vector of independently signed attributes decisively at issuance. For presentations, its proof is smaller than concatenated Ed25519 signatures only after the revealed subset crosses a calculable threshold. Against one Ed25519 signature over a complete vector, BBS becomes smaller only when the bytes omitted from the vector repay the fixed proof overhead and the per-hidden-message responses.

The decision should therefore record five numbers: $N$ , $R$ , $M_{D}$ , $M_{H}$ and the exact serialized envelope. It should also record the property being purchased. If independent signatures already provide the required disclosure model and correlation is acceptable, Ed25519 may use fewer bytes. If holder-generated selective disclosure and cryptographic unlinkability are requirements, BBS can be the correct design even on the other side of the byte crossover.

Context and scope

This analysis abstracts a commissioned comparison of credential payload structures. The commissioning organisation, credential schema, deployment geography and operational measurements are intentionally omitted. All example totals are calculations from stated inputs, not observations from an unidentified production system.