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.

Message contentEncrypted on the sending device and decrypted on participant devices.

Server roleRoutes encrypted envelopes and stores the operational metadata needed to deliver them.

History transferServer foundation deployed; cross-client transfer UX is coming next.

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.

1ComposeYour device prepares the message or attachment.

2EncryptContent is encrypted for the conversation and its devices.

3RelayThe server routes encrypted data plus delivery metadata.

4DecryptAn authorized participant device opens the content locally.

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.

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.

Local storage protection

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.

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.

Pairing code6 digits / 3 minutes

Failed claimsMaximum 5 per window

Chunk protectionAES-256-GCM

Chunk sizeUp to 5 MB

Transfer sizeUp to 2 GB

Relay lifetimeUp to 24 hours

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.

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.

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.

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.
Service platform: ASP.NET Core API, SQL Server storage, React/TypeScript Web client, WinUI Windows client, and native .NET Android client.