lockbitchat
c98a01b1d5
- 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.
2.2 KiB
2.2 KiB
Security Architecture
Current baseline
| Area | Current behavior |
|---|---|
| Protocol | 4.1 with mismatch rejection |
| Peer verification | mandatory manual SAS entry |
| Transport | WebRTC over DTLS |
| Privacy mode | optional TURN relay-only mode |
| Message UI safety | incoming decrypted text sanitized before display |
| File transfer | validated metadata, explicit consent, allowlist policy |
| Voice messages | same chunked AES-GCM transfer as files; auto-accepted and played inline |
| Local metadata | encrypted IndexedDB envelopes with migration |
| Lifecycle | unified disconnect cleanup and bounded resource retention |
Verification state machine
connection established
↓
shared keys derived
↓
deterministic SAS displayed
↓
manual out-of-band comparison
↓
local input validated
↓
peer confirmation received
↓
verified session
The verified state is reached only when both local and remote confirmation flags are true.
File-transfer architecture
- sender emits metadata
- receiver validates name, size, type, and abuse limits
- receiver sees Accept / Reject prompt
- no receive buffers are allocated before acceptance
- sender transmits chunks only after acceptance
- completed received buffers are retained within a bounded window
Voice messages
Voice notes reuse the file-transfer pipeline, so they inherit its per-file AES-GCM session key, chunking, and SHA-256 integrity check. Differences from a regular file:
- audio is recorded in-browser and encoded as PCM/WAV before sending
- duration and a downsampled waveform travel as unsigned presentation metadata; the audio bytes remain integrity-protected by the signed file hash
- the receiver auto-accepts voice transfers (no consent prompt) and plays them inline from an in-memory blob — nothing is written to disk
Disconnect cleanup
The canonical disconnect path clears:
- WebRTC channels and peer connection handles
- timers, deferred retries, fake traffic, and decoy traffic
- pending transfer state and consent waits
- verification state and crypto/PFS state
- React file-transfer callbacks and stale UI transfer state