[//] CIPHAR

Security & Threat Model

Ciphar is built for short, sensitive conversations between people who do not want to exchange phone numbers, install an app, or trust a server with cleartext. This page explains exactly what Ciphar protects against, what it does not, and the honest trade-offs of doing end-to-end encryption inside a web browser.

What Ciphar protects

  • Message confidentiality. Every message is encrypted with AES-256-GCM in your browser. The relay sees only ciphertext, an IV, and an authentication tag.
  • Message integrity. AES-GCM produces an authentication tag with every encryption. Any tampering — by the relay, an attacker on the wire, or anyone in the middle — causes decryption to fail.
  • Identity minimization. No account, no email, no phone number, no real name. Participants pick a callsign per channel. The server has no concept of "user".
  • Forward-only retention. Channels self-destruct after 60 minutes. There is no historical archive to subpoena, breach, or sell.
  • User-triggered destruction. Any participant can burn the channel before the timer with the BURN CHANNEL button. The relay performs the same wipe it would do at expiry, immediately. Burn is a defensive control, not just a UI convenience: if you sense the conversation is compromised, you can end it now.
  • Brute-force resistance on the access key. PBKDF2 with 100,000 SHA-256 iterations is applied to the access key before deriving the AES key, making each guess computationally expensive.
  • Intrusion alerts inside the channel. When a participant submits a wrong key on the lock screen, the server rate-limits the requesting IP (temporary lockout with a retry-after window) and posts a system message into the channel itself. Already-authenticated participants see, in real time: SECURITY_ALERT | ACCESS_ATTEMPT with a timestamp on the first wrong attempt, MULTIPLE_ATTEMPTS after two, and CHANNEL_UNDER_ATTACK + BURN_NOW from the third onward. The alerts contain no IP, no fingerprint, and no identifier — just the fact that a guess happened. The intent is to give participants the information they need to hit the burn button before an attacker gets lucky.

Persistent state, in full

For an honest threat model, here is everything Ciphar keeps for longer than sixty minutes:

  • One integer. A single row in app_stats counting how many channels have ever been created, shown on the home page. It is updated atomically on each channel creation. It contains no per-channel, per-user, per-IP, or per-time data — just a count. There is nothing in it that can identify, single out, or correlate any participant with any conversation.

That is the entire list. No user table. No channel history. No log archive. No analytics store. No backups of expired channels.

One related piece of bounded state: while a channel is alive, the relay records failed access-key attempts in a security_events row tied to the channel ID, used to drive the in-channel intrusion alerts above. These rows are cascade-deleted with the channel at the 60-minute mark or on manual burn — they never outlive the channel they belong to.

What Ciphar does not protect against

An honest threat model has to name the gaps. None of the following are problems Ciphar can solve at the protocol level:

  • Compromised endpoints. If your laptop or phone is keylogged, screen-recorded, or remote-controlled, no E2E system can save you. Ciphar is software running in your browser; it is only as private as the device underneath it.
  • The browser itself. Ciphar runs JavaScript that the browser executes. A malicious browser, a malicious extension, or a sufficiently advanced extension permission grant can observe plaintext before it is encrypted.
  • JavaScript delivery. Every web app that does crypto in the browser shares this property: the server delivers the JS that does the encryption. A coerced server could, in principle, deliver tampered JS to a targeted user. We mitigate this with HTTPS, sub-resource integrity for our pinned dependencies, and a small surface area; we cannot eliminate it. If you are facing a nation-state adversary, native E2E apps with reproducible builds (Signal) are a stronger choice.
  • Traffic metadata. The relay knows that some traffic was exchanged on a given channel name during a given time window. It does not know who you are, but a network observer near you knows you connected to ciphar.org. Use Tor or a trusted VPN if your threat model includes that observer.
  • Screenshots, copies, recordings. The other participant can screenshot anything you say. Self-destruct deletes the channel; it does not retroactively scrub copies the recipient has already made.
  • Subpoenas of the channel name. The channel name (the URL) is visible to the relay because routing requires it. Channel names are auto-generated from a fixed dictionary (e.g. ENGINE-PASSPORT-1881) precisely so the name itself carries no semantic information about the participants or topic — they are not user-chosen handles. The relay still knows that some opaque channel existed for a 60-minute window; it does not know who you are or what was said.

Cryptographic primitives

  • Key derivation: PBKDF2-HMAC-SHA-256, 100,000 iterations, 16-byte salt per channel.
  • Symmetric cipher: AES-256-GCM with a 96-bit IV regenerated per message.
  • Random sources: crypto.getRandomValues for IVs, salts, and access keys.
  • Voice: AES-GCM frames over an authenticated WebSocket relay keyed by the same channel secret.

What the relay stores

For every channel, the relay stores: the channel name, a salt, a verify ciphertext used for membership proof, encrypted message blobs with their IVs and tags, and an expires_at timestamp. After the TTL expires, the row is deleted. There is no audit log of which IP read which blob, no analytics database, and no third-party tracker.

How long anything lives

60 minutes from channel creation. There is no extension, no "save the conversation", no "recover the channel". This is intentional: the absence of a recovery path is itself a security property.

Reporting a vulnerability

If you believe you have found a security vulnerability in Ciphar, please email contact@ciphar.org with a brief description of the issue and how to reproduce it. The operator will acknowledge your report within 7 days.

Please do not include exploit details in public posts, social media, or pre-prints before a fix has shipped. Coordinated disclosure protects users.

Ciphar does not currently run a paid bug bounty program. Good-faith security research is welcome, and the operator is happy to publicly credit researchers who find and responsibly disclose issues, on request.

Related: How it works · FAQ · Privacy · Terms · Forge a channel.