Security — sTELgano

Our Promise

Your messages are encrypted on your device before they ever leave your browser. The server never sees your phone number, your PIN, or the content of your messages. It only receives opaque hashes and ciphertext that are meaningless without your credentials.

There are no accounts to create, no email addresses to provide, and no profile data to fill in. You share a number with someone, each of you picks a PIN, and that is the entire setup. We built sTELgano on a zero-knowledge architecture: we cannot read your messages, we cannot identify you, and we cannot recover your data. That is not a limitation — it is the design.

No metadata is collected. No chat history is retained. No message logs exist on the server. When a reply is sent, the previous message is atomically deleted. At most one message exists in any room at any time.

How Encryption Works

Derivation Chain

Every piece of data the server stores is derived from your shared number and PIN through a series of one-way cryptographic functions. Here is what happens when you enter your credentials:

Your phone number is normalised to E.164 format — spaces, dashes, and formatting are stripped.
A room hash is computed so the server can look up your room without knowing your number.
An access hash is computed from your number and PIN — this proves you know the PIN without revealing it.
An encryption key is derived using 600,000 rounds of PBKDF2 — this key never leaves your browser.
A sender hash is computed so the server can tell which participant sent a message, without knowing who they are.

phone       = normalise(phone_number)
            // Strip spaces, dashes, formatting → E.164 standard

# Server-side identifiers (opaque hashes)
room_hash   = SHA-256(phone + ":" + ROOM_SALT)
            // Unique room ID — cannot be reversed to recover the phone number

access_hash = SHA-256(phone + ":" + PIN + ":" + ACCESS_SALT)
            // Proves PIN knowledge without revealing the PIN itself

# Client-side secrets (never leave the browser)
enc_key     = PBKDF2(phone, room_id + ENC_SALT, 600000, SHA-256, 256-bit)
            // Master encryption key — 600K iterations per OWASP 2023

sender_hash = SHA-256(phone + ":" + access_hash + ":" + room_hash + ":" + SENDER_SALT)
            // Unique sender identity per room session

Encryption Specifications

Cipher

AES-256-GCM

Authenticated encryption with associated data. Industry standard for confidentiality and integrity.

Key Derivation

PBKDF2 600K

600,000 iterations per OWASP 2023 recommendation. Approximately 2 seconds of computation per derivation.

Hash Function

SHA-256

Used for all identifier hashes. Produces 256-bit digests that are computationally irreversible.

Nonce

96-bit Random

Cryptographically random initialisation vector generated fresh for every message encryption.

Auth Tag

128-bit MAC

Message authentication code that detects any tampering with the ciphertext.

Key Length

256-bit

Full 256-bit key space. Brute-forcing this would take longer than the age of the universe.

Threat Model

What we protect against

Casual device snooping and shoulder surfing
ISP and network operator packet inspection
Server-side database breaches
Browser history and cache forensics
Device seizure — no app to find, no chat history to recover
Intimate-access attackers (partner, family member with device access)

Out-of-Scope Risks

We are honest about our limits. sTELgano does not protect against:

Nation-state surveillance infrastructure
Government subpoenas and law enforcement
Targeted endpoint malware and keyloggers
Physical coercion or forced PIN disclosure
A compromised browser or operating system
Network observers who see that you connect to stelgano.com (SNI / DNS / IP)

What the Network Sees

TLS protects the contents of what you send us — never the fact that you're sending it. A partner on the same Wi-Fi, the coffee shop's router, your ISP, or a corporate / school network appliance can observe the following with standard tools (Wireshark, nftables, router logs) even while everything above the TCP/TLS layer stays encrypted:

The destination hostname — TLS 1.2 and 1.3 send the hostname (stelgano.com) in cleartext during the ClientHello (SNI). Encrypted ClientHello (ECH) is not yet widely deployed.
DNS lookups — unless you use DNS-over-HTTPS or DNS-over-TLS, the query for stelgano.com is also visible.
IP address + connection timing — someone inspecting a router log or a NetFlow export can see that your device talked to our IP for a period of time.

If that disclosure is a problem for you, use a VPN or Tor before loading sTELgano. Neither the product nor the protocol can hide the shape of your traffic; the design honestly acknowledges this rather than pretending network-layer metadata doesn't exist.

Paid Extensions: A Residual Correlation

If you pay for a dedicated number, the payment flow is deliberately structured so the extension_tokens table never stores a room_id. No DB dump can answer "which room did this payment pay for?".

We still honestly disclose one residual weakness: a server operator with both DB read access and application log access could temporally align the payment timestamp with a room's TTL update to infer the link. We raise the cost of this correlation by (a) running token and room updates in separate transactions with a random jitter between them, and (b) rounding the stored expiry to the top of its hour so the stored value does not encode the redemption moment. We do not claim to eliminate it against a determined server operator — and this is consistent with the product's broader stance that we do not defend against law-enforcement- grade server access.

The Passcode Test

Design Principle

Every design decision in sTELgano must pass a single test:

"A suspicious person unlocks your phone and opens sTELgano. What do they see?"

The answer: a blank entry screen with two fields. Nothing else. No message previews, no contact list, no notification badges, no chat history. There is nothing to find because nothing is stored.

Data Lifecycle

CORE RULE

N=1 Invariant

At most one message exists per room at any time. When a reply is sent, the previous message is atomically deleted in a single database transaction. No history accumulates.

IMMEDIATE

Immediate Hard Delete on Reply

When you reply, the previous message is permanently hard-deleted from the database in the same transaction that inserts your new message. The old row is gone instantly — no deferred cleanup, no residual data.

TTL ENFORCED

Room Expiry via TTL

Rooms can be set to expire after a time-to-live period. An hourly background job deactivates expired rooms and, in the same transaction, hard-deletes all their messages and every (room_hash, access_hash) record so no long-term linkability of past attempts remains. Expired rooms cannot be rejoined.

Privacy Summary

Data Type	Storage Status
Phone Numbers	Never stored — only hashed derivatives
PINs	Never stored — only hashed derivatives
Plaintext Messages	Never reach the server — encrypted client-side
Encryption Keys	Never leave the browser — derived locally
Room Identifiers	SHA-256 hash only (irreversible)
Access Credentials	SHA-256 hash only (irreversible)
Ciphertext	AES-256-GCM encrypted — deleted on reply
Sender Identity	Ephemeral hash — per-session only
IP Addresses	Rate limiting only — deleted within 48 hours
User Profiles	Do not exist — no accounts

Responsible Disclosure

Report a Vulnerability

If you discover a security vulnerability in sTELgano, we encourage responsible disclosure. Please report vulnerabilities privately so we can address them before they are publicly known.

Our security policy and contact information are published at the standard well-known location.

/.well-known/security.txt

Security & Privacy.