Understanding Contact-Layer Steganography

What Is Steganography?

Steganography is the art of hiding information in plain sight. Unlike cryptography, which makes a message unreadable, steganography makes the message invisible. The goal isn't to protect the content—it's to hide the fact that content exists at all.

The practice is ancient. Historical examples include:

Invisible Ink

Messages written with lemon juice or milk, invisible until heated. Used since ancient Greece through both World Wars.

Microdots

Photographs shrunk to the size of a period in a sentence. Used extensively in Cold War espionage.

LSB Encoding

Altering the least significant bits of image pixels to embed hidden data. A digital evolution of the same principle.

Classical Digital Steganography

Most digital steganography works by hiding data inside a carrier medium—an image, an audio file, a video. You embed your secret message in the noise floor of a JPEG or the inaudible frequencies of an MP3.

These techniques work, but they have significant limitations:

They require a carrier file. You need to send an image or audio file, which itself may be suspicious in context.
They're detectable with statistical analysis. Steganalysis tools can identify anomalies in file data.
They have limited capacity. You can only hide so much data before the carrier visibly degrades.
They require specialised software. Both sender and receiver need tools to embed and extract.

A New Approach: The Contact Layer

Contact-layer steganography takes a fundamentally different approach. Instead of hiding data inside a file, we hide the communication channel inside a phone contact.

The carrier isn't a file—it's a database everyone already has: your phone's contact list.

A randomly generated phone number, saved as a contact, serves as the derivation seed for an encrypted channel. The steg number IS the carrier. It hides in plain sight among hundreds of other contacts, and it's indistinguishable from any of them.

How It Works Technically

The steg number is a random phone number that serves as a cryptographic derivation seed. From this single number, the client derives everything needed for secure communication:

room_hash

SHA-256(phone + ROOM_SALT)

Unique room identity. The server uses this to route messages without knowing the phone number.

access_hash

SHA-256(phone + PIN + ACCESS_SALT)

Access control. Proves you have the right PIN without revealing it.

enc_key

PBKDF2(phone, room_id + ENC_SALT, 600K)

Encryption key. Derived with 600,000 iterations. Never leaves the browser.

sender_hash

SHA-256(phone + access_hash + room_hash + SENDER_SALT)

Sender identity. Different for each user because their PINs (and thus access_hashes) differ.

Why Phone Numbers?

Universal

Every phone has a contact list. Every person understands phone numbers. No technical barrier to entry.

Unsuspicious

A phone number in a contact list raises zero questions. It's the most ordinary data on any device.

Easy to Exchange

Two people can exchange numbers in person in seconds. No QR codes, no key exchange ceremonies.

Pre-existing Storage

The contact list is a database everyone already maintains. No new app storage to explain.

Sufficient Entropy

E.164 phone numbers provide enough entropy for cryptographic key derivation when combined with salts.

Cross-Platform

Works identically on iOS, Android, and any device with a browser and a contact list.

The Full Derivation Chain

// Step 1: Normalise the phone number
phone = normalise("+1 (555) 012-3456")
        → "+15550123456"

// Step 2: Derive the room identity
room_hash = SHA-256(phone + ":" + ROOM_SALT)
            → "a3f8c2...64 hex chars"

// Step 3: Derive access control (with PIN)
access_hash = SHA-256(phone + ":" + PIN + ":" + ACCESS_SALT)
              → "7b1e4d...64 hex chars"

// Step 4: Derive encryption key (slow, intentionally)
enc_key = PBKDF2(phone, room_id + ENC_SALT, 600000, SHA-256, 256)
          → 256-bit AES key (never transmitted)

// Step 5: Derive sender identity
sender_hash = SHA-256(phone + ":" + access_hash + ":" + room_hash + ":" + SENDER_SALT)
              → "e9a2f1...64 hex chars"

Note that the PIN is not part of the encryption key. Both users need the same key to communicate, but they have different PINs. The PIN is used exclusively for access control via the access_hash. The access_hash IS part of the sender_hash, ensuring two users with the same phone number but different PINs produce different sender identities.

Advantages Over Traditional Approaches

No app to install. Works in any browser. Nothing to download, nothing to appear in your app list.
No account to create. No email, no username, no profile. You generate a number and go.
No metadata trail. The server sees hashes and ciphertext. It cannot correlate rooms with identities.
The hiding place already exists. Your contact list is already on your phone. No new data store to explain.
Plausible deniability. Even if someone finds the sTELgano URL, the blank entry screen reveals nothing.