SANKET frente a SalaX: comparación de mensajería segura
Tanto SalaX Secure Messaging como SANKET prestan servicio a organizaciones reguladas y pueden desplegarse en servidores propios y redes aisladas, con claves propiedad del cliente. SANKET se basa en Signal Protocol con PQXDH y SPQR poscuánticos, AES-256 en todas las capas, listas de dispositivos firmadas, autenticación mutua entre dispositivos mediante TLS y claves FIDO2 para administradores. Se desarrolla y cuenta con asistencia técnica en la India.
Acerca de SalaX Secure Messaging
SSH Communications Security Oyj · Finlandia
SalaX Secure Messaging es el componente de mensajería en tiempo real de SalaX Secure Collaboration, de SSH Communications Security, la empresa finlandesa creadora del protocolo SSH original. Se basa en la plataforma Element y el estándar Matrix, con cifrado Olm y Megolm, y se ofrece como SaaS desde una nube europea o para alojamiento propio, incluso en redes aisladas, con claves propiedad del cliente.
Sanket frente a SalaX Secure Messaging: comparativa punto por punto
| Criterio | SANKET | SalaX Secure Messaging |
|---|---|---|
| Quién controla la infraestructura | El cliente. Una instalación dedicada por organización, en una infraestructura que posee o elige, sin ningún servicio operado por el proveedor en la ruta de los mensajes. | El cliente (en sus propias instalaciones o en una nube privada o pública) o como servicio por suscripción desde una nube europea. |
| Opciones de instalación | Instalación dedicada en cualquier nube y región que elija el cliente (o alojada por Tosh Defence), en los servidores propios del cliente o completamente aislada físicamente de otras redes; en un único servidor o con alta disponibilidad y recuperación en un segundo emplazamiento. | SaaS, en servidores propios, nube privada, nube pública, redes aisladas y comunicación fuera de banda. |
| Quién tiene las claves y controla la identidad | El cliente y sus usuarios. Las claves se generan en cada dispositivo y se protegen mediante almacenamiento respaldado por hardware; las identidades son Sanket IDs controladas por el cliente, sin necesidad de identificarse mediante un número de teléfono personal. | Claves de cifrado propiedad del cliente (proveedor). Requisito de número de teléfono: no documentado públicamente. |
| Protocolo de cifrado | Signal Protocol mediante libsignal, la implementación oficial de Signal auditada de forma independiente. Los mensajes utilizan AES-256-CBC con HMAC-SHA256 dentro de libsignal; los archivos y las llamadas, AES-256-GCM; TLS solo utiliza conjuntos de cifrado con AES-256-GCM. | Matrix con Olm y Megolm, AES-256; basado en la plataforma Element. |
| Protección poscuántica | Sí, en la versión actual: PQXDH con una preclave poscuántica Kyber obligatoria y el mecanismo de avance de claves SPQR (Triple Ratchet), además de un intercambio híbrido de claves X25519MLKEM768 en el extremo TLS. | Not publicly documented |
| Grupos y llamadas cifrados de extremo a extremo de forma predeterminada | Sí. Los mensajes individuales y de grupo, las reacciones, las difusiones cifradas y los archivos siempre están cifrados de extremo a extremo; las llamadas de voz y vídeo utilizan cifrado de fotogramas AES-256-GCM con cinco claves nuevas por segundo, dentro de SRTP AES-256-GCM. | El proveedor declara que los chats, las llamadas de audio y vídeo y las transferencias de archivos están cifrados de extremo a extremo. |
| Proveedor de identidad del cliente (SSO / LDAP) | Sí. Autenticación mediante el directorio OIDC, SAML 2.0 o LDAP del propio cliente, aprovisionamiento mediante SCIM 2.0 y llaves de seguridad FIDO2 para administradores. | Verificación mediante MFA, OTP, PIN, SSO o identificación bancaria (SalaX Secure Collaboration). |
| Controles de administración y gestión de dispositivos | Aprobación y revocación de dispositivos, modo de pérdida y borrado remoto, listas de dispositivos firmadas, TLS mutuo entre dispositivos, políticas de conservación, reenvío y portapapeles, etiquetas de clasificación definidas por el cliente y un registro de auditoría encadenado mediante hashes para el SIEM del cliente. | Verificación de dispositivos mediante firmas cruzadas; bot de auditoría y conservación de registros. |
| Soberanía de los datos (jurisdicción, desarrollado en la India) | Desarrollado en la India por Tosh Defence. Los datos permanecen en la jurisdicción y la infraestructura que elija el cliente, sin análisis de terceros ni dependencia de infraestructura extranjera para ejecutar los productos. | SSH Communications Security Oyj, Helsinki, Finlandia; despliegue en regiones específicas de la UE o de cada país. |
| Integridad de las versiones y control de actualizaciones | Versiones firmadas con Ed25519 y verificadas antes de la instalación, con bloqueo de versiones, protección contra la instalación de versiones anteriores y reversión automática si falla una actualización. El cliente decide cuándo actualizar, en línea o mediante un paquete firmado sin conexión. | Not publicly documented |
| Plataformas | Aplicaciones nativas para iOS, Android, Windows, macOS y Linux. Sin navegador por diseño: no hay cliente web que pueda ser atacado. | Aplicaciones de escritorio, móviles y web. |
Quién controla la infraestructura
SANKET
El cliente. Una instalación dedicada por organización, en una infraestructura que posee o elige, sin ningún servicio operado por el proveedor en la ruta de los mensajes.
SalaX Secure Messaging
El cliente (en sus propias instalaciones o en una nube privada o pública) o como servicio por suscripción desde una nube europea.Opciones de instalación
SANKET
Instalación dedicada en cualquier nube y región que elija el cliente (o alojada por Tosh Defence), en los servidores propios del cliente o completamente aislada físicamente de otras redes; en un único servidor o con alta disponibilidad y recuperación en un segundo emplazamiento.
SalaX Secure Messaging
SaaS, en servidores propios, nube privada, nube pública, redes aisladas y comunicación fuera de banda.Quién tiene las claves y controla la identidad
SANKET
El cliente y sus usuarios. Las claves se generan en cada dispositivo y se protegen mediante almacenamiento respaldado por hardware; las identidades son Sanket IDs controladas por el cliente, sin necesidad de identificarse mediante un número de teléfono personal.
SalaX Secure Messaging
Claves de cifrado propiedad del cliente (proveedor). Requisito de número de teléfono: no documentado públicamente.Protocolo de cifrado
SANKET
Signal Protocol mediante libsignal, la implementación oficial de Signal auditada de forma independiente. Los mensajes utilizan AES-256-CBC con HMAC-SHA256 dentro de libsignal; los archivos y las llamadas, AES-256-GCM; TLS solo utiliza conjuntos de cifrado con AES-256-GCM.
SalaX Secure Messaging
Matrix con Olm y Megolm, AES-256; basado en la plataforma Element.Protección poscuántica
SANKET
Sí, en la versión actual: PQXDH con una preclave poscuántica Kyber obligatoria y el mecanismo de avance de claves SPQR (Triple Ratchet), además de un intercambio híbrido de claves X25519MLKEM768 en el extremo TLS.
SalaX Secure Messaging
Not publicly documentedGrupos y llamadas cifrados de extremo a extremo de forma predeterminada
SANKET
Sí. Los mensajes individuales y de grupo, las reacciones, las difusiones cifradas y los archivos siempre están cifrados de extremo a extremo; las llamadas de voz y vídeo utilizan cifrado de fotogramas AES-256-GCM con cinco claves nuevas por segundo, dentro de SRTP AES-256-GCM.
SalaX Secure Messaging
El proveedor declara que los chats, las llamadas de audio y vídeo y las transferencias de archivos están cifrados de extremo a extremo.Proveedor de identidad del cliente (SSO / LDAP)
SANKET
Sí. Autenticación mediante el directorio OIDC, SAML 2.0 o LDAP del propio cliente, aprovisionamiento mediante SCIM 2.0 y llaves de seguridad FIDO2 para administradores.
SalaX Secure Messaging
Verificación mediante MFA, OTP, PIN, SSO o identificación bancaria (SalaX Secure Collaboration).Controles de administración y gestión de dispositivos
SANKET
Aprobación y revocación de dispositivos, modo de pérdida y borrado remoto, listas de dispositivos firmadas, TLS mutuo entre dispositivos, políticas de conservación, reenvío y portapapeles, etiquetas de clasificación definidas por el cliente y un registro de auditoría encadenado mediante hashes para el SIEM del cliente.
SalaX Secure Messaging
Verificación de dispositivos mediante firmas cruzadas; bot de auditoría y conservación de registros.Soberanía de los datos (jurisdicción, desarrollado en la India)
SANKET
Desarrollado en la India por Tosh Defence. Los datos permanecen en la jurisdicción y la infraestructura que elija el cliente, sin análisis de terceros ni dependencia de infraestructura extranjera para ejecutar los productos.
SalaX Secure Messaging
SSH Communications Security Oyj, Helsinki, Finlandia; despliegue en regiones específicas de la UE o de cada país.Integridad de las versiones y control de actualizaciones
SANKET
Versiones firmadas con Ed25519 y verificadas antes de la instalación, con bloqueo de versiones, protección contra la instalación de versiones anteriores y reversión automática si falla una actualización. El cliente decide cuándo actualizar, en línea o mediante un paquete firmado sin conexión.
SalaX Secure Messaging
Not publicly documentedPlataformas
SANKET
Aplicaciones nativas para iOS, Android, Windows, macOS y Linux. Sin navegador por diseño: no hay cliente web que pueda ser atacado.
SalaX Secure Messaging
Aplicaciones de escritorio, móviles y web.En qué destaca Sanket
- Signal Protocol con PQXDH y SPQR poscuánticos para toda la mensajería.
- AES-256 en todas partes: mensajes mediante libsignal, archivos y llamadas con AES-256-GCM, y TLS exclusivamente con conjuntos de cifrado AES-256-GCM.
- Listas de dispositivos firmadas, TLS mutuo entre dispositivos y llaves de seguridad FIDO2 para administradores.
- Desarrollado y respaldado en la India, con licencias sin conexión y paquetes de versiones sin conexión para entornos aislados físicamente de otras redes.
- Integridad de las versiones: manifiestos firmados con protección contra la reversión a versiones anteriores y la reutilización de manifiestos obsoletos.
Preguntas frecuentes
¿De dónde es el servicio de mensajería segura SalaX?
Finlandia. Forma parte de SalaX Secure Collaboration, de SSH Communications Security Oyj, con sede en Helsinki. SANKET (Sanket.Chat), de Tosh Defence, se desarrolla y cuenta con soporte en India.
¿En qué se diferencia el cifrado de Sanket?
SANKET utiliza Signal Protocol mediante la biblioteca oficial libsignal de Signal, con PQXDH y SPQR poscuánticos, y AES-256 para mensajes, archivos, llamadas y transporte.
¿Permite SANKET que el cliente sea propietario de las claves?
Sí. Las claves se generan en los dispositivos de los usuarios y se protegen mediante almacenamiento respaldado por hardware; el servidor transmite los datos cifrados sin disponer en ningún momento de las claves de mensajes, archivos o llamadas.
Fuentes
- Libro blanco sobre la seguridad técnica y la arquitectura de SANKET, edición pública 2.0 (7 de octubre de 2026)
- SSH: primeras instalaciones de SalaX Secure Messaging e incorporación a la Fundación Matrix (28 de abril de 2025)
- SSH: SalaX Secure Messaging
- SSH: colaboración segura con soberanía de los datos
- SSH: ficha comercial de SalaX Secure Collaboration 2025
Sources checked on 7 October 2026. Los datos sobre los competidores proceden únicamente de las fuentes indicadas. Cuando no se ha encontrado ninguna fuente pública, la celda indica «No documentado públicamente». Los nombres de productos y empresas son marcas comerciales de sus respectivos titulares.
Ponga sus comunicaciones bajo su propio control
Hable con el equipo de Tosh Defence sobre su despliegue, desde una instalación en una nube dedicada hasta una infraestructura totalmente aislada de otras redes, o consulte primero la arquitectura de seguridad completa.