Clés de chiffrement
Où se trouve la clé de déchiffrement ?
Pourquoi Collogue utilise un mot de passe saisi séparément plutôt que de placer la clé dans l’URL.
Publié le: 28 février 2026
Limites de l’implémentation actuelle
Le client actuel chiffre le texte dans le navigateur et place le contenu chiffré dans l’URL. Le mot de passe transmis séparément ne fait pas partie du lien. Aucun serveur applicatif ne stocke, ne récupère, ne supprime ou ne consomme les messages une seule fois.
Contexte complémentaire
Le chiffrement remplace un problème difficile par un autre.
Les clés sont petites. Leurs conséquences ne le sont pas.
Une clé de chiffrement symétrique permet au navigateur du destinataire de transformer un texte chiffré authentifié en texte en clair.
``text https://collogue.net/m/example-message#example-key-material ``
N’utilisez cet exemple que s’il correspond à l’architecture réelle.
Le fragment est la partie d’une URL située après #.
``text https://example.test/message/123#key-material ``
``text /message/123 ``
Le navigateur conserve #key-material localement et le rend disponible à la page chargée.
Mais trois précautions sont importantes.
Premièrement, le JavaScript chargé par la page peut lire le fragment. Le déchiffrement côté navigateur nécessite cela ou un mécanisme équivalent.
Deuxièmement, le lien complet devient une capacité d’accès. Toute personne qui l’obtient peut recevoir à la fois la référence du texte chiffré et la clé.
Troisièmement, les fragments peuvent toujours fuiter par le comportement humain, les captures d’écran, le texte copié, les extensions de navigateur, l’historique du presse-papiers, les outils de synchronisation ou un code client modifié.
Un fragment est une limite de protocole utile. Ce n’est pas un champ de force.
- journaux d’accès ;
- journaux de proxy inverse ;
- historique du navigateur ;
- diagnostics copiés ;
- données de référent, selon la politique et la navigation ;
- systèmes de surveillance.
Dans ce cas, l’article public doit expliquer l’exposition réelle plutôt que de décrire le comportement des fragments.
Une phrase secrète mémorable et une clé uniformément aléatoire ne sont pas interchangeables. Les paramètres de dérivation comptent.
Les utilisateurs supposent parfois qu’un lien chiffré peut être publié sans danger parce qu’il « ne contient que des données chiffrées ».
Cette conclusion est fausse lorsque le lien fournit aussi la capacité de déchiffrer.
- systèmes publics de suivi des problèmes ;
- canaux partagés avec des membres inutiles ;
- services d’analyse d’URL ;
- raccourcisseurs d’URL publics ;
- documents avec un accès étendu.
La possession du lien peut démontrer que quelqu’un possède le lien. Elle n’établit pas nécessairement l’identité.
Si un attaquant obtient l’URL avant le destinataire prévu, la cryptographie peut fonctionner parfaitement pour lui.
C’est la leçon récurrente des capacités de type bearer : l’autorisation est représentée par la possession.
Pour les secrets à risque élevé, vérifiez le destinataire et envisagez un canal distinct pour le contexte ou une authentification supplémentaire. Ne décrivez pas les canaux séparés comme automatiquement sûrs ; ils modifient seulement les exigences de l’attaque.
- l’expéditeur partage le mauvais lien ;
- le destinataire le transfère ;
- un logiciel malveillant du navigateur lit le fragment ;
- un script malveillant de la page capture le texte en clair ;
- l’historique du presse-papiers conserve l’URL ;
- un analyseur de liens demande la page ;
- le destinataire enregistre le message déchiffré.
Cela peut être une conception utile parce que le fragment n’est normalement pas envoyé dans les requêtes HTTP. La sécurité dépend malgré tout de la page fournie, de l’environnement du navigateur, de la gestion du lien et du comportement du destinataire.
Oui. Le JavaScript exécuté sur la page peut accéder au fragment. C’est souvent ainsi que le déchiffrement côté client obtient le matériel de clé.
Si Collogue ne conserve pas la clé ou ne la dérive pas, la perte du matériel de lien nécessaire peut rendre le message irrécupérable. Confirmez l’implémentation avant de publier cette affirmation.