Privacy is an architecture decision, not a policy document
Sanket is built on the assumption that the server cannot be trusted. Zero-knowledge architecture, Signal Protocol encryption, and layered privacy controls mean your communication remains private by design - not by promise.
Zero-Knowledge Server
Server stores ciphertext only
9 Cryptographic Layers
From key exchange to storage
Perfect Forward Secrecy
Per-message key rotation
No Advertising Model
Zero metadata profiling
Core Architecture
Zero-Knowledge Server Architecture
A zero-knowledge server stores and relays only encrypted data - it holds ciphertext it cannot read. This means the platform operator, server administrator, and any party with server access cannot read your messages, even under a court order.
Traditional server model
Alice types a message
Plaintext on device
Message sent over HTTPS
Encrypted in transit only
Server decrypts and stores
Server holds plaintext
Server re-encrypts for Bob
Server re-signs message
Server has full access
Operator can read all messages
The server operator can read every message. Any breach, court order, or insider threat exposes all communication.
Sanket zero-knowledge model
Alice types a message
Plaintext on device
Message encrypted on device
Using Bob's public key via Signal Protocol
Ciphertext sent to server
Server receives encrypted blob only
Server stores ciphertext
Cannot decrypt - no private keys
Bob's device decrypts locally
Plaintext only on recipient's device
The server operator has zero access to message content. Breach, court order, or insider threat cannot expose plaintext.
What zero-knowledge architecture guarantees
Operator cannot read messages
Tosh Defence Private Limited cannot read your organisation's communication content - not now, not under any legal process against the platform operator.
Server breach cannot expose content
If an attacker compromises the Sanket server, they obtain ciphertext only. Without private keys (which never leave devices), content cannot be decrypted.
Private keys never leave devices
Identity keys, session keys, and message keys are generated on and stored on the user's device. The server never holds or sees private key material.
Past sessions are permanently protected
Perfect Forward Secrecy means ephemeral keys used for past sessions are not retained. Compromising today's key cannot decrypt yesterday's conversation.
No metadata profiling possible
With no plaintext access, the server cannot perform content analysis, keyword scanning, sentiment analysis, or any form of message intelligence.
No single point of decryption failure
There is no master key that unlocks all messages. Each session is independently encrypted. Compromise is always limited to individual sessions.
Double Ratchet Algorithm
Perfect Forward Secrecy
Signal Protocol's Double Ratchet algorithm generates a new cryptographic key for every single message. Keys are ephemeral - used once and discarded. This property, called Perfect Forward Secrecy (PFS), means that compromising a key today cannot decrypt messages sent in the past.
For sensitive organisations facing persistent adversaries - state-level threat actors, long-term corporate espionage, or sustained intelligence collection - PFS is not optional. It is the difference between a limited incident and total historical exposure.
Session Start
X3DHX3DH key agreement establishes the initial session using identity keys, signed pre-keys, and one-time pre-keys. No pre-shared secret required.
Each Message
DH RatchetThe Diffie-Hellman ratchet advances with every message exchange, generating new ephemeral key material. Each message uses a unique key derived from the previous ratchet state.
Key Derivation
HKDFHKDF-SHA256 derives symmetric encryption and MAC keys from each ratchet output. Message keys are never reused - once used, they are deleted from memory.
Past Messages
PFSDeleted session keys cannot be regenerated. Even if an adversary later compromises a device's long-term identity key, they cannot use it to decrypt past session traffic.
Cryptographic Specification
Encryption algorithms in Sanket
Every layer of communication in Sanket uses published, peer-reviewed cryptographic standards - no proprietary algorithms, no security-by-obscurity.
| Layer | Algorithm | Standard | Key Length | What It Protects |
|---|---|---|---|---|
| Key Agreement | X3DH (Extended Triple Diffie-Hellman) | Signal Protocol | 255-bit (Curve25519) | Initial key exchange without pre-shared secrets |
| Message Encryption | AES-256-GCM | NIST FIPS 197 | 256-bit | Message content confidentiality and integrity |
| Session Keys | Double Ratchet Algorithm | Signal Protocol | 256-bit per ratchet step | Perfect Forward Secrecy - past sessions survive key compromise |
| Transport Layer | TLS 1.3 | RFC 8446 | 256-bit (ECDHE) | Metadata protection and MITM prevention |
| Certificate Pinning | SHA-256 Pin Validation | RFC 7469 | N/A | Network-level interception prevention |
| Key Derivation | HKDF-SHA256 | RFC 5869 | 256-bit output | Cryptographically isolated key material per session |
| Authentication | HMAC-SHA256 | RFC 2104 | 256-bit | Message authenticity and tamper detection |
| Key Storage | Secure Enclave / StrongBox | Platform TEE | Hardware-bound | Physical key extraction resistance |
| Elliptic Curve | Curve25519 / Ed25519 | RFC 8032 / RFC 8031 | 255-bit | Key authenticity and identity verification |
All algorithms are publicly specified open standards. Sanket uses zero proprietary cryptographic implementations.
Layered Controls
Privacy controls at every level
Administrator Controls
User provisioning and de-provisioning - only approved identities can access the platform
Instant access revocation - remove any user from all groups and channels immediately
Group and channel governance - create, manage, and restrict team communication structures
Device trust management - approve, audit, and remotely wipe registered devices
Configurable message retention - set organisation-wide or channel-specific retention periods
Audit log access - visibility into user access events and administrative changes
User Controls
Disappearing messages - set automatic deletion timers per conversation
Screenshot prevention - restrict screen capture within the app on supported platforms
Read receipts control - opt in or out of delivery and read confirmation signals
Active session management - view and terminate sessions on all logged-in devices
Notification content privacy - hide message previews from lock screen notifications
Biometric app lock - require fingerprint or face authentication to access the app
Organisation Data Controls
Data residency selection - choose the geographic region where your deployment data is processed
GDPR Data Processing Agreement - formal DPA available for all Sanket.Work deployments
Retention policy enforcement - administrators set and enforce retention periods organisation-wide
No advertising or profiling - zero commercial data extraction from communication content or metadata
Export and portability - data export capability for subject access requests and portability rights
Erasure procedures - data deletion capability for GDPR right-to-erasure compliance
Regulatory Alignment
GDPR-aligned communication by design
GDPR compliance for communication platforms is not achieved by checking boxes - it requires the right architecture. Sanket's zero-knowledge design, data residency options, and formal DPA support are built for organisations with controller obligations under GDPR.
Request GDPR DocumentationData Minimisation
Sanket collects only the data necessary for communication. No advertising profile, no behavioural tracking, no unnecessary metadata retention.
Right to Erasure
Administrators can action deletion of user data. Disappearing messages auto-delete. Account deletion removes user content from the platform.
Data Portability
Organisation data export is available for GDPR compliance. Users can export their communication history in structured formats.
Privacy by Design
Zero-knowledge server architecture means privacy is the default state - not a configuration. The server cannot read message content under any circumstance.
Data Processor Agreement
Formal GDPR-compliant Data Processing Agreement available for all Sanket.Work deployments. Tosh Defence acts as processor under your controller responsibility.
Security of Processing
Signal Protocol end-to-end encryption, TLS 1.3 transport, hardware-backed key storage, and certificate pinning collectively satisfy Article 32 technical measures.
International Transfers
Data residency options allow processing within the EU/EEA. On-premise Sanket.Enterprise deployments keep data entirely within the customer's jurisdiction.
Business Model
Your communication is not a product
Consumer messaging platforms derive revenue from advertising - which requires understanding user behaviour. Sanket has no advertising model and no incentive to analyse or monetise your communication.
Consumer messaging platform
Advertising revenue depends on understanding user behaviour
Message metadata (who, when, how often) is commercially valuable
Contact graph analysis serves targeted advertising
Terms of service allow broad data use for 'improving services'
Free service means the user's attention and data is the product
Sanket
Revenue comes from deployment and subscription - not data
Zero commercial incentive to analyse communication metadata
No advertising integrations in platform code or infrastructure
No third-party analytics SDKs in the Sanket application
Customer pays for a service - their data remains their property
Evaluate Sanket's privacy architecture for your organisation
Request a technical deep-dive with the Tosh Defence team. We cover zero-knowledge architecture, encryption specification, GDPR DPA, and deployment options for your specific compliance requirements.