The README, ARCHITECTURE.md and CRYPTOGRAPHY.md still described the old
handshake: keys and a session salt travelling inside the invitation, and a safety
code derived from the two DTLS fingerprints. None of that has been true since
5.9.0.
Adds a "The invitation" section to the README covering what the exchange was
reduced to and why that is a security change and not only a smaller QR code:
less material exposed before anyone is authenticated, the DTLS fingerprint as the
anchor, substituted keys failing closed on the commitment instead of on a human
comparison, a safety code that now covers the whole transcript rather than two
fingerprints, and the plain fact that a single QR is scanned in person where a
four-frame animated one pushes people to paste the invitation through a chat app.
Session lifecycle in ARCHITECTURE.md gains the in-band key exchange as its own
step. CRYPTOGRAPHY.md now states that the salt is derived from the transcript
rather than transmitted, and describes the transcript SAS and the signature that
replaced the challenge/response. DESCRIPTOR-SBQ2.md is listed in the doc index
and in the CONTRIBUTING impact table.
The descriptor no longer carries key material. It carries what brings up DTLS
plus a 16-byte commitment; the ECDH and ECDSA public keys travel as the first
frame on the DataChannel and are checked against that commitment BEFORE they are
parsed or imported. Measured on the live site, the invitation went from 2274
characters across 4 animated QR frames to 151 characters in one frame.
What the split buys is that nothing is trusted on the strength of having
completed a handshake. The fingerprint arrives over the channel the user
authenticated by looking at it, so DTLS completes only with whoever showed the
code; the commitment makes substituted key material fail closed automatically
instead of relying on the human comparison; and the SAS is computed over a
transcript covering both descriptors verbatim and both key blobs, so anything an
attacker can change anywhere in the handshake changes the digits.
Consequences for the rest of the crypto:
- the HKDF salt is derived from the transcript rather than transmitted, binding
every session key to both DTLS fingerprints and every candidate;
- authProof is replaced by one ECDSA signature over the transcript, proving the
same possession without echoing a nonce back across seven fields;
- Double Ratchet support is implied by the format rather than advertised in it.
SBQ2 postdates the ratchet, so the "peer is old, fall back to static keys"
branch is unreachable here -- it used to fire silently, since SBQ2 has no `dr`
field for _initializeRatchet to find.
Fail closed throughout. _handshakeMode is latched per connection, so a session
cannot be pushed back onto SB1 halfway through; commitment mismatch, wrong role,
duplicate blob, bad proof and timeout all tear the connection down with a
specific message rather than degrade. SBQ2 handshake frames are refused outright
on a non-SBQ2 session, where there would be no commitment to check them against.
Reception of both formats is unconditional and split by first byte (0x02 vs
ASCII 'S') and text prefix. SBQ2_SEND_ENABLED is the single value that governs
what we emit; flipping it to false and redeploying reverts new invitations to
SB1, and the animated multi-frame QR path stays for them.
Verified end to end in real browsers -- 12/12 across {Chrome, Firefox} squared
and three network profiles -- through to a confirmed SAS, an active ratchet, a
64-byte transcript-derived salt and a decrypted message on the far side.
Live cross-browser testing found three defects in the SBQ2 SDP template, all
invisible to Chrome and all fatal to Firefox.
The candidate lines omitted raddr/rport on srflx and relay candidates. RFC 8839
section 5.1 makes rel-addr and rel-port mandatory for non-host candidates even
though ICE never reads them; Chrome tolerates the omission and Firefox drops the
candidate. Relay-only connections to Firefox failed 0/8 against 8/8 for the
browser's own SDP. The STUN and TURN profiles hid it because a host pair
connected instead -- the relay candidates were never actually needed there.
The template also advertised ice-options:trickle without ever closing the
candidate set, though a descriptor is a complete one-shot set with no channel to
trickle over, and hard-coded the m= port and c= line to the 9 / 0.0.0.0 null
default candidate, which is the trickle convention for "nothing gathered yet".
Both are now correct: no trickle, an explicit a=end-of-candidates, and the most
publicly reachable candidate as the default.
All three are serializer-side and cost zero descriptor bytes; sizes are
unchanged at 98-149 bytes, QR version 6-8. Verified 48/48 across all 16
combinations of {Chrome, Firefox} squared and four network profiles, with every
relay-only pair now connecting over the relay.
The SB1 invitation runs 2000-2400 characters and needs QR version 38-40, past
the point where a single code is scannable, so the app falls back to an
animated multi-frame QR. SBQ2 is a fixed binary layout carrying only what
brings up DTLS -- ICE credentials, certificate fingerprint, candidates -- with
the SDP rebuilt from a template by a strict serializer. Measured on real Chrome
and Firefox SDP across four network profiles: 98-149 bytes, QR version 6-8.
Key material is meant to move to the DataChannel, bound by a commitment in the
descriptor. That half does not exist yet, so nothing calls this module: the
format is landed for review and freeze, not wired into the connection path.
doc/DESCRIPTOR-SBQ2.md records the gate on phase 3.
The decoder is a parser of hostile input: fixed offsets, explicit lengths,
deny-by-default on reserved values and unknown TLV extension types, trailing
bytes rejected, ICE credentials alphabet-checked so a CRLF cannot reach the
serializer. No compression -- DEFLATE adds bytes on this payload, and dropping
it removes the decompression-bomb surface with it.
Candidate pruning keeps coverage before count: one candidate per (family, type,
transport) survives before any surplus, so an IPv6-only or UDP-blocked path
cannot be pruned away by a v4-first sort.
Tests cover round-trip against captured Chrome and Firefox SDP, IPv6 and NAT64
addresses, ICE-TCP candidates, the TLV area, clock skew, one-shot binding and
SAS transcript coverage.
No protocol or message-protection changes.
The version in the application header was a literal and had fallen behind,
showing v5.6.0 while running 5.7.1. It now comes from package.json, and a test
fails if a hard-coded one reappears or if meta.json, the README badge, the
changelog and the docs disagree about the release.
Documentation reorganised so that everything technical lives in doc/ with an
index, and the root keeps only what belongs there by convention: README,
SECURITY, CHANGELOG and LICENSE.
- SECURITY.md rewritten. It listed a supported release line three major versions
out of date and made claims the software does not make. It now states what is
guaranteed, what is not, and how to report a problem.
- SECURITY_DISCLAIMER.md and RESPONSIBLE_USE.md merged into doc/USE-POLICY.md,
which says what the software cannot protect against rather than listing
generic advice.
- doc/SECURITY-ARCHITECTURE.md renamed to doc/ARCHITECTURE.md and rewritten
around the session lifecycle, what verification gates, and how recovery works.
- doc/CRYPTOGRAPHY.md rewritten: key schedule, the Double Ratchet, framing, and
memory handling, with values taken from the source rather than restated.
- doc/CONFIGURATION.md rewritten with the real file-type policy, ICE and TURN
guidance, and the deployment caching rules that matter.
- docs/webrtc-config.md moved to doc/CALLS.md and rewritten; the obsolete
docs/webrtc-audit.md, a working document full of stale line numbers, removed
along with the docs/ directory.
- doc/CONTRIBUTING.md records what the recent regressions taught us about
writing tests that can actually fail.
- doc/README.md added as an index.
Internal security review notes are excluded from the repository via .gitignore.
Those describe attack paths against specific releases in enough detail to
reproduce them, which is useful privately and harmful in public while users are
still updating.
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.
A chat no longer dies when the network moves under it. A NAT rebind, a lift, a
Wi-Fi radio parking itself, a phone that dozed: the session repairs its own network
path in place, and the messages typed meanwhile go out when it returns.
Recovery is an ICE restart, which renegotiates only the transport path — the DTLS
handshake, the session keys and the SCTP association carrying the data channel all
sit above ICE and survive it. The renegotiation SDP therefore travels over the
existing end-to-end encrypted, SAS-verified channel: no signalling service enters
the design, and an attacker who cannot already decrypt the session cannot inject a
reconnection. A restart is refused outright unless the DTLS fingerprint in the
incoming SDP matches the live session's, so recovery can never re-point a
conversation at a different peer.
When the path is gone for good the session is ended and its data wiped rather than
left half-alive: with no server there is nothing to re-signal through, and a
conversation whose transport is gone should not leave its plaintext in an open tab.
The two cases where that is already certain are recognised in seconds instead of
being retried for two minutes — a channel that has delivered nothing at all since
the drop cannot carry a renegotiation, and an ICE agent left bound to a network that
no longer exists reports zero candidate pairs on every restart.
Judging liveness was the hard part. Silence is not evidence of death: browsers freeze
backgrounded tabs outright, and a frozen peer answers nothing while being perfectly
healthy. What survives that freeze is ICE consent, which the browser runs in its
network stack rather than on the page's thread — so a connected ICE state means a
silent peer is asleep, and only a degraded one turns an unanswered probe into a
teardown. The grace window before a restart is sized to the browser's own timings:
'disconnected' arrives after ~5s of missed consent responses and is held ~25s before
'failed', and that window exists for self-healing, so restarting at the start of it
broke connections that were about to recover.
Several long-standing bugs surfaced along the way and are fixed here:
- handleHeartbeat() was dispatched to but never defined, so every inbound heartbeat
threw a TypeError and peer liveness was never observed at all.
- Heartbeats were folded into the 5-minute maintenance cycle instead of running on
their own timer, far too coarse to notice a dead path.
- ondatachannel can hand over a channel that is already open, so the answering side's
'open' event had been dispatched before the handler was assigned and never fired,
leaving that side with no heartbeat, no watchdog and no file-transfer init. The peer
whose network was fine kept showing "connected" indefinitely because nothing was
running to notice.
- Answering a heartbeat required the peer to have finished verifying, but the two
sides confirm a SAS code at different moments; for that whole window one of them
could not reply and was declared dead on a healthy connection.
- Sending on a channel that was not ready returned in silence: the text stayed in the
box, nothing was transmitted, and nothing said why.
- The send path gated on navigator.onLine and the offline/online events, which report
whether an interface exists rather than whether anything is reachable. A tab the OS
froze misses the 'online' edge, and this side then queued every message forever: one
tick on everything it sent, while incoming messages kept arriving. Sending is now
decided by the data channel, and queues drain by polling rather than on an edge, so
a missed event cannot strand them.
- A false offline modal appeared on a working session, because the offline event was
taken at face value.
tests/session-recovery.test.mjs covers the state machine, the backoff and its
serialisation, the offline hold, the sleeping-peer discriminator and the identity
check.
The buttons still led to a dead GitHub page. 5.5.3 updated one of the two places
these links live — the platforms menu on the connection screen keeps its own
DOWNLOADS table, and it was missed, so it stayed on 0.1.0.
Why it looked like a working link that did nothing: the stale entries used
/releases/latest/download/<file>, and GitHub resolves `latest` by redirecting to
the newest tag. Once 0.3.0 shipped, a link written for 0.1.0 resolved to
/releases/download/v0.3.0/SecureBit.Chat_0.1.0_x64-setup.exe — a file that never
existed under that tag. The browser navigated to GitHub and downloaded nothing.
Both places now build their URLs from a DESKTOP_VERSION constant with the tag
pinned, so the version is written once per file and a link cannot silently
become invalid when a new release goes out.
Adds tests/desktop-download-links.test.mjs, which fails the build if this drifts
again: every source must derive URLs from that constant, /latest/ and hardcoded
versions in filenames are rejected, and each generated URL is fetched to prove
the asset exists. SKIP_NETWORK=1 skips the fetches offline.
The Download block still offered desktop 0.1.0 — the build from before in-app
updates, the voice-note fixes and the verification hardening. Windows, macOS and
Linux now link to 0.3.0.
The version was repeated across three URLs in two different forms: two resolved
through /releases/latest/download/ and one pinned a tag. That is how they drifted
out of date, so it is now one constant.
The tag stays pinned on purpose. Release filenames carry the version, so a
/latest/ link breaks the moment a newer release exists, while a pinned tag keeps
serving a working installer — the safer way to fail if the constant is ever left
behind.
A security review of the transport and verification layers. Every item is a fix
to how untrusted peer input is handled; no features changed.
- SAS verification could be bypassed. `verification_both_confirmed` is an
unauthenticated frame on a channel that is not yet trusted, but it was taken as
proof that both sides had compared their codes — so a peer who completed the
signalling exchange could send it right after the data channel opened and drive
the other side to a "verified" session while the user never looked at the code.
It is now only an acknowledgement: refused unless this side already confirmed
locally, and _setVerifiedStatus() independently rejects any SAS-based
transition without a local confirmation. Holding ECDH-derived keys was never
proof of identity — a MITM has those too.
- Unauthenticated frames could be injected into the chat. A bare
{type:"message"} frame, a raw non-JSON frame and a binary frame were each
decoded and rendered, bypassing decryption, the HMAC check and the verification
gate; the injected text was indistinguishable from a genuine message. Chat
content now reaches the UI only through the authenticated enhanced_message
path.
- A peer could supply the verification code. `sas_code` announcements were
adopted verbatim when no local SAS had been derived yet. They may now only
corroborate the locally derived code.
- Anti-replay never ran. The sequence-number and AAD validators were defined on
SecureKeyStorage instead of the connection manager, so every call site failed
with a TypeError and the sliding replay window was dead code. Moved onto the
manager, wired into the live chat path, and a missing or non-numeric sequence
number now fails closed instead of sailing through the range checks.
- File transfers are gated on verification in both directions. Control frames are
written straight to the data channel by the transfer system; sending was
already gated, receiving now is too.
- Tighter CSP: connect-src and img-src no longer allow arbitrary https: hosts
(nothing in the app talks to a third party), plus base-uri 'none'.
- The SAS is no longer written to logs, and is compared in constant time on every
path. Fixed SecureMasterKeyManager.isUnlocked() testing a field renamed long
ago, so it never actually gated anything.
- Fixed the header showing "Secure undefined%": getRealSecurityLevel() became
reachable for the first time by the move above and returned only per-feature
booleans, while the header renders `level` and `score` directly. It now runs
the same verified scoring as every other consumer.
Adds regression tests for the verification gate, inbound frame authentication and
the security-level shape.
Add 1:1 voice and video calling over the existing SAS-verified peer
connection. Audio and video tracks ride the same RTCPeerConnection as the
chat, bundled onto one DTLS-SRTP transport, so media inherits the session's
end-to-end encryption. SDP offer/answer is renegotiated in-band over the
verified data channel — no signalling server, so the media's DTLS
fingerprints are authenticated end-to-end. Calls are gated on a connected,
SAS-verified session.
Codecs & adaptation:
- Opus tuned for lossy links (in-band FEC, DTX, RED redundancy); audio is
bandwidth-prioritised and never throttled.
- VP9/AV1 single-encoding SVC with H.264/VP8 fallback; video degrades by
spatial/temporal layer.
- Runtime NetworkAdaptationController trims video bitrate on loss/RTT and
recovers as the link clears — no renegotiation. Live connection-quality
indicator (Excellent/Good/Fair/Weak) in the call UI.
In-call controls: mute, camera on/off (voice→video upgrade in-band),
camera flip, minimize-to-widget, hang up, and accept/decline for incoming
calls. Production logging disabled (DEBUG_MODE=false); temporary call
diagnostic logger removed. Codec rationale in docs/webrtc-config.md.
- config/ice-servers.prod.js: swap ExpressTURN for self-hosted coturn at
turn.securebit.chat (TURN udp/tcp on 3478, TURNS/TLS on 443). Long-lived
REST-API credential (expiry capped at int32 max for coturn compatibility).
- Add raw-IP STUN/TURN fallback (144.172.96.126): Safari's WebRTC layer fails
to resolve STUN/TURN hostnames on some networks and gathers no srflx/relay
candidates; reaching the server by IP fixes cross-browser (Safari<->Chrome)
connections. Harmless to other browsers.
- deploy/nginx.conf: never long-cache /config/ice-servers.js so clients don't
lock onto a stale server list.
- Bump version to 5.4.10 (header + init banner).
- Record voice notes in-browser, sent over the chunked AES-GCM file-transfer
channel (per-file session key + signed SHA-256 integrity).
- Captured as PCM and encoded to WAV for universal playback (incl. iOS/Safari);
auto-accepted and played inline from an in-memory blob, never written to disk.
- Composer mic button with live waveform + timer; desktop shows mic + send side
by side, mobile swaps mic to send when typing.
- CSP media-src now allows blob: so recorded/received audio can play.
- Roadmap: Desktop Edition -> 5.0, new 5.5 'Secure Voice & Calls', later
milestones shifted; version bumped to 5.4.5.
- Update README, docs (security/API/cryptography), and CHANGELOG.
Each conversation now runs its own WebRTC session with separate keys and SAS verification, so chats never mix. Adds a side panel to switch between open chats with unread badges, a New chat action that leaves existing chats connected, per-chat local labels stored only on this device, and an availability status (Available, Away, Busy, Invisible) shared end-to-end with connected peers. Also includes vendored Prism syntax highlighting, more reliable PWA update handling, and offline send queueing fixes. Version 4.10.0.
- Move CSP frame-ancestors and report-uri to HTTP headers
- Fix font-src to allow fonts.gstatic.com
- Add MIME type configuration for .jsx files
- Improve Service Worker error handling with cache fallback
- Rebuild application
- Add UpdateManager and UpdateChecker for automatic version detection
- Add post-build script for meta.json generation and version injection
- Enhance Service Worker with version-aware caching
- Add .htaccess configuration for proper cache control
This ensures all users receive the latest version after deployment
without manual cache clearing.
- Update version to v4.7.53
- Add Desktop Edition documentation (Windows, macOS, Linux)
- Update roadmap with all versions and dates
- Add mobile apps information (Q1 2026)
- Expand security and development sections
- Update URLs to securebit.chat domain
- Disable timer-based key rotation for Double Ratchet mode
- Auto-reinitialize encryption keys when missing but ECDH available
- Preserve active keys during periodic cleanup in ratchet sessions
- Fix IndexedDB "database closing" errors with connection checking
- Add individual transactions per queue item to prevent race conditions
- Implemented proper RFC 5869 compliant HKDF key derivation process
- Added Perfect Forward Secrecy (PFS) key for enhanced session security
- Improved key separation using unique info parameters for each derived key
- Enhanced salt size from 32 to 64 bytes for increased entropy
- Added comprehensive key validation and error handling
- Implemented proper ECDH + HKDF integration following Web Crypto API best practices
- Added metadata encryption key for enhanced data protection
- Improved compatibility with modern cryptographic standards (RFC 7748, NIST SP 800-56A)
-Enhanced logging and debugging capabilities for cryptographic operations
- Maintained backward compatibility while upgrading security infrastructure
Security improvements:
- Cryptographic isolation between different key purposes
- Enhanced protection against cross-key attacks
- Improved resistance to future key compromise scenarios
- Better compliance with OWASP cryptographic storage guidelines
Technical details:
- Refactored deriveSharedKeys() method for proper HKDF implementation
- Updated WebRTC manager to use new messageKey API
- Added comprehensive error handling and validation
- Improved browser compatibility with standardized cryptographic operations
- This update strengthens the existing security foundation with modern cryptographic practices while maintaining full system compatibility.
- Added SecureNotificationManager with cross-browser support (Chrome, Firefox, Safari, Edge)
- Integrated WebRTC message notifications with tab visibility detection
- Implemented XSS protection, URL validation, and rate limiting
- Notifications shown only when chat tab is inactive
- Enforced HTTPS and user gesture requirements
- Cache only essential PWA assets (manifest, icons, core scripts)
- Use Network First for all other requests
- Remove aggressive caching of UI components and styles
- Preserve PWA installation while minimizing cache footprint
- implemented glowing border effect on cards when cursor is near
- multiple cards can glow simultaneously within proximity
- smooth fade-out without flicker on mouse leave
- improved hover animation for better user experience
- Removed temporary console logs used for debugging
- Disabled DEBUG_MODE flag
- Updated configuration to run in production mode
- Cleaned up leftover debug utilities to reduce noise in console
- Improve installation status detection logic
- Add proper DOM cleanup when PWA is installed
- Enhance monitoring for installation state changes
- Fix shouldShowPrompt() logic to always check current status
- Add forceInstallationCheck() method for manual status updates
- Add manifest.json with full PWA configuration
- Support for installation on all platforms (iOS, Android, Desktop)
- Custom app icons (72x72 to 512x512) with maskable support
- App shortcuts for quick actions (Create/Join Channel)
- Protocol handlers for web+securebit:// links
- Share target integration
- Implement enhanced Service Worker (v4.0)
- Smart caching strategies (cache-first, network-first, stale-while-revalidate)
- Security-aware caching (excludes sensitive endpoints)
- Background sync for failed requests
- Offline fallbacks with custom error handling
- Response cloning fixes and CORS handling
- Add PWA Install Prompt Manager
- Cross-platform install detection and prompts
- iOS Safari specific installation guide
- Smart dismissal logic with retry mechanisms
- Install success notifications and user guidance
- Persistent install preferences with localStorage
- Implement comprehensive Offline Manager
- IndexedDB for offline data persistence
- Automatic message queuing and sync when online
- Session state recovery after connection loss
- WebRTC reconnection handling
- Real-time connection status indicators
- Offline guidance and help system
- Add offline-first features
- Message queue with priority and retry logic
- Session data preservation during disconnection
- Application state recovery
- Background sync registration
- Periodic cleanup of old offline data
- Enhanced user experience
- Connection status notifications
- Offline mode guidance and help
- Automatic sync notifications
- Reconnection progress indicators
- Platform-specific installation instructions
This implementation ensures SecureBit.chat works seamlessly offline while maintaining security and providing a native app-like experience across all platforms.
lockbitchat