🥥 Coconut Wireless — Security

Honest overview of what is implemented today (build: safety-v1). No phone number required. Private keys never leave your device for chat E2E.

Whitepaper v0.9 · public draft

Positioning

Signal-level security for the open web — no phone number, Linux-friendly, no big-tech owner. We do not claim “more secure than Signal” until Double Ratchet and an independent audit ship. We claim: open client path, ciphertext chat, verifiable keys, working calls.

1. What the server can and cannot see

Data	Server	Notes
Username / display name	Yes	Account directory
Password	Hashed only	Never stored plaintext
Chat message body (E2E on)	Ciphertext only	`cipher` + `iv`; plaintext stripped when present
Your private key	Never	Stays in browser `localStorage` for that username
Your public key	Yes	So peers can encrypt to you
Who messaged whom / when	Metadata	Delivery requires routing; minimization is ongoing
Call signaling (invite, SDP, ICE)	Yes (relay)	Needed to connect; media is peer WebRTC
Voice/video media bytes	Not by design	WebRTC P2P or TURN relay encrypted with DTLS-SRTP

2. Chat encryption (current)

Algorithm

Identity keys: ECDH on curve P-256 (Web Crypto)
Shared secret: ECDH deriveBits → SHA-256 → AES-GCM key
Messages: AES-GCM with random 12-byte IV
Wire format: { alg, iv, cipher } (+ optional fromPublicKey)

What this gives you

Server operators cannot read message bodies when E2E is used correctly
Each browser holds its own private key
DR-v3 (shipping): Double Ratchet — DH ratchet + per-message chain (forward secrecy + post-compromise recovery)
CHAIN-v2: symmetric chain fallback for older clients
v1: plain ECDH session still decryptable
Not full Signal X3DH / sealed sender; identity ECDH bootstrap, P-256 (not X25519 yet)
If your device is compromised, stored private keys are at risk until you reset

Roadmap

X25519 migration, sealed sender / metadata minimization, post-quantum hybrid (X25519 + Kyber), independent audit.

3. Safety Numbers (shipping now)

Open a chat → tap 🔐. Coconut builds a 60-digit Safety Number from both identity public keys (order-independent).

Both people should see the same number
QR encodes the same verification payload for easy compare
“Mark verified” is stored on this device only (not a server trust list)
If the number ever changes, re-verify — keys may have rotated

Algorithm: SHA-256("coconut-safety-v1|" + sortedCanonKeyA + "|" + sortedCanonKeyB) → 60 digits

4. Voice & video calls

Signaling: Socket.IO over HTTPS (invite / accept / SDP / ICE)
Media: WebRTC with STUN + TURN (TURN for hard NATs)
Media encryption: DTLS-SRTP (browser standard)
Application-layer insertable-stream E2E (beyond DTLS-SRTP) is not claimed yet
Desktop app must use the live API so both peers share the same signaling server

5. Authentication

No phone number required — username (+ optional password)
Sessions use JWT; sockets can require auth
Guest / quick join available for demos — use a password account for real use

6. Audit roadmap

Independent audit of crypto + WebRTC signaling is planned
Until audited, treat Coconut as strong privacy beta, not a formal security guarantee

7. How to verify a contact (user steps)

Both of you open Coconut and the same chat
Each taps 🔐 Safety Number
Compare the digits (or scan QR) in person or via a second channel
If they match → Mark verified
If they differ → stop sending sensitive data and investigate

8. Known limitations (honest)

No Double Ratchet / sealed sender yet
Metadata (social graph, timing) still visible to the server for routing
Multi-device key sync is not Signal-complete
Screenshots / compromised endpoints are out of scope for any messenger
TURN servers can see that a call is happening (not media content under DTLS-SRTP)