lockbitchat
27279ae7c6
Adds the Double Ratchet (Signal's design) on top of the existing ECDH session keys, so message protection no longer rests on one set of keys lasting the whole conversation. Every message gets its own key, derived through a one-way function and discarded after use, and each change of direction introduces a fresh ECDH key pair that re-keys the session root. The ratchet needed no handshake change: both peers already hold each other's authenticated ECDH public key, and the safety code compared during verification covers exactly those keys. Its root is derived from the existing shared secret through its own branch of the key schedule. Support is negotiated in the invitation and response and used only when both sides have it; a peer on an earlier release falls back to per-session keys. The security panel reports which of the two is actually in force. Out-of-order delivery is supported within fixed bounds (512 skipped keys per chain, 1024 retained, five-minute expiry), and inbound frames are authenticated before any ratchet state is committed, so a malformed frame cannot desynchronise a live session. Also in this release: - Verification is enforced as a gate, not a label: control frames (reconnection signalling, call setup, message deletion, delivery receipts) are acted on only after both peers have compared the safety code, and verified state is set in a single guarded place. - Chat content reaches the interface through one authenticated path; an older, weaker inbound path was retired. - The security panel measures what it displays — several checks previously returned a fixed result and now exercise the subsystem they describe. - Invitation data is no longer kept in local storage, and entries left by earlier versions are cleared on first launch. - View-once and disappearing messages no longer place their text in system notifications. - Shared-secret buffers are overwritten once derivation completes; scanned QR codes are decompressed with a size limit; voice notes are validated against audio type and size budgets before skipping the consent prompt; the master password is collected by the app rather than a browser dialog. - Connection setup no longer fails on networks where STUN/TURN are unreachable: it proceeds as soon as usable candidates exist and only waits while there are none. Test suite grows from 27 to 41 files, covering forward secrecy, post-compromise re-keying, out-of-order delivery across ratchet steps, the skipped-key bounds, tamper resistance, negotiation fallback, and byte-level key-derivation compatibility with 5.6.0.
206 lines
11 KiB
Markdown
206 lines
11 KiB
Markdown
<div align="center">
|
||
|
||
<img src="logo/securebit-logo.png" width="120" alt="SecureBit.chat" />
|
||
|
||
# SecureBit.chat
|
||
|
||
**End-to-end encrypted, peer-to-peer chat that runs entirely in your browser.**
|
||
|
||
No accounts. No servers storing your messages. No installation required.
|
||
|
||
[](LICENSE)
|
||
[](CHANGELOG.md)
|
||
[](#install-as-an-app)
|
||
[](#security-model)
|
||
[](#forward-secrecy)
|
||
|
||
[Features](#features) · [How it works](#how-it-works) · [Security](#security-model) · [Quick start](#quick-start) · [Documentation](#documentation)
|
||
|
||
</div>
|
||
|
||
---
|
||
|
||
SecureBit.chat is a browser-based, peer-to-peer messenger built on **WebRTC** and the **Web Crypto API**. Two people establish a direct, end-to-end encrypted channel and verify each other in person — there is no registration, no central server relaying or storing messages, and no metadata account to leak. Everything cryptographic happens locally in the two browsers.
|
||
|
||
It is designed for people who need a small, auditable, zero-infrastructure way to talk privately: journalists and sources, security researchers, or anyone who simply wants a conversation that leaves nothing behind.
|
||
|
||
## Screenshots
|
||
|
||
| Open a secure channel | Encrypted conversation |
|
||
| :---: | :---: |
|
||
|  |  |
|
||
|
||
## Features
|
||
|
||
** Encryption & verification**
|
||
- ECDH P-384 key agreement with derived per-session keys, AES-256-GCM payloads, and DTLS-protected transport.
|
||
- **Double Ratchet forward secrecy** — every message is encrypted with its own key, and the session re-keys itself each time the conversation changes direction. See [Forward secrecy](#forward-secrecy).
|
||
- Interactive **Short Authentication String (SAS)** verification — you confirm a code out-of-band before the session is trusted, defeating man-in-the-middle attacks.
|
||
- Replay protection, message integrity (HMAC), and a live security report you can open at any time during a call.
|
||
|
||
** Privacy by design**
|
||
- Direct peer-to-peer connection — messages never touch a SecureBit server.
|
||
- No accounts, no phone numbers, no message history on disk.
|
||
- Optional **relay-only mode** routes traffic through your own TURN server so your IP is never exposed to the peer.
|
||
- Local key metadata is stored encrypted in IndexedDB; disconnecting cleans up session state.
|
||
|
||
** Encrypted calls**
|
||
- **1:1 voice and video calls** over the same verified peer-to-peer connection — media rides the SAS-verified DTLS-SRTP transport, so calls inherit the session's end-to-end encryption and never traverse a SecureBit server.
|
||
- **Adaptive audio**: Opus with in-band FEC, DTX and RED redundancy for intelligible speech under 15–20% packet loss; audio is prioritised and never throttled by the network controller.
|
||
- **Adaptive video**: VP9/AV1 single-encoding SVC (H.264/VP8 fallback) that degrades by spatial/temporal layer, with a runtime controller that trims video bitrate on loss/RTT and recovers as the link clears.
|
||
- **Live connection-quality indicator** (Excellent → Good → Fair → Weak) shown in the call UI, plus in-call mute and video-upgrade controls.
|
||
|
||
** Messaging**
|
||
- **Encrypted voice messages** — record in the browser and send over the same end-to-end encrypted transfer channel as files. Audio is captured as PCM/WAV, integrity-protected by a signed hash, and played back inline on the recipient's device without ever touching disk.
|
||
- Code blocks with syntax highlighting and an auto-clearing copy button.
|
||
- View-once and disappearing messages with countdown timers.
|
||
- Unsend (delete for everyone) over the authenticated control channel.
|
||
- WhatsApp-style delivery status (sending → sent → delivered) with offline store-and-forward.
|
||
|
||
**Multiple conversations**
|
||
- Run several independent chats at the same time. Every conversation gets its own encrypted session, keys and verification, so two chats can never mix.
|
||
- A side panel lists your open chats with unread badges. Switching is instant, and starting a new chat leaves the others connected.
|
||
- Set your availability (Available, Away, Busy or Invisible) and connected peers can see it. You can also give each chat a private label that is stored only on your device and is never sent to the other side.
|
||
|
||
** File transfer**
|
||
- Consent-gated, end-to-end encrypted transfers with resumable, per-chunk progress.
|
||
- Strict file-type allowlist; executable and scriptable formats are rejected.
|
||
|
||
** Progressive Web App**
|
||
- Installable on desktop and mobile, works offline, and ships update notifications.
|
||
|
||
## How it works
|
||
|
||
SecureBit never sees your conversation. A session is built directly between the two browsers:
|
||
|
||
```
|
||
Peer A Peer B
|
||
│ 1. create encrypted offer │
|
||
│ ────────────────────────────► │ (shared out-of-band: QR / link / paste)
|
||
│ │
|
||
│ 2. return encrypted answer │
|
||
│ ◄──────────────────────────── │
|
||
│ │
|
||
│ 3. compare SAS code aloud │
|
||
│ ✓ both confirm → verified │
|
||
│ │
|
||
│ ═══ end-to-end encrypted ════ │
|
||
```
|
||
|
||
1. **Peer A** creates an offer (sharable as a QR code, link, or text).
|
||
2. **Peer B** opens it and returns an answer the same way.
|
||
3. Both sides see a **SAS code** and compare it over a trusted channel (in person, a call you recognize, etc.).
|
||
4. Only after both peers confirm the matching code does the chat unlock. Three failed attempts terminate the session.
|
||
|
||
## Security model
|
||
|
||
| Layer | Mechanism |
|
||
| --- | --- |
|
||
| Key agreement | ECDH (P-384), per-session derived keys |
|
||
| Forward secrecy | Double Ratchet — per-message keys, DH re-key on each reply |
|
||
| Transport | WebRTC data channel over DTLS |
|
||
| Message encryption | AES-256-GCM, end-to-end |
|
||
| Authentication | Interactive SAS bound to both peers' DTLS fingerprints |
|
||
| Integrity | HMAC + replay protection |
|
||
| Sanitization | DOMPurify text-only rendering boundary |
|
||
| Local storage | Encrypted key metadata in IndexedDB |
|
||
|
||
A session is **not** treated as verified until both peers complete the SAS flow. This is the step that protects you against a man-in-the-middle: the code must be compared through a channel an attacker cannot impersonate. Until it is completed, the session will not act on control messages from the peer.
|
||
|
||
### Forward secrecy
|
||
|
||
Message protection does not rest on the keys agreed during the handshake. On top of them SecureBit runs the **Double Ratchet** — the design used by Signal:
|
||
|
||
- **Every message gets its own key.** It is derived from a chain key through a one-way function and discarded as soon as the message is encrypted or read, so keys held now cannot reconstruct earlier ones. Recovering the live state of a session does not expose what was said before.
|
||
- **Each change of direction re-keys the session.** Every reply introduces a fresh ECDH key pair and mixes a new shared secret into the root key, so the conversation continuously moves away from any state an attacker may have captured.
|
||
- **Out-of-order messages are handled within fixed bounds.** Keys are held for messages that have not arrived yet, capped at 512 per chain and 1024 in total and expiring after five minutes, with a limit on how far ahead a message may claim to be.
|
||
|
||
The ratchet is negotiated during the handshake and used when both peers support it. If one side is on an older release, the session falls back to per-session keys and the security panel reports which of the two is actually in use — it shows the state of your connection, not the capabilities of your client.
|
||
|
||
> [!WARNING]
|
||
> SecureBit.chat is privacy software, not a guarantee. View-once and disappearing messages are cooperative (not screenshot-proof), and a TURN relay can observe both peers' IPs and traffic timing — though never message contents. See [`SECURITY_DISCLAIMER.md`](SECURITY_DISCLAIMER.md).
|
||
|
||
## Quick start
|
||
|
||
### Run locally
|
||
|
||
```bash
|
||
npm install
|
||
npm run build
|
||
npm run serve
|
||
```
|
||
|
||
Open the printed local URL in two browser windows or profiles, then:
|
||
|
||
1. Create an offer in the first window.
|
||
2. Transfer it to the second and create an answer.
|
||
3. Return the answer to the first window.
|
||
4. Compare the SAS code out-of-band and enter it on both sides.
|
||
5. Start chatting once both peers are verified.
|
||
|
||
### Install as an app
|
||
|
||
SecureBit is a PWA — open it in a supported browser and choose **Install** (or *Add to Home Screen* on mobile) to run it as a standalone, offline-capable app.
|
||
|
||
## Configuration
|
||
|
||
### TURN / privacy mode
|
||
|
||
Direct WebRTC connections can reveal IP addresses to the peer. SecureBit supports a relay-only privacy mode:
|
||
|
||
- **Default** keeps standard WebRTC behavior with public STUN.
|
||
- **Relay-only** sets `iceTransportPolicy: "relay"` and requires a configured TURN server.
|
||
- STUN alone does not hide IP addresses; public TURN credentials are never bundled.
|
||
|
||
Configure your own STUN/TURN servers under **Advanced network settings**, or at deployment time. See [`doc/CONFIGURATION.md`](doc/CONFIGURATION.md).
|
||
|
||
### File transfer policy
|
||
|
||
Incoming transfers require explicit consent. Metadata is validated and dangerous names rejected before the prompt appears. Accepted: common raster images, PDF, plain text, and ZIP. Executable/scriptable formats (`.exe`, `.bat`, `.sh`, `.js`, `.msi`, `.dmg`, `.jar`, `.ps1`, `.vbs`, `.html`, `.svg`, …) are blocked, and MIME type must agree with the file extension.
|
||
|
||
## Development
|
||
|
||
**Requirements:** Node.js 18+ and npm.
|
||
|
||
```bash
|
||
npm install
|
||
npm test # run the test suite
|
||
npm audit # check dependencies
|
||
npm run build # build CSS + JS bundles and refresh meta.json
|
||
npm run dev # build and serve locally
|
||
```
|
||
|
||
### Project structure
|
||
|
||
```text
|
||
src/network/ WebRTC connection and session lifecycle
|
||
src/transfer/ secure file-transfer implementation
|
||
src/crypto/ cryptographic utilities and the Double Ratchet
|
||
src/components/ React UI components
|
||
src/styles/ component styles
|
||
tests/ node:assert suites, run by `npm test`
|
||
doc/ technical documentation
|
||
dist/ built bundles served in production
|
||
```
|
||
|
||
## Documentation
|
||
|
||
- [`SECURITY.md`](SECURITY.md) — security policy & reporting
|
||
- [`doc/CONFIGURATION.md`](doc/CONFIGURATION.md) — deployment & ICE configuration
|
||
- [`doc/CRYPTOGRAPHY.md`](doc/CRYPTOGRAPHY.md) — cryptographic design
|
||
- [`doc/SECURITY-ARCHITECTURE.md`](doc/SECURITY-ARCHITECTURE.md) — architecture overview
|
||
- [`doc/API.md`](doc/API.md) — internal APIs
|
||
- [`CHANGELOG.md`](CHANGELOG.md) — full release history
|
||
|
||
## Contributing & responsible use
|
||
|
||
Issues and pull requests are welcome. SecureBit.chat is intended for lawful, ethical communication only — please read [`RESPONSIBLE_USE.md`](RESPONSIBLE_USE.md) before using or contributing.
|
||
|
||
## License
|
||
|
||
Released under the [MIT License](LICENSE).
|
||
|
||
<div align="center">
|
||
<sub>Built with WebRTC and the Web Crypto API · No servers, no accounts, no compromises.</sub>
|
||
</div>
|