Signal Protocol end-to-end encryption and AES-256 everywhere
SANKET (Sanket.Chat) by Tosh Defence encrypts every message, reaction and encrypted broadcast end to end with the Signal Protocol through Signal's official, independently audited libsignal, using PQXDH key agreement and the Double Ratchet with SPQR. Files, call frames, call transport, local storage and every TLS session the installation terminates use AES-256, with no AES-128 fallback and no compatibility mode.
AES-256 or fail is SANKET's engineering policy, enforced in code. If encryption cannot be performed exactly as designed, the operation is refused rather than weakened.
Messages: the Signal Protocol, unmodified
SANKET uses Signal's official libsignal library for all message encryption, at the same release on iOS, Android, desktop and server. It contains no reimplementation of the Signal Protocol and no alternative message cipher.
Sessions are established with PQXDH, the post-quantum extension of X3DH, combining X25519 agreements with a Kyber encapsulation. Messages are then encrypted with the Double Ratchet: each message key is expanded into an AES-256 key, an HMAC-SHA256 key and an IV, the message is encrypted with AES-256 and authenticated with HMAC-SHA256, and the key is deleted after use. Signal's Sparse Post-Quantum Ratchet runs alongside for every session.
No fallback, by design
A client refuses to send if libsignal encryption cannot be performed. Devices that do not publish a libsignal identity key are skipped rather than sent plaintext, legacy plaintext markers are rejected, and the server refuses key bundles that do not follow the libsignal format. There is no plaintext or alternative-cipher path for message content.
Groups without a shared key
Group messages are encrypted by pairwise fan-out: the sending device encrypts the message separately for every trusted device of every member, each through its own libsignal session. Membership changes need no re-keying, and a removed member is simply no longer in the fan-out list.
Before encrypting, a sender checks each recipient account's device list, signed by that account's own key, and sends nothing to a device that is not on it.
Files and calls
Attachment content, names and types are encrypted on the device with AES-256-GCM under a random 256-bit key per file, and that key travels inside the libsignal message.
Voice and video are protected twice. Each participant's frames are encrypted end to end with AES-256-GCM under a per-sender key that ratchets every 200 milliseconds, giving five new frame keys per second for each sender, with a fresh random key on every join or leave. Between each device and the media server, SRTP accepts only AEAD_AES_256_GCM. The media server forwards encrypted frames it cannot decrypt, and the design excludes server-side call recording.
- AES-256-GCM per file
- Per-sender call keys, never a shared room key
- Five frame keys per second per sender
- SRTP AES-256-GCM only
Transport and storage
Every client connection uses TLS 1.3 with TLS_AES_256_GCM_SHA384, or TLS 1.2 with ECDHE and AES-256-GCM for platform network stacks that require it. AES-128, ChaCha20, CBC-mode suites and static RSA are excluded, and the hybrid post-quantum group X25519MLKEM768 is offered first. Every approved device can also prove itself with its own client certificate through mutual TLS.
On devices, local databases are encrypted with AES-256 and authenticated with HMAC-SHA256, and on phones the protocol store and device secrets are encrypted under a hardware-backed key in the Secure Enclave, StrongBox or the trusted execution environment.
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.
Does SANKET use the Signal Protocol?
Yes. SANKET encrypts all messages with Signal's official libsignal library on every platform, using PQXDH key agreement and the Double Ratchet with SPQR. It contains no reimplementation of the protocol.
Is SANKET AES-256 encrypted messaging?
Yes. Messages use AES-256-CBC with HMAC-SHA256 inside libsignal; files, call frames, call transport, local storage and TLS use AES-256-GCM. There is no AES-128 fallback.
Are voice and video calls end-to-end encrypted?
Yes. Call frames are encrypted end to end with AES-256-GCM under per-sender keys delivered over libsignal, with five new frame keys per second for each sender, inside SRTP that accepts only AES-256-GCM.
Are reactions and broadcasts encrypted?
Yes. Reactions and encrypted broadcasts are libsignal messages, encrypted end to end like every other message. A broadcast's priority, deadline and expiry are inside the encryption too.
Does SANKET use Sender Keys for groups?
No. SANKET encrypts group messages separately for every trusted device of every member, each through its own libsignal session, so there is no shared group key.
Which TLS versions does SANKET accept?
TLS 1.3 is preferred, with TLS_AES_256_GCM_SHA384 only. TLS 1.2 is accepted only with ECDHE and AES-256-GCM. Nothing below TLS 1.2 is accepted, and the hybrid post-quantum key exchange X25519MLKEM768 is offered first.
Is libsignal audited?
Yes. SANKET is built on Signal's independently audited libsignal library, and the PQXDH protocol has been formally analysed.
Review SANKET's cryptography with our engineers
Tosh Defence walks security architects and evaluation committees through the cryptographic design, layer by layer, with the controlled whitepaper edition available under a non-disclosure agreement.