Fonctionnement du chiffrement

La messagerie transporte le conteneur

Secure Chat fonctionne indépendamment de Telegram, de l’e-mail et des autres moyens de transmission. Sur l’appareil de l’expéditeur, le texte ou le fichier devient un conteneur chiffré. Ce conteneur est transmis par le canal choisi, puis déchiffré localement par le destinataire avec sa clé privée.

1. Les correspondants créent leurs propres profils et échangent leurs cartes de clés publiques.
2. Ils comparent les empreintes complètes par un moyen indépendant et confirment le contact dans l’application.
3. L’expéditeur choisit son profil, le destinataire et l’algorithme. Secure Chat chiffre le contenu et signe le conteneur.
4. Le destinataire ouvre le conteneur, saisit si nécessaire le mot de passe du coffre et obtient le résultat vérifié.

L’accès à l’historique de la messagerie ne donne pas à lui seul la clé privée Secure Chat. Cette protection supplémentaire concerne précisément le contenu chiffré au préalable. Elle ne masque ni l’existence des échanges, ni les participants, les horaires ou les adresses réseau, et ne protège pas un appareil déjà infecté par un logiciel malveillant.

Deux paires de clés par profil

La carte publique .scpub contient le nom, les deux clés publiques, l’empreinte et la version du format. Elle ne contient aucune clé privée. Son format est un JSON lisible ; les champs binaires sont encodés en Base64.

Format: SecureChat.PublicKey
Version: 1
Name
EncryptionPublicKey
SigningPublicKey
Fingerprint

Vérifier son correspondant

L’empreinte réunit les deux clés publiques en un hachage SHA-256 de 64 caractères hexadécimaux. Avant l’envoi, comparez-la intégralement en personne ou par un autre canal de confiance. Le nom d’une carte importée ne prouve pas l’identité.

SHA256(
  UTF8("SecureChat.Identity.v1\0")
  || int32BE(length(RSA_SPKI)) || RSA_SPKI
  || int32BE(length(ECDSA_SPKI)) || ECDSA_SPKI
)

Un contact importé est toujours marqué comme non vérifié. L’application autorise le chiffrement à son intention après confirmation de la comparaison. Les profils personnels peuvent être choisis comme destinataires pour tester l’application.

Une signature numérique valide confirme que le conteneur correspond à la clé de signature. Le lien entre cette clé et une personne est établi par l’empreinte comparée. Pour une clé inconnue ou non vérifiée, l’application indique séparément que l’identité de l’expéditeur n’est pas confirmée.

Une clé aléatoire distincte pour chaque conteneur

Chaque nouveau message et fichier reçoit une nouvelle clé aléatoire de 256 bits via RandomNumberGenerator.GetBytes . Vous choisissez l’un des deux modes de chiffrement authentifié, AEAD :

ChaCha20-Poly1305 est proposé uniquement si le système d’exploitation le prend en charge. L’algorithme choisi figure dans l’en-tête authentifié ; aucun passage automatique à une variante plus faible n’est effectué.

La clé aléatoire du contenu est chiffrée avec la clé publique RSA du destinataire. Une copie distincte est chiffrée avec celle de l’expéditeur, qui peut ainsi ouvrir son propre message envoyé. L’envoi à soi-même crée un seul emplacement de ce type.

AEAD vérifie l’intégrité du contenu et des données associées. La signature ECDSA-P256/SHA-256 lie en outre le conteneur à la clé de l’expéditeur. Un échec de vérification interrompt le déchiffrement.

Coffre protégé par mot de passe

Les profils avec leurs clés privées, les contacts, les paramètres protégés et l’historique sont réunis dans un fichier Data/wallet.scvault à côté de l’application. Le coffre est chiffré avec AES-256-GCM.

Le mot de passe et un hachage distinct de vérification ne sont pas enregistrés. PBKDF2 ralentit les attaques par essais successifs, mais la résistance dépend toujours du mot de passe. Pour une phrase secrète longue et unique, privilégiez des mots aléatoires ou un gestionnaire de mots de passe.

L’en-tête de 64 octets est lui aussi authentifié. Il est suivi du texte chiffré et du tag :

"SCVAULT1"[8]
|| version:int32LE
|| iterations:int32LE
|| salt[32]
|| nonce[12]
|| ciphertext_length:int32LE
|| ciphertext
|| tag[16]

Le format version 1 n’accepte que les paramètres KDF définis, une taille limitée et une longueur de fichier exacte. L’écriture passe par une copie chiffrée entièrement préparée, puis le remplacement du fichier. Les écritures simultanées et l’écrasement de modifications externes détectées sont refusés. Le fichier auxiliaire .lock ne contient aucune clé.

Ce que contient l’en-tête en clair

Un conteneur de message ou de fichier commence par quatre octets de type, la longueur de l’en-tête JSON, puis cet en-tête. La taille du JSON est limitée à 16 384 octets.

magic[4] || header_length:int32LE || header_json[header_length]

Ces métadonnées ne sont pas chiffrées. L’algorithme, la taille, le nom du fichier, les clés publiques et les empreintes sont visibles. Les clés permanentes permettent de relier les conteneurs d’un même expéditeur. Si le nom du fichier est sensible, renommez-le avant le chiffrement.

L’en-tête en clair est protégé contre les modifications indétectées : la signature et AEAD utilisent ses octets d’origine, et non un JSON reconstruit. Dans la description ci-dessous, || désigne la concaténation d’octets. Les entiers sont écrits en little-endian ; les exceptions en big-endian sont indiquées explicitement.

Texte : conteneur SC1 et pièce jointe .scmsg

Le texte initial est limité à 1 Mio en UTF-8 strict. Le conteneur binaire est de type SCT1 :

"SCT1"
|| header_length:int32LE || header_json
|| ciphertext_length:int32LE || ciphertext
|| tag[16] || signature[64]

L’ensemble du préfixe sert de données additionnelles authentifiées (AAD) : type, longueur et JSON de l’en-tête. La signature ECDSA-P256 est calculée sur le SHA-256 de tous les octets précédents. Le format de signature est IeeeP1363FixedFieldConcatenation : r || s , de 32 octets chacun.

Pour la transmission, le conteneur binaire est converti en Base64url sans caractères de remplissage = :

SC1:<base64url(binary_container)>
securechat://message/<base64url(binary_container)>

Avant de révéler le texte, le logiciel vérifie la structure, la longueur exacte et la signature, puis déchiffre l’enveloppe RSA et vérifie AEAD. Les caractères non autorisés, les sauts de ligne dans l’enveloppe, les paramètres URI supplémentaires et les données endommagées sont refusés.

Transmission via Telegram

Le bouton « Fichier pour le chat » copie le fichier chiffré .scmsg dans le presse-papiers de fichiers Windows. Collez-le dans le chat avec Ctrl + V et envoyez la pièce jointe. Le destinataire télécharge le fichier et l’ouvre dans Secure Chat. Si l’application est verrouillée, elle demande d’abord le mot de passe.

L’enveloppe ordinaire SC1:… peut aussi être copiée et collée manuellement. Le lien Windows securechat://… est limité à 8 000 caractères et n’est pas cliquable dans tous les clients. Telegram Desktop ne transforme pas ce schéma arbitraire en lien automatique ordinaire ; utilisez la pièce jointe .scmsg à cet effet. Les anciens fichiers .sct s’ouvrent explicitement depuis l’application.

Fichiers : blocs, signature et deux passes de vérification

Un fichier chiffré reçoit l’extension .scx et le type SCF1 . Le format accepte des fichiers initiaux jusqu’à 1 Tio. Le traitement s’effectue en flux : le fichier n’est pas chargé entièrement en mémoire, son contenu est réparti en blocs de 1 Mio.

"SCF1" || header_length:int32LE || header_json
|| (chunk_length:int32LE || ciphertext[chunk_length] || tag[16])*
|| 0:int32LE || terminal_tag[16]
|| signature[64]

Chaque bloc reçoit son propre nonce de 12 octets. Il se compose du préfixe aléatoire de quatre octets du conteneur et de l’index de bloc sur huit octets :

nonce = Nonce[4] || uint64BE(chunk_index)
AAD   = SHA256(full_prefix)[32]
        || uint64BE(chunk_index)
        || int32LE(chunk_length)

L’index commence à zéro. Le bloc terminal vide reçoit l’index suivant et son propre tag. Même un fichier vide possède un en-tête, un bloc terminal, un tag et une signature. Une nouvelle clé de contenu est générée pour chaque nouveau fichier.

La signature couvre tous les octets depuis SCF1 jusqu’au tag AEAD terminal inclus. L’ordre et la taille des blocs, la longueur exacte du conteneur et la fin du fichier sont vérifiés. Réordonner, dupliquer, supprimer des blocs, tronquer ou ajouter des données entraîne un refus.

Déroulement du déchiffrement

1. L’en-tête limité en taille, la longueur du fichier et la présence d’une clé privée correspondante sont vérifiés.
2. La première passe lit le conteneur et vérifie la signature complète. Aucun fichier temporaire en clair n’est encore créé.
3. La seconde passe vérifie AEAD pour chaque bloc, écrit les données déchiffrées dans un fichier temporaire et vérifie de nouveau la signature finale.
4. Après une exécution réussie, le résultat est renommé en un nouveau fichier choisi par l’utilisateur. Un fichier existant n’est pas écrasé.

La barre d’état affiche la progression globale : vérification de la signature, déchiffrement et enregistrement. 100 % signifie que le résultat est bien enregistré. L’annulation reste disponible pendant le traitement ; en cas d’erreur normale ou d’annulation, le fichier temporaire est supprimé.

Le fichier initial est conservé. Le résultat déchiffré n’est pas exécuté automatiquement. Une panne de courant, l’arrêt forcé du processus ou un handle externe empêchant la suppression peuvent laisser un fichier temporaire en clair. La protection du dossier de sortie et du disque reste essentielle pour les données sensibles.

Stockage local, historique et verrouillage

L’historique contient les métadonnées des opérations et les enveloppes texte chiffrées. Le texte en clair et le contenu des fichiers n’y sont pas enregistrés. Les 100 dernières entrées sont conservées, pour environ 8 Mio d’enveloppes au total ; les plus anciennes sont supprimées automatiquement. L’historique peut être désactivé ou effacé.

Le coffre se verrouille avec Ctrl + L , lors de la réduction de la fenêtre, du verrouillage ou de la déconnexion de la session Windows, de la mise en veille et de l’inactivité. Le délai d’inactivité se règle de 1 à 15 minutes, avec 5 minutes par défaut. L’opération sur fichier en cours est annulée avant la libération des clés.

Au verrouillage, les champs et références aux entrées sont effacés ; les tableaux de clés privées et de clé dérivée appartenant à l’application sont remplis de zéros. La suppression complète de toutes les copies en mémoire n’est pas garantie : chaînes gérées, presse-papiers, dumps et fichier d’échange peuvent garder des résidus.

Deux modes distincts du presse-papiers

« Copier le texte » marque l’entrée propre à l’application et l’efface après 30 secondes ou au verrouillage si elle appartient toujours à Secure Chat. Une entrée plus récente d’une autre application n’est pas effacée. La copie ordinaire par la commande système Ctrl + C n’est pas gérée par ce délai.

« Fichier pour le chat » place dans Windows FileDrop le chemin d’un fichier .scmsg , qui contient uniquement le texte chiffré. Cette copie reste disponible après le verrouillage et la fermeture du coffre pour laisser le temps à la messagerie de la lire. Chaque copie crée une pièce jointe distincte.

Les copies de plus de 24 heures sont supprimées au prochain lancement ou à la prochaine copie. Jusqu’à 128 pièces jointes temporaires sont conservées simultanément ; à cette limite, vous pouvez enregistrer explicitement le message dans un dossier choisi. Les interdictions d’historique et de presse-papiers cloud sont transmises comme indications à Windows ; des gestionnaires tiers peuvent les ignorer.

Sauvegardes, déplacement et mises à jour

Une sauvegarde est une copie complète du coffre chiffré. Son ouverture nécessite le mot de passe en vigueur lors de sa création. Actualisez-la après l’ajout de nouvelles clés. Aucune récupération sans mot de passe et clés privées n’est prévue.

Le changement du mot de passe, la suppression d’un profil ou l’effacement de l’historique modifient le coffre actuel. Les anciennes sauvegardes conservent leur mot de passe, leurs clés et leur historique antérieurs. La suppression d’une entrée ne garantit pas non plus l’effacement physique sur SSD, dans les instantanés ou un système de fichiers journalisé.

Pour passer à la version 0.1.6, fermez Secure Chat et remplacez SecureChat.exe dans son dossier actuel. Conservez l’intégralité du dossier Data. Les formats du coffre et des conteneurs restent en version 1 ; aucune migration n’est requise. Pour les futures versions modifiant un format, la procédure de migration sera décrite séparément.

Pour déplacer l’application vers un autre dossier, déplacez l’EXE avec Data et les traductions externes nécessaires dans Languages . Réactivez ensuite la prise en charge de .scmsg , .scx et des liens dans les paramètres : l’enregistrement Windows conserve un chemin absolu. Un EXE à fichier unique peut extraire les bibliothèques natives .NET dans le cache système de l’utilisateur.

Les requêtes réseau de l’application

Le chiffrement et le déchiffrement n’ont pas besoin de serveur. Secure Chat ne propose ni transport de messages, ni compte pour échanger les clés, ni service de réinitialisation du mot de passe. Le transport des conteneurs est assuré par votre messagerie, l’e-mail ou un autre canal.

Avec « Rechercher des mises à jour », l’application récupère un petit document JSON depuis https://itmsft.com/securechat/update/latest.json . La vérification au démarrage s’active séparément et est désactivée par défaut. La requête transmet les informations réseau habituelles d’une connexion HTTPS et un User-Agent générique contenant la version du logiciel. Elle n’inclut ni mot de passe, ni clés, profils, historique ou contenu des fichiers.

Le client limite la réponse à 64 Kio et la lecture à 10 secondes. Il vérifie la version et la présence d’un paquet pour son architecture. Une erreur de serveur, de réseau ou de format est signalée comme une impossibilité de vérifier, sans déclarer la version installée à jour.

Le bouton de téléchargement ouvre l’adresse HTTPS autorisée du paquet sur itmsft.com dans le navigateur habituel. L’application n’effectue aucune installation automatique et n’exécute pas le fichier téléchargé. Le format du champ SHA-256 est vérifié, mais pas les octets du ZIP téléchargé par le navigateur. Dans la version 0.1.6, l’EXE ne possède pas de signature numérique de l’éditeur.

Des limites à prendre en compte

• Sécurité de l’appareil. Un logiciel malveillant, un enregistreur de frappe, la lecture de la mémoire, le remplacement de l’EXE ou un accès distant peuvent révéler le texte avant le chiffrement et après le déchiffrement.
• Métadonnées. L’en-tête en clair du conteneur et les informations réseau du canal de transmission sont visibles. Ce n’est pas un outil d’anonymat.
• Clés statiques. La confidentialité persistante (forward secrecy) n’est pas implémentée : une clé privée volée permet de lire les conteneurs précédemment interceptés qui lui étaient destinés.
• Rétablissement de la confidentialité. Double Ratchet et la sécurité après compromission (post-compromise security) sont absents. Il s’agit d’un format propre au projet, et non d’une implémentation du protocole Signal.
• Répétition et retour en arrière. Un conteneur valide peut être renvoyé. Une ancienne copie valide du coffre n’est pas protégée contre le retour en arrière : l’intégrité ne prouve pas qu’elle est à jour.
• Mot de passe. La longueur minimale et les délais de l’interface n’arrêtent pas les essais hors ligne sur un coffre volé. Les protections principales sont un mot de passe fort et la KDF.
• Suppression des données. L’effacement complet de la RAM, du fichier d’échange, du presse-papiers cloud et du support de stockage n’est pas garanti.
• Propriétés cryptographiques. Le schéma n’est pas post-quantique. Les tiers ayant reçu le conteneur peuvent vérifier sa signature ; aucun déni cryptographique n’est fourni.
• État de la vérification. Les primitives standard et les tests automatisés ne remplacent pas un audit indépendant du protocole et de l’implémentation.

Secure Chat ajoute un contrôle distinct sur le contenu choisi. Pour des données particulièrement sensibles, il faut évaluer votre modèle de menace, sécuriser l’appareil et faire examiner l’implémentation par des experts indépendants.

Demander l’accès au code source →