La réponse courte
Un chiffrement de bout en bout correctement mis en œuvre signifie que le contenu du message est chiffré sur l’appareil de l’expéditeur et ne peut être déchiffré que par les points finaux de réception prévus. Le service de livraison doit gérer le texte chiffré, et non le texte brut ou les clés de conversation. Mais E2EE protège un chemin entre les points de terminaison : il ne rend ni le point de terminaison, ni le destinataire, ni chaque élément de métadonnées, ni chaque sauvegarde dignes de confiance.
Que signifie réellement « bout à bout »
Les points de terminaison sont les appareils ou les instances d'application qui détiennent les clés nécessaires pour lire une conversation. Le chiffrement a lieu avant que le message ne quitte le point de terminaison de l'expéditeur ; le décryptage a lieu après avoir atteint un point de terminaison de réception autorisé.
Cette frontière compte. Le chiffrement de transport tel que TLS protège une connexion entre un appareil et un serveur. Le chiffrement de bout en bout ajoute une limite distincte au niveau du message destinée à empêcher l'intermédiaire de recevoir les clés en texte brut. La norme Messaging Layer Security du IETF décrit l'objectif comme étant de rendre les messages accessibles aux points finaux communicants plutôt qu'aux serveurs qui les délivrent.
Une étiquette de produit à elle seule ne constitue pas une preuve. L'authentification de l'identité, la gestion des clés, les modifications d'appartenance à un groupe, la suppression des anciennes clés, la qualité de la mise en œuvre et le comportement des sauvegardes affectent tous le résultat réel de la sécurité.
Ce que le E2EE est conçu pour protéger
Les garanties exactes dépendent du protocole et de la mise en œuvre, mais le E2EE authentifié moderne est destiné à répondre à ces risques :
Interception de réseau
Une personne observant Wi-Fi, un FAI ou un réseau intermédiaire devrait voir le trafic chiffré plutôt que le contenu lisible des messages.
Un prestataire curieux
Un service de livraison qui ne détient pas de clés de conversation ne devrait pas être en mesure d'ouvrir le texte chiffré d'un message ordinaire.
Compromission du serveur de livraison
Le chiffrement au niveau des messages peut préserver la confidentialité du contenu même si le routage de l'infrastructure ou le texte chiffré temporairement mis en file d'attente est compromis.
Modifications de message non détectées
Le chiffrement authentifié peut permettre aux destinataires de rejeter le texte chiffré qui a été modifié ou falsifié, sous réserve d'une authentification et d'une mise en œuvre correctes de la clé.
Une certaine exposition à des messages passés
Les protocoles avec secret de transmission suppriment ou avancent les anciens éléments de clé afin qu'une compromission de clé ultérieure ne révèle pas automatiquement tous les messages antérieurs. Il s'agit d'une propriété de protocole supplémentaire et non d'un synonyme de E2EE.
Ce que E2EE ne protège pas automatiquement
La plupart des malentendus en matière de sécurité commencent lorsque la protection du contenu des messages est traitée comme la protection de l'ensemble du système de communication.
Un point de terminaison compromis ou déverrouillé
Les logiciels malveillants, un appareil volé déverrouillé, des aperçus de notifications, des captures d'écran, des claviers et des services d'accessibilité peuvent rencontrer du texte en clair avant le cryptage ou après le décryptage.
La personne qui reçoit le message
Un destinataire autorisé peut copier, photographier, citer ou transmettre ce qu’il peut légitimement lire. Les contrôles qui disparaissent réduisent l’historique conservé ; ils ne peuvent pas faire oublier un destinataire hostile.
Toutes les métadonnées
La livraison peut exposer le timing, le volume de trafic, les adresses IP, les destinations, les jetons d'appareil ou les opérations de groupe. Les protocoles et les architectures peuvent minimiser ou protéger certaines parties de ces métadonnées, mais le chiffrement du contenu ne suffit pas à les supprimer.
Sauvegardes et exportations non chiffrées
Si l'historique en texte brut ou les clés récupérables sont copiés dans un autre système, cette copie possède sa propre limite de sécurité. « Le chat est E2EE » ne prouve pas que chaque sauvegarde le soit.
Qui est vraiment à l'autre bout du fil
Le cryptage avec une clé incorrecte ou substituée peut créer une conversation parfaitement cryptée avec la mauvaise partie. La vérification des clés et la liaison d’identité fiable restent importantes.
Disponibilité et coercition
Un service peut toujours retarder, bloquer, limiter le débit ou supprimer le trafic chiffré. E2EE ne peut pas non plus empêcher une personne d’être obligée de déverrouiller un point de terminaison ou de divulguer ce qu’elle sait.
Modèle de menace : E2EE est-il utile ?
Une question de sécurité utile nomme l’adversaire au lieu de demander si une application est simplement « cryptée ».
| Scénario | E2EE protège-t-il le contenu ? | Qu'est-ce qui compte d'autre |
|---|---|---|
| L'observateur du réseau intercepte le trafic | Généralement oui | Protocole solide, mise en œuvre sécurisée, limites d'analyse du trafic |
| Le serveur de livraison est piraté | Généralement oui | Les clés doivent rester sur les points finaux autorisés ; les métadonnées peuvent rester visibles |
| Le téléphone est volé alors qu'il était déverrouillé | Non | Verrouillage de l'appareil, protection du stockage local, politique de notification, conservation courte |
| Le destinataire enregistre intentionnellement le message | Non | Confiance, politique, filigrane, divulgation limitée, contrôles juridiques |
| L'attaquant remplace une clé d'identité | Pas tout seul | Vérification des clés, transparence, authentification, avertissements de changement |
| Le service refuse de transmettre les messages | Non | Conception de disponibilité, surveillance, plan de communication alternatif |
Comment City of Hats gère cette limite
City of Hats traite E2EE comme une couche dans un modèle de menace plus large. Les déclarations ci-dessous décrivent notre architecture publiée et le comportement de nos produits ; ils ne prétendent pas que le logiciel peut éliminer les risques liés aux points finaux ou le comportement des destinataires.
Chiffrement au niveau des messages
City of Hats documente E2EE côté client pour les messages, fichiers et appels Hat-to-Hat, à l'aide de l'établissement de clés hybrides X25519 et ML-KEM-768 avec un Double Ratchet et AES-256-GCM. Les clés de décryptage des conversations sont destinées à rester sur les appareils autorisés.
Transparence technique →Moins d'identité d'enregistrement
Un Hat peut être créé sans numéro de téléphone ni e-mail. Phrase IDs, plusieurs Hats et Hats jetables réduisent le besoin de lier chaque contexte de communication à une identité d'opérateur ou de boîte aux lettres. Ils ne rendent pas anonyme un appareil ou une connexion réseau compromis.
Disposable Hats →Appels cryptés relayés
City of Hats documente la voix et la vidéo relayées afin que l'autre participant ne reçoive pas d'adresse IP directe peer-to-peer. Le relais gère les médias cryptés, tandis que les métadonnées au niveau du réseau nécessitent toujours un modèle de menace réaliste.
Appels cryptés →Aucun chemin de récupération de conversation
La messagerie grand public est conçue sans coffre-fort de récupération de messages détenu par le fournisseur. La perte du seul appareil autorisé peut entraîner la perte de l'historique des messages. Cela améliore la résistance aux demandes de récupération côté serveur, mais constitue un compromis délibéré en matière de disponibilité.
Confidentialité et traitement des données →Contrôles après livraison
View Once, Recall, GeoLock, Certified Send, Channel Seal et d'autres modes de sécurité peuvent limiter l'accès ou la conservation normale. Ces contrôles réduisent l'exposition ; ils ne peuvent pas vaincre un destinataire autorisé à l’aide d’une deuxième caméra ou d’un point final déjà compromis.
Modes de sécurité →Contextes de communication brûlables
Hats et les chaînes peuvent être gravées ou expirer, de sorte qu'une identité à long terme et un historique de conversations illimité ne sont pas obligatoires. La destruction réduit ce qui reste disponible plus tard ; il ne peut pas retirer les informations déjà capturées en dehors du système protégé.
Channel Seal →Comment évaluer une messagerie cryptée
Ne vous arrêtez pas à l’expression « chiffré de bout en bout ». Demandez au fournisseur ou à sa documentation :
- Quels types de communication sont E2EE par défaut : messages, groupes, fichiers, appels et interactions professionnelles ?
- Où les clés sont-elles générées, stockées, alternées, sauvegardées et supprimées ?
- Comment les clés d’identité sont-elles vérifiées et que se passe-t-il lorsqu’une clé change ?
- Quels contenus et métadonnées le service peut-il observer ou conserver ?
- Que se passe-t-il sur un appareil compromis, perdu ou nouvellement lié ?
- Les destinataires peuvent-ils exporter, transférer, capturer ou conserver du contenu de manière permanente ?
- Les spécifications du protocole, le code source, les audits ou les preuves techniques reproductibles sont-ils disponibles ?
- Quelles propriétés de sécurité sont indépendantes de E2EE, telles que la confidentialité transmise, la sécurité après compromission, la résistance aux métadonnées et la disponibilité ?
L'essentiel
Le chiffrement de bout en bout est essentiel car il peut supprimer le service de livraison et le réseau de l'ensemble des parties auxquelles le contenu des messages est confié. Il ne s’agit pas de l’ensemble du système de confidentialité. Une communication sécurisée et solide dépend également des points finaux, de l'identité, des métadonnées, de la conservation, de la récupération, du comportement du destinataire et d'une documentation honnête des compromis.
Sources primaires et lectures complémentaires
Normes et documents techniques de première partie utilisés pour cet article. Consulté le 9 août 2026.
- IETF RFC 9420. The Messaging Layer Security (MLS) Protocol
- IETF RFC 9750. The Messaging Layer Security (MLS) Architecture
- NIST SP 800-124 Rev. 2. Guidelines for Managing the Security of Mobile Devices
- Signal. Sealed Sender: metadata and message delivery
- Signal. Disappearing messages and the hostile-recipient boundary
Les déclarations de produits City of Hats renvoient à notre propre documentation publiée et doivent être évaluées comme des allégations de première partie jusqu'à ce qu'elles soient vérifiées de manière indépendante.
← Retour au centre de connaissances