SecureBit.chat - P2P Encrypted Messenger Files

Sessions previously derived one set of keys during the handshake and used them for the whole conversation. This release adds the Double Ratchet (Signal's design) on top of that, so protection no longer rests on a single set of keys lasting the entire chat. It also collects a hardening pass across verification, peer input and local storage.

This is the first public release since 5.6.0 and supersedes the 5.6.1, 5.6.2 and 5.7.0 development builds.

Forward secrecy

• A separate key for every message. Each message key is derived from a chain key through a one-way function and discarded immediately after use, so keys that exist now cannot be used to reconstruct earlier ones.
• A Diffie–Hellman step on every change of direction. Each reply introduces a fresh ECDH key pair and mixes a new shared secret into the root key, so a session re-keys itself continuously as the conversation goes back and forth.
• Bounded handling of out-of-order messages. Keys for messages that have not arrived yet are held so they can still be read, with firm limits on how many are kept (512 per chain, 1024 in total, expiring after five minutes) and a fixed ceiling on how far ahead a message number may jump.

The ratchet required no change to the handshake. Both peers already hold each other's authenticated ECDH public key, and the safety code compared during verification covers exactly those keys. The ratchet's root is derived from the existing shared secret through its own branch of the key schedule, keeping it separate from the session's other keys.

Incoming frames are authenticated before any ratchet state is committed, so a malformed frame cannot desynchronise an established session.

Compatibility

Support is advertised in the invitation and the response and used only when both sides have it. A peer on an earlier release negotiates it away and the session runs on the previous scheme — with no server in the design there is no way to update both ends at once, and connecting with the earlier protection is better than not connecting. The security panel shows which of the two is actually in use, rather than what the client is capable of.

The peer who joins has no sending chain until the inviting peer's first message arrives; that is inherent to the ratchet, since both sides derive it from the same exchange. The app sends a presence update from both sides as soon as verification completes, so those first frames use the session keys and everything afterwards is ratcheted.

Verification and peer input

• The safety-code comparison is the only route to a verified session. Verification state is set in exactly one place, and the checks that guard it cannot be reached around.
• Control messages are honoured only after verification. Reconnection signalling, call setup, message deletion and delivery receipts all wait until both people have compared the safety code. The verification exchange itself continues to work beforehand, as it must.
• A single path for incoming chat content, so everything shown in a conversation has been authenticated.

Accuracy of what the app reports

• The security panel now measures what it displays. Several checks previously reported a fixed result; they now exercise the subsystem they describe and can report a failure. The score therefore reflects the session more precisely, and may read differently than before on the same connection.
• Operations that cannot clear a value in JavaScript — immutable strings, non-extractable keys — now say so instead of reporting success.

What stays on the device

• Invitation data is no longer kept in local storage. An unused reference-based QR path wrote session invitation details to local storage without removing them; the path has been removed and existing entries are cleared on first launch after updating.
• Ephemeral messages stay ephemeral. View-once and disappearing messages no longer place their text in system notifications, where the operating system would retain it beyond the app's control. Ordinary messages are unchanged.

Hardening

• Shared-secret buffers are overwritten once derivation completes.
• Scanned QR codes are decompressed with a size limit, so a malformed or hostile code cannot exhaust memory.
• Voice notes are validated before being accepted automatically: only genuine audio types within a size limit skip the consent prompt, and a per-session budget bounds how much can arrive unattended.
• The master-password prompt comes from the app's own interface rather than a browser dialog.
• Local and remote DTLS fingerprints are kept separate and reported accurately.

Connectivity

• Connection setup on restrictive networks. Gathering network candidates only finishes once every configured STUN/TURN server has replied or timed out, which behind a VPN or a strict firewall may not happen at all. Setup now proceeds as soon as there are usable candidates and only keeps waiting while there are none, up to a longer ceiling. A network that genuinely yields nothing now explains what to try instead of failing without explanation.

Under the hood

The 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.

Key agreement is unchanged on the wire; 5.6.0 sessions remain compatible.

Full changelog: https://github.com/SecureBitChat/securebit-chat/blob/main/CHANGELOG.md