Signal Without Phone Numbers: Who Gets to Join?

Key takeaways

• Hiding your phone number from contacts is different from never providing one at registration.
• Zero-knowledge proofs can verify a registration credential without revealing its underlying personal information.
• Preventing credential reuse does not stop someone from obtaining many different credentials.
• Private registration still needs message limits, recipient protections, and separate safeguards for connection metadata.

Imagine joining Signal without handing over your phone number. The privacy appeal is clear, but so is the challenge: what stops someone from creating accounts by the thousand? In this hypothetical design, cryptography could protect your registration details while leaving some difficult decisions about who gets in.

A phone number does two different jobs

Keeping your number hidden from other users is a question of disclosure. Removing it from registration changes how the service decides to admit accounts.

Phone verification establishes something fairly narrow: you can receive a message or call at that number. If acquiring more numbers takes money or effort, that friction can also make mass account creation harder.

It does not establish one person, one account. People can have multiple numbers.

Still, removing that step means deciding what will replace its resistance to abuse. Deleting the input field is a product change. Designing the admission system behind it is the harder work.

Prove you qualify without revealing why

A zero-knowledge proof lets someone demonstrate that a claim is true without disclosing the secret information supporting it. For messenger registration, the claim might be simple: “I hold a valid credential that lets me join.”

Consider a hypothetical setup. A trusted issuer gives you a registration credential. You then submit a proof of its validity to the messenger, which can check your eligibility without receiving the personal identifying information behind it.

That still leaves an obvious loophole: using the same credential repeatedly.

A system can address this with a nullifier, a tag used to detect reuse. The same credential produces the same tag when used to register with the same service. The server checks whether it has seen that tag before and rejects a second registration.

This lets the service enforce one registration per credential without directly identifying its holder.

The tag’s scope matters, though. Reusing the same tag across multiple services could give those services a way to connect someone’s activity. A privacy-preserving design needs to define where that tag remains consistent.

The hard part is issuing the credentials

Suppose an attacker obtains 1,000 credentials. That is an illustrative number, but the loophole is real: the attacker can use each credential once without triggering a duplicate-use check.

This is the Sybil attack problem—one actor creating multiple accounts that appear to be separate participants.

A zero-knowledge proof can establish that a submitted credential meets the system’s rules. How many credentials one person can acquire depends on the issuing system.

So the issuer needs an answer to two questions: who qualifies, and how many credentials can they receive?

One possible design would have an issuer verify a phone number and then provide an anonymous credential. The messenger would no longer need to receive the number itself. The user would still have to give it to the issuer.

That would reduce disclosure to the messenger, but it would not eliminate phone numbers from the process.

If the goal is registration without submitting a number anywhere, another eligibility rule is needed. Its usefulness depends on how hard it makes bulk acquisition—and how much difficulty it creates for ordinary users trying to join.

Getting an account should not mean unlimited access to inboxes

Even a legitimately registered account can send unwanted messages. Controlling sign-ups addresses only one stage of abuse.

A messenger also needs controls on sending and tools for recipients. Possible protections include message limits, a request inbox for unfamiliar senders, and blocking.

Privacy-preserving usage limits are another design option. For example, a system could give each valid credential a fixed daily allowance of sending tokens.

But that system would still need to prevent users from claiming extra allowances or spending the same token twice. Adding a zero-knowledge proof does not implement those controls automatically.

There is a separate privacy boundary, too. Protecting registration credentials does not automatically conceal a user’s IP address or the timing of their connections. Private registration and anonymity across the whole service require different protections.

Zero-knowledge proofs could let a messenger ask for less personal information while still checking eligibility. Making that work would require credential issuance, reuse prevention, and message controls to fit together. The real design choice is how much cost and inconvenience users should bear to keep registration private and their inboxes usable.