Security at ChatCoreHub
Private conversations need more than a lock icon.
ChatCoreHub combines end-to-end encryption, encrypted local storage, authenticated devices, and short-lived server relays. This page explains what each layer does, what the server can still see, and how the upcoming encrypted history transfer is designed to work.
01
Messages and attachments
Content is protected before it leaves the client.
Direct conversations
Each ChatCoreHub device has its own messaging identity and publishes a public pre-key bundle. A sender uses those public keys to establish a Signal Protocol session for each destination device. The server receives an encrypted envelope for delivery, not the readable message.
Multi-device delivery is deliberate: a message is encrypted separately for the recipient's registered devices and for the sender's other devices, so those devices can continue the conversation without sharing one permanent private key.
Group conversations
Group messages use versioned 256-bit AES-GCM group keys. Key material is wrapped separately for the registered devices of current members. Membership and device changes can require new key coverage or key rotation before sending continues.
The server stores encrypted group messages and wrapped device-specific key records, but it does not receive the usable group key in plaintext.
Files, photos, and voice notes
Attachments are encrypted with AES-GCM before upload. The key, nonce, authentication information, filename, and other details required by the recipient travel inside the encrypted conversation payload. The stored attachment bytes are therefore not useful without the conversation's decryption material.
02
Your devices are part of the trust boundary
Every installation is treated as a separate cryptographic device.
ChatCoreHub registers encryption material per device rather than copying one permanent Signal private key everywhere. Account Safety shows registered secure-messaging devices and allows another device to be revoked. Removing a device stops future encrypted delivery to that registration; it does not remotely erase files already stored on that device.
Reinstalling an app, clearing browser site data, or deleting local encryption state creates a new cryptographic identity. That protects against silently reusing damaged or missing keys, but it can also make older locally encrypted history unreadable until it is restored from an encrypted backup or transferred from a trusted device.
Android and Windows store cached message history in SQLCipher databases. Their random database keys are wrapped with Android Keystore and Windows DPAPI respectively. The Web client keeps browser encryption state and cached history in IndexedDB; browser-profile access and cleared site data therefore remain important security boundaries.
03
Coming next: encrypted history transfer
Move readable local history without moving permanent messaging private keys.
The authenticated server protocol and encrypted relay foundation are already deployed. The remaining work is to connect the Android, Windows, and Web clients, add approval and progress screens, merge transferred history safely, and support optional attachment transfer.
- The new device creates a request.It must already be a registered device on the same account. It creates a temporary public key and receives a cryptographically random six-digit code.
- The code expires after three minutes.The code only locates a pending request. It is stored as a keyed hash, failed attempts are limited, and the encryption key is never derived from those six digits.
- One trusted device claims the request.The first registered device on the account to claim it wins atomically. A device cannot claim its own request, and the source still has to approve the transfer.
- The devices agree on a temporary transfer key.Ephemeral key agreement is performed by the clients. Permanent Signal private keys are never uploaded, copied, or used as the transfer payload.
- History is encrypted in independent chunks.Each chunk is protected with AES-256-GCM using a fresh 96-bit nonce and a 128-bit authentication tag. Associated data binds it to the transfer, chunk position, total count, protocol version, and manifest hash.
- The server acts as a temporary opaque relay.The encrypted manifest and chunks may remain available for up to 24 hours. Completion, cancellation, or expiry removes relay chunks, with background cleanup as a second enforcement path.
- The destination verifies before importing.Authentication tags and SHA-256 plaintext hashes detect tampering or corruption. History is merged by message identity while deletion records remain authoritative.
History transfer is not yet available in the public clients. The details above describe the deployed protocol foundation and the client behavior being implemented; they are published now so the security model can be reviewed before release.
04
Calls use a different security layer
Message encryption and real-time media transport are not the same protocol.
Voice and video calls use WebRTC's encrypted media transport. ChatCoreHub uses SignalR to relay call invitations and connection-negotiation messages such as offers, answers, and network candidates. The server does not intentionally record call media, but it processes the signaling and call metadata required to establish and manage a call.
The message E2EE design described above does not automatically make calls part of the Signal message protocol. We state these protections separately to avoid implying a stronger call-security property than the implementation provides.
05
Conferences add an optional encrypted mode
Group video rooms come in two flavors, and the difference is deliberate.
A conference is a group video room — with screen sharing, live chat, and file sharing — hosted through a self-hosted media server (SFU) that forwards each participant's streams to the others. It is available on the Web client today; the Windows and Android clients do not have conferences yet.
Standard rooms
In a standard conference the media is encrypted in transit on each leg, but the media server relays the streams and can therefore access the call content and the room's text chat. Standard rooms can invite people who do not have a ChatCoreHub account, through a single-use email link. Treat a standard room like a private-but-server-visible call, not like your end-to-end encrypted direct and group chats.
End-to-end encrypted rooms
When the host turns on encryption at creation, the whole room becomes end-to-end encrypted — the video, the voice, and the room chat and attachments. A per-room key is generated on the host's device and wrapped separately for each member's registered devices over their Signal sessions, so the server moves only ciphertext and never receives the room key. The media server forwards frames it cannot read. Removing a member rotates the key so they cannot read anything sent afterward. An encrypted room cannot admit account-less email guests — that is what keeps the all-or-nothing encryption safe.
Encryption protects the content of an encrypted room. It does not hide operational metadata: the participant list, join and leave times, call duration, and network addresses are still processed by the server, as with any call. Device identity also still relies on public key material discovered through the server, and there is not yet an in-room security-code comparison, so first-contact device substitution is not independently verifiable by a participant. We say the content of an encrypted conference is end-to-end encrypted — not that a conference is completely invisible to the server.
06
What encryption does not hide
Honest boundaries are part of the security design.
- Operational metadata: account, sender, recipient, group, timestamps, delivery and read state, attachment records, device registrations, invitations, and call records may be processed by the server.
- Your endpoints: someone with access to an unlocked or compromised device may read content already decrypted there.
- Your recipients: encryption cannot prevent a participant from copying, forwarding, photographing, or sharing content after receipt.
- Account systems: contacts, group membership, settings, authentication records, and operational logs are not end-to-end encrypted.
- Availability: encryption protects confidentiality and integrity; it does not guarantee that a device, network, or server will always be available.
07
Technology in use
The implementation is cross-platform, but the security boundaries stay consistent.
- Direct-message protocol
- Signal Protocol wire format through libsignal-compatible implementations, with separate device identities and pre-key bundles.
- Group and attachment encryption
- AES-256-GCM with authenticated encryption and versioned group-key coverage.
- Web cryptography
- Official Rust libsignal compiled to WebAssembly, Web Crypto for AES-GCM operations, and IndexedDB for browser-local state.
- Native local history
- SQLCipher through a shared local-cache layer; keys wrapped by Android Keystore or Windows DPAPI.
- Realtime and calling
- ASP.NET Core SignalR for realtime events and signaling; WebRTC for voice and video media.
- Conferences
- Self-hosted LiveKit SFU for group rooms; optional per-room end-to-end encryption keyed over Signal sessions, with frame encryption the server cannot read.
- Service platform
- ASP.NET Core API, SQL Server storage, React/TypeScript Web client, WinUI Windows client, and native .NET Android client.