<\/p>\n
ANONYMOUS CREDENTIALS<\/p>\n
A conventional digital signature binds a signer to a message. Verification normally requires the same message that was signed. BBS signatures alter that relationship in a precise way: an issuer signs an ordered collection of messages, and the holder can later prove possession of that signature while revealing only a selected subset.<\/p>\n
The result is often described as selective disclosure. That description is correct, but incomplete. Hiding some signed values does not automatically make two presentations unlinkable. The disclosed values, proof context, revocation mechanism and application protocol can still provide stable points of correlation.<\/p>\n
BBS is therefore best understood as a cryptographic component with unusually useful disclosure properties, not as a complete privacy system.<\/p>\n
The issuer does not sign a document in the abstract. It signs a vector of scalars derived from messages. Each position is associated with a generator, so message order and generator derivation are part of the construction.<\/p>\n
This matters at the application boundary. A JSON object, a CBOR map and a database record have naming and encoding rules that BBS does not define. Before signing, an application must decide which claims become messages, how each value is serialized, which order is canonical and how the schema is identified.<\/p>\n
If two implementations map the same apparent claim to different bytes or positions, they are not signing the same vector. The issue is closely related to the distinction between meaning and signed bytes<\/a>, but BBS adds another layer: the message boundaries themselves affect later disclosure.<\/p>\n A BBS signature has constant size with respect to the number of signed messages. This is attractive when an issuer signs a record containing many independently disclosable fields.<\/p>\n The derived proof is different. It includes responses associated with hidden messages, so its size and verification work depend on the disclosure pattern. Constant-size signatures should not be translated into a claim that every presentation has constant size.<\/p>\n That distinction is operationally relevant for QR codes, contactless channels and constrained devices. A design should measure the exact proof produced by its real message count, ciphersuite and encoding rather than repeat a property of the underlying signature.<\/p>\n The holder does not present the issuer’s original signature. Proof generation randomizes the cryptographic material and creates a zero-knowledge proof of knowledge of a valid signature. Independently generated proofs should not contain a stable representation of that signature.<\/p>\n This removes an important direct correlator. A verifier cannot simply compare the signature bytes from two presentations because those bytes are not exposed.<\/p>\n It does not remove information supplied elsewhere. If every presentation reveals a unique account number, a rare date combination or a stable revocation handle, the application has reintroduced correlation above the proof system.<\/p>\n BBS proves that the disclosed and hidden messages belonged to one valid signed vector. It does not decide whether a requested disclosure is proportionate or whether the disclosed combination is identifying.<\/p>\n Several apparently ordinary fields can form a strong fingerprint when combined. Age band, postal area, qualification and issue month may identify a person in a small population even when name and document number remain hidden.<\/p>\n A privacy analysis therefore needs to consider sets of presentations, not a single proof. The useful question is not only which messages are hidden, but which equivalence class remains after the visible messages are combined with timing, network and verifier data.<\/p>\n The current BBS specification distinguishes material associated with signing from material associated with a particular proof presentation. These inputs allow an application to bind protocol context without turning every contextual value into a selectively disclosable message.<\/p>\n That flexibility needs discipline. Context strings, schema identifiers and verifier challenges need stable encoding and clear semantics. A value that should make a presentation fresh must not be confused with one that merely identifies the application.<\/p>\n A verifier nonce can prevent replay to another session, but a stable verifier identifier can also contribute to linkability. Domain separation prevents protocol confusion; it does not determine the correct privacy policy.<\/p>\n A derived proof demonstrates knowledge of a valid signature and its hidden messages. If the complete credential material can be copied, another device or person may be able to generate the same class of proofs.<\/p>\n Holder binding is therefore an additional design decision. One approach is to include a holder secret among the signed messages and require knowledge of it in every proof. Another is to combine the presentation with an external device-bound key or authentication protocol.<\/p>\n These approaches have different recovery and privacy consequences. A hardware-bound key can make copying harder while creating device migration problems. A stable public key can defeat unlinkability. A secret known to several synchronized devices changes the meaning of possession.<\/p>\n The emerging blind BBS construction allows the prospective holder to commit to selected messages during issuance. The issuer can sign a vector containing those committed messages without learning their values.<\/p>\n This is not the same as selective disclosure. Selective disclosure limits what a verifier learns later. Blind issuance limits what the issuer learns at creation time.<\/p>\n The distinction enables interesting protocols, but also moves responsibility to the issuer’s policy layer. If an issuer must validate a hidden value, the protocol needs a separate proof that the committed message satisfies the relevant condition. Blindness should not be confused with unchecked input.<\/p>\n Some applications need repeated presentations to one verifier to be recognizable while preventing correlation across different verifiers. Current CFRG work on per-verifier linkability adds a scoped pseudonym derived within the BBS proof system.<\/p>\n This is a useful reminder that unlinkability is not binary. A system may choose no linkability, linkability within one relying party, linkability during one session or deliberate global linkability.<\/p>\n The scope must be encoded into the construction and stated in the protocol. A database policy saying that identifiers will not be compared is weaker than a design in which different verifiers receive cryptographically unrelated values.<\/p>\n A signature can remain mathematically valid after the issuer no longer wants the credential accepted. BBS does not prescribe one revocation system.<\/p>\n A unique status URL or index is easy to implement but may become a correlator. Short-lived credentials reduce status checks but increase issuance frequency. Accumulator-based schemes can preserve more privacy while adding witness updates, state and implementation complexity.<\/p>\n The revocation mechanism should be designed with the presentation protocol from the beginning. Adding it later can nullify the privacy properties that motivated BBS.<\/p>\n The specified ciphersuite uses pairing-friendly elliptic-curve groups. Implementations need correct compressed-point decoding, subgroup checks, hash-to-curve operations, scalar handling and pairing evaluation.<\/p>\n These are mature cryptographic techniques, but they are not universally available in secure elements, HSMs or platform APIs. A device may protect an ordinary P-256 or Ed25519 key in hardware while executing a BBS proof entirely in application software.<\/p>\n Performance should be measured at proof generation and verification, including serialization and message-to-scalar processing. The relevant question is not whether the library offers BLS12-381, but whether the complete presentation fits the device, channel and latency budget.<\/p>\n BBS security relies on problems in pairing-friendly elliptic-curve groups. Like other elliptic-curve systems, it is not resistant to a sufficiently capable quantum computer.<\/p>\n That does not make present work irrelevant. It does mean that long-lived credential ecosystems need versioned suites, explicit algorithm identifiers and a migration path. Proof formats, issuer keys and verifier capabilities should not assume that one ciphersuite is permanent.<\/p>\n BBS provides a powerful primitive: one signature over many messages and randomized proofs that disclose only selected positions.<\/p>\n Its privacy value depends on everything around it. Message encoding determines what can be disclosed. Holder binding determines who can present. Challenges determine freshness. Revocation can introduce identifiers. Network and business data can reconnect sessions that the proof itself keeps separate.<\/p>\n Selective disclosure is a cryptographic capability. Unlinkability is a property of the complete system and its repeated use.<\/p>\n BBS signatures support selective disclosure and randomized derived proofs. Unlinkability still depends on disclosed values, proof context, revocation and the surrounding protocol.<\/p>\n","protected":false},"author":2,"featured_media":338,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[10],"tags":[],"nlabs_article_type":[],"class_list":["post-339","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-research"],"_links":{"self":[{"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/posts\/339","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/comments?post=339"}],"version-history":[{"count":1,"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/posts\/339\/revisions"}],"predecessor-version":[{"id":343,"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/posts\/339\/revisions\/343"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/media\/338"}],"wp:attachment":[{"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/media?parent=339"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/categories?post=339"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/tags?post=339"},{"taxonomy":"nlabs_article_type","embeddable":true,"href":"https:\/\/neodata.com.uy\/labs\/wp-json\/wp\/v2\/nlabs_article_type?post=339"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Constant-size signature, variable proof<\/h2>\n
Proof randomization removes one obvious link<\/h2>\n
Disclosure is an application decision<\/h2>\n
Headers are part of the cryptographic context<\/h2>\n
Proof of possession is not holder binding<\/h2>\n
Blind issuance changes who knows the messages<\/h2>\n
Controlled linkability can be a feature<\/h2>\n
Revocation can dominate the privacy model<\/h2>\n
Pairings move the implementation boundary<\/h2>\n
A current scheme with a finite lifetime<\/h2>\n
The privacy property lives in the whole presentation<\/h2>\n
\nReferences<\/h2>\n
\n