// The Contact Discovery Dilemma
When you install a standard messaging app, the first action it requests is permission to access your device’s contacts. To connect you with your friends, the app uploads your entire address book—including names, phone numbers, and emails—to a centralized database. This process is known as **Contact Discovery**.
While convenient, this model is a privacy disaster. It forces you to hand over highly sensitive corporate networks, professional sources, or private personal associations to a third-party server. Even if *you* refuse to upload your contacts, you can still be compromised if a peer uploads *their* address book containing your number.
For a truly secure, zero-knowledge messaging system, this centralized profiling is unacceptable. We need a way to connect users securely **without the server ever knowing who is looking for whom.** This is the problem solved by **Blind Indexing**.
---
// The Cryptography of Blind Indexing
Blind Indexing is a form of searchable encryption. Instead of storing and searching for user identifiers (like email addresses or usernames) in plain text, the server only stores **cryptographic search hashes**.
When a user registers an account on BlackBox with a username or email, the client-side browser normalizes the input (trimming whitespace and converting to lowercase) and hashes it locally using a strong, salted **SHA-256 algorithm**.
The hash is calculated using a public, platform-wide salt: $$ ext{Search Hash} = ext{SHA-256}( ext{Salt} + ext{Normalized Identifier})$$
The client sends only this one-way, irreversible hash to the server. The server stores this hash in the database database record next to the user's public identity keys.
[User Input: "alice@example.com"]
|
v (Client-Side normalization & SHA-256)
[Hash: e3b0c44298fc1c149afbf4c8996fb...]
|
v (Send over network)
[Server Database] (Stores only the hash, blind to original email)When Bob wants to start a chat with Alice, his browser performs the exact same mathematical hashing locally and queries the server for the resulting hash. The server matches the queried hash in its database and returns Alice’s public identity key.
At no point in this transaction does the server ever see the plaintext email address `alice@example.com` or know that Bob is searching for Alice. The server remains completely blind.
---
// Mitigating brute-force dictionaries
Because SHA-256 is an extremely fast hashing algorithm, a malicious server operator or an external hacker who gains access to the database could try to run a **brute-force dictionary attack** (also known as a rainbow table attack) to reverse the hashes of common email addresses or phone numbers.
To defend against this, BlackBox implements two advanced mitigation strategies:
> 1. Hybrid Blind Indexing For registered accounts with passwords, the blind search hash is generated using a combination of the global platform salt and a user-specific derivation path. This ensures that a single pre-computed rainbow table cannot be used to reverse the entire database.
> 2. Client-Side Cryptographic Rate Limits When searching for user hashes, the lookup endpoint enforces strict IP-based rate limiting. An adversary attempting to harvest the user directory by spamming random hashes is automatically blocked, neutralizing automated dictionary lookup sweeps.
---
// On-Page FAQ: Contact Discovery Security
> Can a database leak expose my email address or username? No. Because the database contains only one-way cryptographic hashes, an external hacker who gains access to the database cannot reverse the hashes back into plaintext email addresses or usernames. They will see only random 64-character hexadecimal strings.
> What happens when I search for a user who does not exist? If you query a hash that does not exist in the database, the server returns a standard `404 Not Found` response. Because of our strict client-side rate limits, you cannot brute-force test millions of variations to map our active user directory.
> Why doesn't BlackBox use mobile phone numbers for user verification? Phone numbers are tied to physical identities, SIM cards, and geographic location records. They are heavily tracked by cellular carriers and government registries. By completely avoiding phone number integration, BlackBox ensures that your E2EE identity is mathematically isolated from your real-world physical identity.
---
// Conclusion: Connecting in the Shadows
Convenience should never demand the sacrifice of your social graph. The networks of human relationships are highly sensitive transactional structures that must be protected with the same defensive rigor as the contents of your messages.
By shifting user discovery from plaintext database queries to client-side blind hashing, BlackBox 1:1 proves that contact discovery and absolute privacy can co-exist, allowing peers to connect securely without leaving a trail of relationships behind.
---