lockbitchat
e3e10656d7
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.
1.6 KiB
1.6 KiB
Documentation
Technical documentation for SecureBit.chat. Start with the project README if you are looking for an overview or a quick start.
| Document | What it covers |
|---|---|
| ARCHITECTURE.md | How a session is established, verified and torn down, and where each guarantee comes from |
| CRYPTOGRAPHY.md | Key schedule, the Double Ratchet, SAS verification, memory handling |
| DESCRIPTOR-SBQ2.md | The invitation format: wire layout, why it is small, the in-band key exchange, decoder rules |
| CONFIGURATION.md | Deployment, ICE and TURN setup, privacy modes, file transfer policy |
| CALLS.md | Voice and video: codec choices, adaptation, and why each value was picked |
| API.md | Internal interfaces of the WebRTC manager and file transfer system |
| CONTRIBUTING.md | Development workflow and what needs extra review |
| USE-POLICY.md | Terms of use, intended use, and the limits of what the software can protect |
Security policy and vulnerability reporting live in SECURITY.md at the repository root, where GitHub expects to find them.
Keeping this accurate
These documents describe the current release and are expected to change with it. Every value quoted here (limits, timeouts, algorithm parameters) is taken from the source rather than restated from memory, so if you change one in code, change it here in the same commit. CONTRIBUTING.md lists which documents are affected by which areas of the code.