Layered security
Chat256 does not rely on a single security feature. Client-side encryption protects supported content, authenticated identity establishes who is authorised to act, secure transport protects network connections, and application controls manage sessions, media access, quotas and expiry.
Cryptographic building blocks
| Primitive | Role |
|---|---|
| ECDSA P-256 | Identity and signature verification in authenticated application flows. |
| ECDH P-256 | Shared-key agreement for supported private-message encryption. |
| HKDF-SHA256 | Key derivation for protected message encryption. |
| AES-256-GCM | Confidentiality and integrity for supported encrypted messages and media. |
| HTTPS / WSS | Encrypted transport between the browser and service. |
Identity and authenticated sessions
Chat256 uses persistent browser identity and authenticated sessions to connect a user to authorised application activity. Session state is checked against identity, public-key consistency, account status and expiry.
Authentication challenges are single-use and signed proof-of-possession is used in sensitive application flows. This gives the service a way to enforce authority without requiring private cryptographic keys to be sent to the server.
Private messaging
Supported private messages are encrypted in the browser before the protected envelope is transmitted. ECDH P-256 establishes shared key material, HKDF-SHA256 derives the encryption key and AES-256-GCM protects the message.
The service can relay and manage protected envelopes without the normal private-message workflow requiring readable message plaintext on the application server.
Encrypted files and media
Files and media use a dedicated transfer layer with client-side encryption, chunked transfer, authenticated access, progress handling, quotas, expiry and deletion controls. Transfer identifiers and access tokens are designed to bind media operations to authorised application context.
Private voice and video calls
WebRTC provides encrypted media transport while Chat256 signalling coordinates call setup. ICE, STUN and TURN support real-world network traversal, including connections where direct peer connectivity is unavailable.
Administrative security
The administrative control plane uses a dedicated authentication boundary with Argon2id password verification, IP/CIDR controls, CSRF protection, login limiting, audit events and encrypted settings. Administrative permissions are separate from ordinary user permissions.
Web application protection
The public and application layers use controls including Content Security Policy, frame protection, MIME-sniffing protection, Referrer-Policy, Permissions-Policy and HTTPS enforcement where enabled. Server operations use prepared database queries, normalised error responses and request identifiers for diagnostics.
Privacy in the real world
Encryption protects supported content; it does not make a device, recipient or network invisible. Protect your device, browser, recovery material and invitation links. Treat anyone who can legitimately open a conversation or file as someone who can potentially preserve a copy.
Why the architecture matters
The security model is designed to put the most sensitive cryptographic work in the client while keeping the server focused on authenticated delivery, access control, expiry, abuse prevention and service reliability. That separation is central to the Chat256 product.