SANKET vs SalaX Secure Messaging compared
SalaX Secure Messaging and SANKET both serve regulated organisations and both deploy on-premises and air-gapped with customer-owned keys. SANKET is built on Signal Protocol with post-quantum PQXDH and SPQR, AES-256 on every layer, signed device lists, device mutual TLS and FIDO2 administrator keys, built and supported in India.
About SalaX Secure Messaging
SSH Communications Security Oyj · Finland
SalaX Secure Messaging is the real-time messaging part of SalaX Secure Collaboration from SSH Communications Security, the Finnish company behind the original SSH protocol. It is built on the Element platform and the Matrix standard with Olm and Megolm encryption, and is offered as SaaS from a European cloud or self-hosted, including air-gapped, with customer-owned keys.
SANKET vs SalaX Secure Messaging: side by side
| Criterion | SANKET | SalaX Secure Messaging |
|---|---|---|
| Who controls the infrastructure | The customer. One dedicated installation per organisation, on infrastructure it owns or chooses, with no vendor-operated service in the message path. | The customer (on-premises, private or public cloud) or SaaS from a European cloud. |
| Deployment options | Dedicated installation on any cloud in any region the customer chooses (or Tosh Defence hosting), customer on-premise, or fully air-gapped; single host or high availability with second-site recovery. | SaaS, on-premises, private cloud, public cloud, air-gapped and out of band. |
| Who holds keys and identity | The customer and its users. Keys are generated on each device and protected by hardware-backed storage; identities are customer-controlled Sanket IDs, with no consumer phone-number identity required. | Customer-owned encryption keys (vendor). Phone number requirement: not publicly documented. |
| Encryption protocol | Signal Protocol through Signal's official, independently audited libsignal. Messages AES-256-CBC with HMAC-SHA256 inside libsignal; files and calls AES-256-GCM; TLS with AES-256-GCM suites only. | Matrix with Olm and Megolm, AES-256; built on the Element platform. |
| Post-quantum protection | Yes, in the current release: PQXDH with a mandatory post-quantum Kyber prekey and the SPQR ratchet (Triple Ratchet), plus hybrid X25519MLKEM768 key exchange at the TLS edge. | Not publicly documented |
| Groups and calls end-to-end encrypted by default | Yes. One-to-one and group messages, reactions, encrypted broadcasts and files are always end-to-end encrypted; voice and video calls use AES-256-GCM frame encryption with five new frame keys per second, inside SRTP AES-256-GCM. | Vendor states end-to-end encrypted chats, audio and video calls and file transfers. |
| Customer identity provider (SSO / LDAP) | Yes. Sign-in through the customer's own OIDC, SAML 2.0 or LDAP directory, SCIM 2.0 provisioning, and FIDO2 security keys for administrators. | Verification by MFA, OTP, PIN, SSO or bank ID (SalaX Secure Collaboration). |
| Admin controls and device governance | Device approval and revocation, lost mode and remote wipe, signed device lists, device mutual TLS, retention, forwarding and clipboard policy, customer-defined classification labels and a hash-chained audit log for the customer's SIEM. | Cross-signed device verification; audit bot and record-keeping. |
| Data sovereignty (jurisdiction, built in India) | Built in India by Tosh Defence. Data stays in the jurisdiction and on the infrastructure the customer chooses, with no third-party analytics and no foreign runtime dependency in the products. | SSH Communications Security Oyj, Helsinki, Finland; deployment in specific EU or national regions. |
| Release integrity and update control | Ed25519-signed releases verified before install, with release freeze and rollback protection and automatic rollback on a failed upgrade. The customer decides when to upgrade, online or with a signed offline package. | Not publicly documented |
| Platforms | Native apps for iOS, Android, Windows, macOS and Linux. Browser-free by design: there is no web client to attack. | Desktop, mobile and web apps. |
Who controls the infrastructure
SANKET
The customer. One dedicated installation per organisation, on infrastructure it owns or chooses, with no vendor-operated service in the message path.
SalaX Secure Messaging
The customer (on-premises, private or public cloud) or SaaS from a European cloud.Deployment options
SANKET
Dedicated installation on any cloud in any region the customer chooses (or Tosh Defence hosting), customer on-premise, or fully air-gapped; single host or high availability with second-site recovery.
SalaX Secure Messaging
SaaS, on-premises, private cloud, public cloud, air-gapped and out of band.Who holds keys and identity
SANKET
The customer and its users. Keys are generated on each device and protected by hardware-backed storage; identities are customer-controlled Sanket IDs, with no consumer phone-number identity required.
SalaX Secure Messaging
Customer-owned encryption keys (vendor). Phone number requirement: not publicly documented.Encryption protocol
SANKET
Signal Protocol through Signal's official, independently audited libsignal. Messages AES-256-CBC with HMAC-SHA256 inside libsignal; files and calls AES-256-GCM; TLS with AES-256-GCM suites only.
SalaX Secure Messaging
Matrix with Olm and Megolm, AES-256; built on the Element platform.Post-quantum protection
SANKET
Yes, in the current release: PQXDH with a mandatory post-quantum Kyber prekey and the SPQR ratchet (Triple Ratchet), plus hybrid X25519MLKEM768 key exchange at the TLS edge.
SalaX Secure Messaging
Not publicly documentedGroups and calls end-to-end encrypted by default
SANKET
Yes. One-to-one and group messages, reactions, encrypted broadcasts and files are always end-to-end encrypted; voice and video calls use AES-256-GCM frame encryption with five new frame keys per second, inside SRTP AES-256-GCM.
SalaX Secure Messaging
Vendor states end-to-end encrypted chats, audio and video calls and file transfers.Customer identity provider (SSO / LDAP)
SANKET
Yes. Sign-in through the customer's own OIDC, SAML 2.0 or LDAP directory, SCIM 2.0 provisioning, and FIDO2 security keys for administrators.
SalaX Secure Messaging
Verification by MFA, OTP, PIN, SSO or bank ID (SalaX Secure Collaboration).Admin controls and device governance
SANKET
Device approval and revocation, lost mode and remote wipe, signed device lists, device mutual TLS, retention, forwarding and clipboard policy, customer-defined classification labels and a hash-chained audit log for the customer's SIEM.
SalaX Secure Messaging
Cross-signed device verification; audit bot and record-keeping.Data sovereignty (jurisdiction, built in India)
SANKET
Built in India by Tosh Defence. Data stays in the jurisdiction and on the infrastructure the customer chooses, with no third-party analytics and no foreign runtime dependency in the products.
SalaX Secure Messaging
SSH Communications Security Oyj, Helsinki, Finland; deployment in specific EU or national regions.Release integrity and update control
SANKET
Ed25519-signed releases verified before install, with release freeze and rollback protection and automatic rollback on a failed upgrade. The customer decides when to upgrade, online or with a signed offline package.
SalaX Secure Messaging
Not publicly documentedPlatforms
SANKET
Native apps for iOS, Android, Windows, macOS and Linux. Browser-free by design: there is no web client to attack.
SalaX Secure Messaging
Desktop, mobile and web apps.Where SANKET leads
- Signal Protocol with post-quantum PQXDH and SPQR for all messaging.
- AES-256 everywhere: messages through libsignal, files and calls with AES-256-GCM, and TLS with AES-256-GCM suites only.
- Signed device lists, device mutual TLS and FIDO2 security keys for administrators.
- Built and supported in India, with offline licensing and offline release bundles for air-gapped estates.
- Release integrity: signed manifests with rollback and freshness protection.
Frequently asked questions
Where is SalaX Secure Messaging from?
Finland. It is part of SalaX Secure Collaboration from SSH Communications Security Oyj in Helsinki. SANKET (Sanket.Chat) by Tosh Defence is built and supported in India.
How does SANKET's encryption differ?
SANKET uses Signal Protocol through Signal's official libsignal with post-quantum PQXDH and SPQR, and AES-256 for messages, files, calls and transport.
Does SANKET let the customer own the keys?
Yes. Keys are generated on users' devices and protected by hardware-backed storage, and the server relays ciphertext without ever holding the keys to messages, files or calls.
Sources
- SANKET Technical Security & Architecture Whitepaper, public edition 2.0 (7 October 2026)
- SSH: SalaX Secure Messaging initial installations and Matrix Foundation membership (28 April 2025)
- SSH: SalaX Secure Messaging
- SSH: Secure collaboration with data sovereignty
- SSH: SalaX Secure Collaboration sales sheet 2025
Sources checked on 7 October 2026. Competitor facts are taken only from the sources listed. Where no public source was found, the cell reads 'Not publicly documented'. Product and company names are trademarks of their respective owners.
Put your communications under your own control
Talk to the Tosh Defence team about your deployment, from a dedicated cloud installation to a fully air-gapped estate, or read the full security architecture first.