Cifrado de extremo a extremo con Signal Protocol y AES-256 en todas partes
Sanket (Sanket.Chat) de Tosh Defence cifra de extremo a extremo cada mensaje, reacción y difusión cifrada mediante Signal Protocol, a través de libsignal, la implementación oficial de Signal sometida a auditorías independientes, con acuerdo de claves PQXDH y Double Ratchet con SPQR. Los archivos, las tramas y el transporte de las llamadas, el almacenamiento local y todas las sesiones TLS que termina la instalación utilizan AES-256, sin alternativa con AES-128 ni modo de compatibilidad.
AES-256 o la operación se rechaza: esta es la política de ingeniería de Sanket, aplicada mediante código. Si el cifrado no puede realizarse exactamente como está diseñado, se rechaza la operación en lugar de reducir su nivel de seguridad.
Mensajes: Signal Protocol, sin modificaciones
SANKET utiliza la biblioteca oficial libsignal de Signal para cifrar todos los mensajes, con la misma versión en iOS, Android, las aplicaciones de escritorio y el servidor. No incluye ninguna reimplementación de Signal Protocol ni ningún cifrador alternativo para mensajes.
Las sesiones se establecen mediante PQXDH, la extensión poscuántica de X3DH, que combina acuerdos de claves X25519 con una encapsulación Kyber. A continuación, los mensajes se cifran mediante Double Ratchet: cada clave de mensaje se expande para generar una clave AES-256, una clave HMAC-SHA256 y un vector de inicialización; el mensaje se cifra con AES-256 y se autentica con HMAC-SHA256, y la clave se elimina tras su uso. El mecanismo de trinquete poscuántico disperso de Signal funciona en paralelo en cada sesión.
Sin mecanismo alternativo, por diseño
Un cliente se niega a enviar mensajes si no puede cifrarlos mediante libsignal. Se omiten los dispositivos que no publican una clave de identidad de libsignal, en lugar de enviarles texto sin cifrar; se rechazan los indicadores antiguos de texto sin cifrar; y el servidor rechaza los conjuntos de claves que no cumplen el formato de libsignal. No existe ninguna vía de envío de contenido de mensajes en texto sin cifrar ni mediante un cifrado alternativo.
Grupos sin clave compartida
Los mensajes de grupo se cifran mediante distribución individualizada: el dispositivo emisor cifra el mensaje por separado para cada dispositivo de confianza de cada miembro, a través de su propia sesión de libsignal. Los cambios en la composición del grupo no requieren renovar las claves, y los miembros eliminados simplemente dejan de figurar en la lista de distribución.
Antes de cifrar, el remitente comprueba la lista de dispositivos de la cuenta de cada destinatario, firmada con la clave propia de esa cuenta, y no envía nada a los dispositivos que no figuren en ella.
Archivos y llamadas
El contenido, los nombres y los tipos de los archivos adjuntos se cifran en el dispositivo con AES-256-GCM mediante una clave aleatoria de 256 bits por archivo, y esa clave se transmite dentro del mensaje de libsignal.
Las comunicaciones de voz y vídeo están protegidas dos veces. Los fotogramas de cada participante se cifran de extremo a extremo con AES-256-GCM mediante una clave específica de cada emisor que se renueva cada 200 milisegundos, lo que proporciona cinco claves nuevas para fotogramas por segundo y por emisor, con una nueva clave aleatoria cada vez que alguien se une o abandona la llamada. Entre cada dispositivo y el servidor multimedia, SRTP solo acepta AEAD_AES_256_GCM. El servidor multimedia reenvía fotogramas cifrados que no puede descifrar, y el diseño excluye la grabación de llamadas en el servidor.
- AES-256-GCM por archivo
- Claves de llamada por remitente, nunca una clave compartida para toda la sala
- Cinco claves de fotograma por segundo y por remitente
- Solo SRTP con AES-256-GCM
Transporte y almacenamiento
Cada conexión entre un cliente y la instalación utiliza TLS 1.3 con TLS_AES_256_GCM_SHA384, o TLS 1.2 con ECDHE y AES-256-GCM en las implementaciones de red de las plataformas que lo requieren. Se excluyen AES-128, ChaCha20, los conjuntos de cifrado en modo CBC y RSA estático, y se ofrece primero el grupo híbrido poscuántico X25519MLKEM768. Cada dispositivo aprobado también puede acreditar su identidad mediante su propio certificado de cliente a través de TLS mutuo.
En los dispositivos, las bases de datos locales se cifran con AES-256 y se autentican con HMAC-SHA256; en los teléfonos, el almacén del protocolo y los secretos del dispositivo se cifran con una clave respaldada por hardware en Secure Enclave, StrongBox o el entorno de ejecución de confianza.
Pruebas técnicas
Consulte los detalles en el documento técnico de SANKET
Todas las afirmaciones de esta página se desarrollan íntegramente en el documento técnico público sobre seguridad y arquitectura de SANKET, disponible gratuitamente y sin necesidad de registrarse.
¿Utiliza SANKET Signal Protocol?
Sí. Sanket cifra todos los mensajes en todas las plataformas con la biblioteca oficial libsignal de Signal, mediante el acuerdo de claves PQXDH y Double Ratchet con SPQR. No contiene ninguna implementación propia del protocolo.
¿Es SANKET un servicio de mensajería cifrada con AES-256?
Sí. Los mensajes utilizan AES-256-CBC con HMAC-SHA256 dentro de libsignal; los archivos, los fotogramas de las llamadas, el transporte de las llamadas, el almacenamiento local y TLS utilizan AES-256-GCM. No existe una alternativa con AES-128.
¿Las llamadas de voz y vídeo están cifradas de extremo a extremo?
Sí. Las tramas de las llamadas se cifran de extremo a extremo con AES-256-GCM mediante claves individuales de cada emisor entregadas a través de libsignal, con 5 claves de trama nuevas por segundo para cada emisor, dentro de SRTP, que solo acepta AES-256-GCM.
¿Están cifradas las reacciones y los mensajes de difusión?
Sí. Las reacciones y las difusiones cifradas son mensajes de libsignal, cifrados de extremo a extremo como todos los demás mensajes. La prioridad, el plazo y la caducidad de cada difusión también quedan dentro del cifrado.
¿Utiliza SANKET claves de remitente para los grupos?
No. SANKET cifra los mensajes de grupo por separado para cada dispositivo de confianza de cada miembro, cada uno mediante su propia sesión de libsignal, por lo que no existe una clave de grupo compartida.
¿Qué versiones de TLS acepta Sanket?
Se prefiere TLS 1.3, exclusivamente con TLS_AES_256_GCM_SHA384. TLS 1.2 solo se acepta con ECDHE y AES-256-GCM. No se acepta ninguna versión anterior a TLS 1.2 y se ofrece primero el intercambio híbrido de claves poscuántico X25519MLKEM768.
¿Se ha auditado libsignal?
Sí. SANKET se basa en libsignal, la biblioteca de Signal auditada de forma independiente, y el protocolo PQXDH ha sido analizado formalmente.
Examine la criptografía de Sanket con nuestros ingenieros
Tosh Defence explica a arquitectos de seguridad y comités de evaluación el diseño criptográfico, capa por capa, con acceso a la versión de acceso controlado del documento técnico bajo un acuerdo de confidencialidad.