Chiffrement de bout en bout avec Signal Protocol et AES-256 partout
Sanket (Sanket.Chat) de Tosh Defence chiffre de bout en bout chaque message, réaction et diffusion chiffrée au moyen de Signal Protocol et de la bibliothèque libsignal officielle de Signal, auditée de manière indépendante, avec l'établissement de clés PQXDH et Double Ratchet associé à SPQR. Les fichiers, les trames d'appel, le transport des appels, le stockage local et chaque session TLS terminée par l'installation utilisent AES-256, sans repli vers AES-128 ni mode de compatibilité.
La règle d'ingénierie de Sanket, appliquée dans le code, est AES-256 ou l'échec de l'opération. Si le chiffrement ne peut pas être effectué exactement comme prévu, l'opération est refusée plutôt que d'utiliser un chiffrement moins robuste.
Messages : Signal Protocol, sans modification
Sanket utilise la bibliothèque officielle libsignal de Signal pour chiffrer tous les messages, avec la même version sur iOS, Android, les ordinateurs et le serveur. Elle ne contient aucune réimplémentation de Signal Protocol ni aucun autre algorithme de chiffrement des messages.
Les sessions sont établies avec PQXDH, l’extension post-quantique de X3DH, qui combine des accords de clés X25519 avec une encapsulation Kyber. Les messages sont ensuite chiffrés avec Double Ratchet : chaque clé de message est développée en une clé AES-256, une clé HMAC-SHA256 et un vecteur d’initialisation ; le message est chiffré avec AES-256 et authentifié avec HMAC-SHA256, puis la clé est supprimée après utilisation. Le mécanisme de cliquet post-quantique à mises à jour espacées de Signal fonctionne en parallèle pour chaque session.
Aucune solution de repli, par conception
Un client refuse d’envoyer un message si le chiffrement libsignal ne peut pas être effectué. Les appareils qui ne publient pas de clé d’identité libsignal sont ignorés : aucun message ne leur est envoyé en clair. Les anciens marqueurs de texte en clair sont rejetés, et le serveur refuse les ensembles de clés non conformes au format libsignal. Aucun contenu de message n’est transmis en clair ni par un autre mécanisme de chiffrement.
Groupes sans clé partagée
Les messages de groupe sont chiffrés par distribution individuelle : l’appareil émetteur chiffre le message séparément pour chaque appareil de confiance de chaque membre, au moyen de sa propre session libsignal. Les changements de membres ne nécessitent aucun renouvellement des clés, et un membre retiré ne figure simplement plus dans la liste de distribution.
Avant de chiffrer, l'expéditeur vérifie, pour chaque compte destinataire, la liste des appareils signée par la clé propre à ce compte et n'envoie rien à un appareil qui n'y figure pas.
Fichiers et appels
Le contenu, les noms et les types des pièces jointes sont chiffrés sur l'appareil avec AES-256-GCM au moyen d'une clé aléatoire de 256 bits propre à chaque fichier. Cette clé est transmise dans le message libsignal.
La voix et la vidéo bénéficient d'une double protection. Les trames de chaque participant sont chiffrées de bout en bout avec AES-256-GCM au moyen d'une clé propre à chaque émetteur, renouvelée par cliquet toutes les 200 millisecondes, ce qui produit cinq nouvelles clés de trame par seconde pour chaque émetteur. Une nouvelle clé aléatoire est créée à chaque arrivée ou départ d'un participant. Entre chaque appareil et le serveur multimédia, SRTP n'accepte que AEAD_AES_256_GCM. Le serveur multimédia transmet des trames chiffrées qu'il ne peut pas déchiffrer, et l'architecture exclut l'enregistrement des appels côté serveur.
- AES-256-GCM pour chaque fichier
- Des clés d’appel propres à chaque expéditeur, jamais de clé commune à tous les participants
- Cinq clés de trame par seconde et par expéditeur
- SRTP AES-256-GCM uniquement
Transport et stockage
Chaque connexion client utilise TLS 1.3 avec TLS_AES_256_GCM_SHA384, ou TLS 1.2 avec ECDHE et AES-256-GCM lorsque la pile réseau de la plateforme l'exige. AES-128, ChaCha20, les suites en mode CBC et RSA statique sont exclus, et le groupe hybride post-quantique X25519MLKEM768 est proposé en premier. Chaque appareil approuvé peut aussi prouver son identité au moyen de son propre certificat client par authentification TLS mutuelle.
Sur les appareils, les bases de données locales sont chiffrées avec AES-256 et authentifiées avec HMAC-SHA256 ; sur les téléphones, le stockage du protocole et les données secrètes de l’appareil sont chiffrés à l’aide d’une clé protégée par le matériel dans Secure Enclave, StrongBox ou l’environnement d’exécution de confiance.
Démonstration technique
Consultez les détails dans le livre blanc de Sanket
Chaque affirmation de cette page est détaillée dans le livre blanc public sur la sécurité technique et l'architecture de SANKET, consultable gratuitement et sans inscription.
SANKET utilise-t-il Signal Protocol ?
Oui. Sanket chiffre tous les messages sur chaque plateforme au moyen de la bibliothèque officielle libsignal de Signal, en utilisant l'accord de clés PQXDH et Double Ratchet avec SPQR. La plateforme ne contient aucune réimplémentation du protocole.
La messagerie SANKET est-elle chiffrée avec AES-256 ?
Oui. Les messages utilisent AES-256-CBC avec HMAC-SHA256 dans libsignal ; les fichiers, les trames d'appel, le transport des appels, le stockage local et TLS utilisent AES-256-GCM. Aucun repli vers AES-128 n'est prévu.
Les appels vocaux et vidéo sont-ils chiffrés de bout en bout ?
Oui. Les trames d'appel sont chiffrées de bout en bout avec AES-256-GCM au moyen de clés propres à chaque émetteur, transmises via libsignal. Chaque émetteur dispose de 5 nouvelles clés de trame par seconde, au sein d'un flux SRTP qui n'accepte que AES-256-GCM.
Les réactions et les messages de diffusion sont-ils chiffrés ?
Oui. Les réactions et les diffusions chiffrées sont des messages libsignal, chiffrés de bout en bout comme tous les autres messages. Le niveau de priorité, l'échéance et la date d'expiration d'une diffusion sont eux aussi chiffrés.
SANKET utilise-t-il Sender Keys pour les groupes ?
Non. Sanket chiffre séparément les messages de groupe pour chaque appareil de confiance de chaque membre, au moyen d'une session libsignal propre à chaque appareil ; il n'existe donc aucune clé de groupe partagée.
Quelles versions de TLS Sanket accepte-t-il ?
TLS 1.3 est privilégié, avec la seule suite TLS_AES_256_GCM_SHA384. TLS 1.2 n'est accepté qu'avec ECDHE et AES-256-GCM. Aucune version antérieure à TLS 1.2 n'est acceptée, et l'échange de clés post-quantique hybride X25519MLKEM768 est proposé en premier.
libsignal a-t-il fait l’objet d’un audit ?
Oui. SANKET repose sur libsignal, la bibliothèque de Signal auditée de manière indépendante, et le protocole PQXDH a fait l'objet d'une analyse formelle.
Examinez la cryptographie de Sanket avec nos ingénieurs
Tosh Defence présente aux architectes de sécurité et aux comités d'évaluation la conception cryptographique couche par couche, avec accès à la version du livre blanc à accès contrôlé sous accord de confidentialité.