Sanket.Chat
Security: server-blind

Server-blind architecture: the server relays ciphertext

SANKET (Sanket.Chat) by Tosh Defence is server-blind: the server relays ciphertext and never holds the keys to messages, files, calls, reactions or encrypted broadcasts. Content is encrypted on the sending device and decrypted only on the recipients' devices, so neither Tosh Defence, nor a hosting provider, nor the customer's own servers can read it.

Server-blind changes what a server compromise means. An attacker who controls the server cannot read past content, because the keys never reached it, and cannot silently add a device to listen in, because senders verify each account's signed device list.

What server-blind means

In SANKET the server is a relay for encrypted content. Messages, reactions and encrypted broadcasts are libsignal messages encrypted on the sender's device; attachments are encrypted with AES-256-GCM before upload; call frames are encrypted end to end before they reach the media server. The keys for all of them are generated and kept on users' devices.

Even the label that marks a message's classification travels inside the encryption, so the server can neither read nor change it.

A compromised server reveals no content

Tosh Defence analyses the compromise of every server-side component. Across all of them, message bodies, reactions, encrypted broadcasts, classification labels, file contents, call media and private keys remain protected, because content confidentiality never depends on a server component remaining uncompromised.

Recovery follows one pattern: rebuild from a verified, signed release, rotate server-side secrets, force re-authentication and review the tamper-evident audit record.

  • Message bodies and reactions
  • Encrypted broadcasts and their priority
  • Classification labels
  • File contents
  • Call media
  • Private keys

No silent listeners

Each account's device list is signed by a key held on the account's own primary device, with an append-only log on the installation. Before encrypting, a sender checks that list and sends nothing to a device that is not on it, so a hostile server cannot add a device to receive copies. Safety numbers and identity-change notices let users verify each other directly.

Inside your installation

SANKET is never a shared public service. Each organisation runs its own dedicated installation, so the routing metadata needed to deliver messages stays inside the customer's own installation, under its own administrators, retention policy and audit.

Administrators govern identities, devices and policy; they hold no content keys and cannot read conversations.

Technical proof

Read the detail in the SANKET whitepaper

Every statement on this page is set out in full in the public SANKET Technical Security and Architecture Whitepaper, free to read without registration.

FAQ

Frequently asked questions

Ask our team a question

What does server-blind mean?

Server-blind means the server relays ciphertext and never holds the keys to messages, files, calls, reactions or encrypted broadcasts. Content is readable only on the devices of the people in the conversation.

Can Tosh Defence read customer messages?

No. Tosh Defence does not operate customer installations and has no access path into them, and message content is end-to-end encrypted with keys that exist only on users' devices.

Can customer administrators read messages?

No. Administrators govern identities, devices and policy. The server holds no content keys, so administrators cannot read messages, files or calls.

What happens if a SANKET server is compromised?

Past message and file content stays confidential, because it was encrypted with keys the server never held. Signed device lists stop the attacker from adding a device to receive copies, and safety numbers let users verify identities.

Can the server change or replay a broadcast?

No. An encrypted broadcast's priority, acknowledgement deadline and expiry travel inside the end-to-end encryption, so the server can neither downgrade nor replay it.

Where does routing metadata go?

The routing metadata needed to deliver messages stays inside the customer's own dedicated installation, governed by its own retention policy and audit.

See how a server-blind design changes your threat model

Tosh Defence briefs security architects on SANKET's server compromise analysis, device trust and metadata handling.