In 1982, David Chaum published a paper that described a cryptographic operation with no physical analog: signing a document without seeing its contents. The idea was as counterintuitive then as it remains today. A signer – a bank, a government, a certificate authority – produces a valid signature on a message they have never read. The signature is verifiable by anyone. Yet the signer cannot link the signed message to the signing event. They know they signed something, but not what.
Chaum called these “blind signatures” and immediately identified their application: untraceable electronic cash. A bank could sign (authenticate) digital coins without recording which coin went to which customer. When the coin was spent, the bank could verify its own signature but could not determine which withdrawal produced it. The bank knows it issued the coin. The bank cannot trace the coin to the spender.
Forty-four years later, blind signatures remain the core primitive behind anonymous credential systems, privacy-preserving authentication tokens, and the growing ecosystem of digital identity standards that aim to prove attributes (“I am over 18,” “I hold a valid driver’s license”) without revealing identity.
The RSA Blind Signature
Chaum’s original construction uses RSA, and its elegance lies in the multiplicative homomorphism of the RSA function.
Setup
The signer has an RSA key pair: public key (e, N) and private key d, where N = p * q for large primes p, q.
Protocol
- Blinding. The user wants a signature on message m. They choose a random blinding factor r coprime to N and compute the blinded message:
m' = m * r^e mod N
The blinded message m’ is indistinguishable from a random element of Z_N. It reveals nothing about m.
- Signing. The user sends m’ to the signer. The signer computes:
s' = (m')^d mod N = (m * r^e)^d mod N = m^d * r^(ed) mod N = m^d * r mod N
The signer returns s’ to the user. The signer has never seen m.
- Unblinding. The user removes the blinding factor:
s = s' * r^(-1) mod N = m^d * r * r^(-1) mod N = m^d mod N
The result s = m^d mod N is a valid RSA signature on m.
- Verification. Anyone can verify that s^e mod N = m. This is a standard RSA signature verification.
The magic is in step 2: the signer’s RSA operation distributes over the multiplication. The blinding factor r^e commutes through the signing operation and cancels cleanly during unblinding. The signer produces a valid signature on m without any knowledge of m.
Unlinkability
The critical privacy property: the signer cannot link the blinding event (seeing m’ and producing s’) to the verification event (seeing m and s). Even if the signer records every blinding request, they cannot determine which request produced any given signature. The blinding factor r acts as a one-time pad over the multiplicative group, making m’ statistically independent of m.
This is stronger than pseudonymity. It is complete unlinkability between issuance and presentation.
Chaum’s eCash: The First Application
Chaum founded DigiCash in 1990 to commercialize blind-signature-based electronic cash. The protocol:
- The user generates a random serial number S and blinds it.
- The bank signs the blinded value (debiting the user’s account).
- The user unblinds to get a signed coin (S, sigma) where sigma = Sign(S).
- To spend, the user gives (S, sigma) to a merchant.
- The merchant verifies sigma and sends S to the bank for deposit.
- The bank checks that S has not been spent before (preventing double-spending) and credits the merchant.
The bank sees the serial number at deposit time but cannot link it to the withdrawal because of the blinding. The user’s spending is anonymous to the bank.
DigiCash implemented this system with Mark Twain Bank in 1995, processing real transactions. The company went bankrupt in 1998 – not because the cryptography failed, but because the market for digital privacy did not yet exist. The technical architecture, however, was sound. A 2024 retrospective by the International Association for Cryptologic Research noted that Chaum’s eCash protocol had no known cryptographic weakness in over 40 years.
Beyond RSA: Modern Blind Signature Schemes
RSA blind signatures are simple but have limitations: they support only single messages, produce large signatures (2048+ bits for adequate security), and provide no mechanism for selective disclosure.
Schnorr Blind Signatures
Blind signatures based on Schnorr’s identification scheme use elliptic curve groups, producing shorter signatures (64 bytes on Curve25519). The protocol:
- The signer sends a commitment R = k * G (where k is random).
- The user blinds: R’ = R + alpha * G + beta * P (where P is the signer’s public key, alpha and beta are random blinding factors).
- The user computes the challenge: c’ = H(R’ || m).
- The user sends the blinded challenge c = c’ - beta to the signer.
- The signer responds: s = k + c * x (where x is the signer’s private key).
- The user unblinds: s’ = s + alpha.
- The signature on m is (R’, s’), which verifies as s’ * G = R’ + c’ * P.
Schnorr blind signatures are the basis of the Privacy Pass protocol (used by Cloudflare and Apple), which issues anonymous tokens proving a user has passed a CAPTCHA or other verification challenge without tracking which token corresponds to which challenge.
BBS+ Signatures and Anonymous Credentials
BBS+ (Boneh-Boyen-Shacham, extended) signatures enable a qualitatively different capability: signing a vector of messages (m_1, m_2, …, m_n) in a single signature, and later selectively disclosing a subset of messages while proving that the undisclosed messages exist and were signed.
A BBS+ signature on (m_1, …, m_n):
A = (g_1 * g_2^m_1 * g_3^m_2 * ... * g_{n+1}^m_n)^(1/(x + e))
where g_1, …, g_{n+1} are public generators, x is the signer’s private key, and e is a random value.
Selective disclosure: The holder can produce a zero-knowledge proof that A is a valid signature on a set of messages, revealing only a chosen subset. For example, a government issues a credential containing (name, birthdate, nationality, ID_number). The holder can prove to a bar that their birthdate implies age >= 18, without revealing name, nationality, or ID number.
The W3C Verifiable Credentials specification (v2.0, 2024) includes BBS+ as a recommended cryptographic suite for privacy-preserving credentials. The Internet Engineering Task Force (IETF) has an active draft for BBS signatures (draft-irtf-cfrg-bbs-signatures). Microsoft, IBM, and several European digital identity programs are implementing BBS+-based selective disclosure.
Performance
A 2024 benchmark on a standard laptop:
| Operation | RSA (2048-bit) | Schnorr (Curve25519) | BBS+ (BLS12-381) |
|---|---|---|---|
| Blind | 0.5 ms | 0.1 ms | N/A |
| Sign | 2.0 ms | 0.1 ms | 1.5 ms |
| Unblind | 0.5 ms | 0.05 ms | N/A |
| Verify | 0.1 ms | 0.05 ms | 5.0 ms (with proof) |
| Signature size | 256 B | 64 B | 112 B |
| Proof size (selective) | N/A | N/A | ~400 B |
BBS+ verification is slower due to the pairing operations required, but remains well within practical bounds for most applications.
Privacy Pass: Blind Signatures at Scale
Privacy Pass, deployed by Cloudflare since 2017 and integrated into Chrome and Safari, demonstrates blind signatures at internet scale. The protocol:
- A user solves a CAPTCHA (or other challenge) on one website.
- The issuer (Cloudflare) blind-signs a batch of tokens.
- The user unblinds the tokens and stores them.
- When visiting another Cloudflare-protected site, the user presents a token instead of solving another CAPTCHA.
- The site verifies the token with Cloudflare. The token is valid, but Cloudflare cannot link it to the original CAPTCHA-solving event.
Privacy Pass processes hundreds of millions of token redemptions daily. The blinding ensures that Cloudflare cannot build a browsing profile by linking challenge events to redemption events – even though it operates both sides of the protocol.
Apple adopted a similar approach for iCloud Private Relay, using blind signatures to separate the user’s IP address (known to the first relay) from the destination URL (known to the second relay). Neither relay can link the two.
Anonymous Credentials: The Full Framework
Jan Camenisch and Anna Lysyanskaya (CL signatures, 2001-2004) developed the theoretical framework for anonymous credentials:
- Issuance: A credential authority blind-signs a set of attributes (name, age, membership status).
- Presentation: The credential holder produces a zero-knowledge proof that they possess a valid credential satisfying certain predicates (e.g., age > 18) without revealing the credential itself or any non-required attributes.
- Unlinkability: Multiple presentations of the same credential cannot be linked to each other or to the issuance event.
The EU’s European Digital Identity Wallet (expected deployment 2026-2027) includes anonymous credential capabilities, enabling citizens to prove residency, age, or professional qualifications without revealing unnecessary personal data. The technical specification references BBS+ signatures and zero-knowledge proofs as the underlying cryptographic mechanisms.
Limitations and Attacks
One-more-forgery. An adversary who engages in k blind signing sessions should not be able to produce k+1 valid signatures. This property (called “one-more unforgeability”) is harder to prove for some blind signature schemes than standard unforgeability. Schnorr blind signatures have a flawed security proof for one-more unforgeability (the proof in the plain model is incomplete), though no practical attack is known. RSA blind signatures have a standard-model proof.
Denial of service. The blinding protocol requires interaction, and a malicious user can initiate many blinding sessions without completing them, wasting the signer’s resources. Rate limiting and proof-of-work challenges mitigate this.
Credential accumulation. A user who receives many anonymous credentials can stockpile them. If the issuer revokes the user’s access, already-issued credentials remain valid. Revocation requires additional mechanisms – credential revocation lists, short-lived credentials, or accumulator-based revocation – each with privacy tradeoffs.
Quantum threat. RSA and elliptic curve blind signatures are vulnerable to quantum attack via Shor’s algorithm. Lattice-based blind signatures are an active research area, with constructions by Agrawal et al. (2022) and Hauck et al. (2023) providing post-quantum alternatives, though they are not yet practical for deployment.
The Stealth Cloud Perspective
Stealth Cloud’s authentication model – wallet signature via SIWE (Sign-In with Ethereum) – establishes identity at the point of authentication. The server stores a hash of the wallet address, providing pseudonymity but not unlinkability: repeated sessions from the same wallet hash are linkable.
Blind signatures offer a path to unlinkable authentication. Consider a protocol where:
- The user’s wallet signs a challenge, proving they hold a valid wallet.
- A blind signature service issues a credential confirming “this entity holds a valid Ethereum wallet” without recording which wallet.
- The user presents the blind-signed credential to initiate a Ghost Chat session.
- The session cannot be linked to the wallet, to previous sessions, or to the credential issuance event.
This would extend Stealth Cloud’s zero-knowledge guarantee from “the server stores a hash of your identity” to “the server has no information about your identity at all.” The wallet proves authorization. The blind signature strips the proof of its identifying information. The session begins with a clean cryptographic slate.
The technical challenge is the trust model of the blind signing service. In Chaum’s eCash, the bank was the blind signer. In Stealth Cloud’s architecture, the blind signer would need to be either distributed (using threshold cryptography) or operated by a party that the user trusts not to collude with the server. This is a design problem, not a cryptographic one – the primitives are ready.
Chaum demonstrated in 1982 that authentication and identification are separable concerns. Blind signatures are the mechanism. Forty-four years of refinement have made them practical. The question for privacy platforms is no longer “can we do this?” but “when do we deploy it?”