Chiffrement
Comment Collogue chiffre un message privé
Une explication concise du flux de chiffrement vérifié côté navigateur utilisé par Collogue.
Publié le: 17 février 2026
Limites de l’implémentation actuelle
Les liens Collogue actuels portent la charge utile chiffrée dans l’URL. Le navigateur utilise l’API Web Crypto : PBKDF2-SHA-256 avec 310 000 itérations dérive une clé AES-GCM de 256 bits à partir du mot de passe saisi séparément, avec un sel aléatoire de 16 octets et un IV de 12 octets. Le client actuel n’envoie aucune requête à une API applicative pour créer, récupérer ou stocker des messages.
Le mot de passe n’est pas encodé dans le lien. L’implémentation ne fournit ni affichage à usage unique, ni suppression côté serveur, ni minuteur d’expiration. Considérez le lien complet comme sensible et transmettez le mot de passe par un autre canal.
Contexte complémentaire
L’idée est simple. C’est sa mise en œuvre correcte qui fait apparaître les problèmes intéressants.
Un message commence par être un texte lisible dans le navigateur de l’expéditeur.
- l’utilisateur ;
- le navigateur ;
- les scripts de la page ;
- les extensions disposant d’un accès suffisant ;
- les logiciels malveillants présents sur l’appareil ;
- les systèmes d’accessibilité et de saisie.
Ce n’est pas un défaut propre à Collogue. Un secret doit exister quelque part sous une forme lisible avant de pouvoir être chiffré.
Une clé cryptographique doit provenir d’une source cryptographiquement sûre ou d’un processus de dérivation documenté. Un hasard qui ressemble à celui d’un humain ne suffit pas. Un horodatage accompagné d’une ponctuation décorative reste un horodatage.
Si une phrase secrète intervient, l’implémentation doit utiliser une fonction de dérivation de clé et des paramètres adaptés. Si une clé aléatoire est générée, sa longueur et sa source de génération doivent être documentées.
- Confidentialité — le texte chiffré ne révèle pas le texte en clair sans la clé.
- Intégrité — toute modification non autorisée est détectée lors du déchiffrement.
La page publique ne devrait nommer la construction exacte qu’après vérification du code. « AES » n’est pas une description complète. Les modes, les nonces, les balises d’authentification, la taille des clés, l’encodage et la gestion des erreurs comptent.
Les API cryptographiques sont réputées fournir des outils tranchants avec des manches fabriqués avec professionnalisme. Leur utilisation correcte fait partie de la conception.
La forme sûre attendue, si le code réel la prend en charge, est une requête contenant du texte chiffré et des paramètres opérationnels plutôt que le texte lisible du message.
Inspectez le panneau réseau du navigateur. Ne déduisez pas cette propriété des textes de l’interface.
Ces valeurs ne sont pas automatiquement secrètes. Certaines sont nécessaires au déchiffrement et peuvent accompagner le texte chiffré sans danger. La clé est la distinction essentielle.
Un lien sûr n’est pas nécessairement une métadonnée anodine. Si la possession du lien complet permet de déchiffrer, le lien est une capacité de porteur : toute personne qui le possède peut être en mesure d’ouvrir le message.
Le lien doit donc être traité avec à peu près autant de soin que le secret pendant sa courte durée de vie.
Ce détail compte parce que des systèmes automatisés peuvent demander les liens. Une simple requête GET est plus facile à déclencher pour un robot d’aperçu qu’une action humaine explicite, même si aucun mécanisme ne prouve parfaitement qu’un humain est intervenu.
Le navigateur du destinataire reçoit le texte chiffré et le matériel de clé nécessaire, puis effectue un déchiffrement authentifié.
Si l’authentification échoue, l’application doit signaler que le message n’a pas pu être vérifié ou déchiffré. Elle ne doit pas afficher un texte corrompu comme si de rien n’était.
Un déchiffrement réussi crée du texte en clair dans le navigateur du destinataire. À partir de là, la cryptographie ne peut empêcher les copies, les captures d’écran, les photographies ou un appareil infecté de capturer le message.
Le chiffrement protège un trajet. Il ne peut pas contrôler le comportement futur du destinataire.
Une bonne page sur la confidentialité nomme cette limite au lieu de la remplacer par « disparu pour toujours ».
La bonne conclusion n’est pas le pessimisme, mais la précision.
Collogue doit faire une promesse limitée, la soutenir par un comportement observable et expliquer ses hypothèses. C’est plus utile que d’ajouter une grande icône de cadenas à un petit paragraphe.
Non. La génération sûre des clés, le chiffrement authentifié, les nonces uniques lorsque cela est nécessaire, l’encodage correct, les contrôles d’intégrité et la gestion sûre des erreurs font tous partie du protocole.
Parce que le déchiffrement doit produire du texte lisible sur l’appareil du destinataire. La cryptographie peut contrôler l’accès avant ce moment, pas le comportement du destinataire ensuite.
Créez un lien privé Collogue pour envoyer un mot de passe, un jeton, un code de récupération ou une autre valeur sensible courte.