What Is Contact Discovery Privacy? (Zero-Knowledge)
Contact discovery privacy lets an app compare your address book with registered users without sending the service your contacts in plain text. It is usually built with private set intersection or an oblivious pseudorandom function. “Zero-knowledge” is not a blanket guarantee: the protocol, outputs, logs, and abuse controls determine what each party can still learn.
Contact discovery is the feature behind prompts such as “find friends who use this app.” It can be useful, but phone numbers and email addresses are sensitive identifiers. A service that receives a full address book, or a list of simple contact hashes, may expose it to staff, attackers, or later misuse.
The privacy trend is toward cryptographic matching that keeps raw contact values from the service. That is an important improvement, not a reason to skip threat modeling. I assess these systems by asking what each party can infer, including from match results and repeated queries, rather than relying on a broad label.
Planning the Threat Model and Privacy Claims
A threat model states what the client, service, and any attacker or colluding party can see or control. It should name the data each party learns, the risks being addressed, and the limits of the privacy claim. Start here, before selecting a cryptographic protocol.
What should the service learn?
The goal is to let a user discover which contacts are registered without revealing the raw contact list to the service. “Raw” means the actual phone numbers or email addresses, not just readable text. A sound design also asks whether the service learns query size, timing, repeated attempts, or which contacts matched.
Private set intersection (PSI) is a family of protocols that lets parties compare sets while limiting what they reveal. In common contact-discovery designs, a client learns the intersection: the registered contacts from its own list. That result is still sensitive. A person could use it to learn who has an account, so the design must consider how much matching output is disclosed and to whom.
An oblivious pseudorandom function (OPRF) lets a client obtain a pseudorandom function result for an input without directly revealing that input to the server, under the protocol’s stated assumptions. It is a cryptographic building block, not by itself a complete contact-discovery system. The surrounding message flow and output handling matter.
When is “zero-knowledge” accurate?
Zero-knowledge has a specific meaning in cryptography: a prover convinces a verifier that a statement is true without revealing more than the statement itself. A PSI or OPRF design is not automatically a zero-knowledge proof system. Use the term only if the design uses a specific, reviewed zero-knowledge proof and explains what that proof establishes.
RFC 9497 defines OPRF, VOPRF, and POPRF protocols. It does not define a full contact-discovery service or promise that a server learns nothing. RFC 9380 specifies hash-to-curve methods that some compatible cryptographic constructions may use. It is not a contact-discovery protocol either. Implementations must use the exact ciphersuite and encoding required by their selected protocol.
A useful privacy statement is specific: “The protocol is designed to hide submitted contact values from the service, but the service may observe request timing and volume; the user receives matching contacts.” That wording is more informative than an unsupported claim of total secrecy.
Contact Normalization, Permissions, and Data Boundaries
Normalization converts contact details to a consistent form before comparison. Permissions and data boundaries define what the app may read, process, transmit, retain, or delete. These steps are not cryptography, but errors here can defeat a well-chosen protocol or create unnecessary exposure.
Normalize consistently, then minimize
Phone numbers need a consistent representation for matching. ITU-T E.164 is the international numbering plan, not a privacy protocol; formatting and country context still need careful handling. The client and service must agree on the input encoding and normalization rules. Otherwise, equivalent numbers may fail to match, or different inputs may be treated inconsistently.
Normalization does not prove that a number belongs to the user or to a contact. Ownership checks, such as a separate verification step, answer a different question. Do not treat a correctly formatted number as verified identity.
For email, document the rules used for case, whitespace, and other transformations. Avoid applying provider-specific assumptions unless the service has a verified reason to do so. Any canonicalization rule should be consistent, testable, and versioned, because changing it can alter matches.
Obtain explicit permission before reading contacts, explain the feature, and process them on-device where possible. Transmit no plaintext address book. Do not send a simple unsalted hash of phone numbers or email addresses: these values are often guessable, so an attacker can hash likely candidates and compare them.
| Design choice | What it can protect | What it does not establish |
|---|---|---|
| Encrypted transport | Data from some network observers in transit | That the service cannot read received data |
| Simple unsalted hash | May hide values from casual viewing | Protection against guessing common numbers or emails |
| OPRF or PSI | Input privacy defined by the chosen protocol | No leakage of query patterns or match results |
| On-device processing | Reduces data sent to the service | That the device, app, or local account is secure |
These are different controls, not substitutes for one another. The privacy claim should describe the complete path from address-book permission to deletion, not only the cryptographic exchange.
Implementing PSI or OPRF Safely
Safe implementation means choosing a reviewed protocol, defining all inputs and outputs, and following its exact specifications. A cryptographic library does not settle product questions such as who sees matches, how often a user may query, or how long logs remain. Document those choices alongside protocol assumptions.
A practical implementation sequence
Define the threat model. Record what the client, service, and any colluding or compromised parties may learn. State whether the service may see query volume, repeated queries, timing, or results. Include risks from compromised accounts and malicious clients.
Select a reviewed protocol and ciphersuite. Decide whether the use case calls for PSI or an OPRF-based design. Record input encoding, normalization, key management, protocol version, and security assumptions. If the construction uses hash-to-curve, use the exact compatible method and ciphersuite; RFC 9380 alone does not select one for you.
Limit exposure. Request permission, process contacts locally when feasible, and send no plaintext address book. Define abuse controls and retention based on the threat model. Do not assume that an encrypted connection makes server-side data invisible.
Review and test the whole system. Arrange independent cryptographic review, then test the application, service, logs, and deletion path. Check enumeration, replay, account correlation, malformed inputs, analytics leakage, and behavior after deletion.
Illustrative deployment scenarios
These are design examples, not claims about named products or measured deployments. In a small messaging app, a client might use a reviewed PSI design and receive only its matches. The team would still need to limit repeated lookups and prevent result data from appearing in analytics or support logs.
In a larger service, the same feature may face many automated clients and a higher risk of enumeration. The team would need to consider query patterns, account correlation, and operational monitoring as well as cryptographic input privacy. More users do not change the protocol’s guarantees, but they can change the likely abuse and the controls needed.
I treat these as separate engineering cases because “the server cannot read the address book” does not answer whether it can infer a person’s social links from results, timing, or repeated attempts.
Verifying Leakage, Abuse Controls, and Deletion
Verification checks whether the system’s actual behavior matches its documented privacy claim. Test not only the cryptographic exchange, but also client permissions, service logs, analytics, rate controls, and data deletion. There is no universal RFC-specified query limit or retention period for contact discovery.
What to test before release
Use a written test plan with clear pass or fail conditions. For example, a pass condition may be that no plaintext contact value appears in network captures, application logs, analytics, or crash reports. Another may require that a deleted account’s retained contact-discovery data is removed according to the documented deletion process. These are project requirements, not universal protocol thresholds.
Test these failure paths:
- Enumeration: Can a client submit large or targeted sets to infer registered users? Check whether controls limit abuse and whether an attacker can evade them by creating accounts.
- Replay: Can a captured or repeated request produce extra information or bypass intended limits?
- Correlation: Can the service link a user’s queries over time or across accounts through identifiers, timing, or logs?
- Malformed inputs: Do invalid encodings, duplicate entries, or unexpected lengths cause unsafe behavior or inconsistent matches?
- Logging and analytics: Do request details, match outputs, or diagnostic events expose information outside the protocol?
- Deletion: Do documented deletion rules cover logs, cached data, backups, and downstream systems where applicable?
Set query limits, monitoring, and retention from the threat model. Rate limits can make enumeration harder, but they do not erase information already revealed by a match result or repeated guesses. State the chosen limits and rationale in the system documentation, and review them as usage and abuse patterns change.
What a defensible privacy claim includes
A clear claim names the protocol and version, explains what input is hidden from which party, and identifies known leakage. It should also describe what the client receives, what request metadata the service sees, and the rules for retention and deletion.
Avoid statements such as “zero-knowledge means the server learns nothing.” An OPRF, PSI, or encrypted transport alone does not support that claim. A stronger and more honest statement names the exact guarantees and the remaining limits.
Frequently Asked Questions
Is contact discovery privacy the same as hiding my address book?
Not exactly. A protocol may hide raw contact values from the service, while still revealing request volume, timing, or which contacts matched. The full system determines the privacy outcome.
Does OPRF mean the server cannot learn anything?
No. RFC 9497 defines OPRF-related protocols, but it does not guarantee zero leakage for a complete contact-discovery service. Review outputs, metadata, and implementation.
Is PSI always zero-knowledge?
No. PSI lets parties compare sets under defined privacy guarantees. It may reveal the intersection to one party, and that result can be sensitive.
Why are unsalted contact hashes unsafe?
Phone numbers and email addresses are often drawn from guessable ranges or public sources. An attacker can hash likely values and compare them with exposed hashes.
Does E.164 verify a phone number?
No. E.164 is an international numbering plan. Formatting a number consistently does not prove that a person owns or controls it.
Does encryption in transit protect contacts from the service?
It protects data from some observers while it travels. The service can still access data it receives unless the protocol and system design prevent that access.
Are there standard query limits or retention periods?
No universal RFC specifies them for contact discovery. Set limits and retention rules from a documented threat model, legal duties, operational needs, and abuse risk.
What should an audit examine?
It should examine the cryptographic protocol and implementation, input handling, enumeration and replay risks, account correlation, logs and analytics, abuse controls, and deletion behavior.
The practical standard is not a reassuring label; it is a documented and tested leakage profile. Choose a reviewed PSI or OPRF design, minimize data at the source, and make every privacy claim match what the system can prove.
(This article was written by one of our staff writers, Garrett Vance. Visit our Meet the Team page.)
