🥥 Coconut Wireless — Security

Positioning

Signal-class privacy for the open web — no phone number, Linux-friendly, no big-tech owner. We claim: open client path, ciphertext chat with Double Ratchet (DR-v3), verifiable Safety Numbers, and WebRTC calls protected by DTLS-SRTP. We do not claim “more secure than Signal” until full sealed-sender / MLS group productization and an independent audit ship.

Open Coconut Mesh Call Tech Support

For true end-to-end encryption with no middleman access to chat bodies, Coconut uses a Double Ratchet (DR-v3): the algorithm continuously rotates keys with each message, so even if one key is compromised, past and future messages stay protected (forward secrecy + post-compromise recovery). Older peers can fall back to CHAIN-v2 or v1 ECDH.

Algorithm stack

• Identity keys: ECDH on curve P-256 (Web Crypto)
• Shared secret: ECDH deriveBits → SHA-256 → AES-GCM key material
• Messages: AES-GCM with random 12-byte IV
• DR-v3 (shipping): DH ratchet + per-message chain in crypto-e2e.js
• 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
• Per-message key rotation (Double Ratchet)
• Not full Signal X3DH / sealed sender yet; 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.

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
• If the number ever changes, re-verify — keys may have rotated

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

DTLS-SRTP secures the media stream between your two devices after the signaling handshake. It uses DTLS to exchange keys directly peer-to-peer, then SRTP encrypts the actual voice and video packets with those keys. Coconut and Mesh Call use standard browser WebRTC, so this media encryption is on for live A/V.

• Signaling: Socket.IO / HTTPS (invite, SDP, ICE) — connection setup only
• Media path: WebRTC with STUN + TURN (TURN for hard NATs)
• Media encryption: DTLS key exchange → SRTP packet encryption
• TURN can relay encrypted packets; operators do not get clear voice/video under DTLS-SRTP
• Extra app-layer insertable-stream E2E (beyond DTLS-SRTP) is roadmap, not claimed yet
• Both peers must share the same live signaling API for calls to complete

MLS (Messaging Layer Security) takes this further for group calls by efficiently managing keys across multiple participants (join/leave, epoch rotation, scalable group keying).

• 1:1 media today: DTLS-SRTP (Coconut calls + Mesh Call)
• 1:1 chat today: Double Ratchet (DR-v3)
• MLS for multi-party: architecture target — not claimed as full production MLS until shipped and audited

Summary: DTLS-SRTP locks call media after handshake · Double Ratchet rotates chat keys every message · MLS is the group-scale keying model for multi-person sessions.

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

• Independent audit of crypto + WebRTC signaling is planned
• Until audited, treat Coconut as strong privacy beta, not a formal guarantee
• Sealed sender / full metadata hiding is not complete
• Multi-device key sync is not Signal-complete
• MLS group productization is roadmap
• Screenshots and compromised devices are out of scope for any messenger
• TURN can see that a call exists — not media content under DTLS-SRTP