Chat chiffré sans compte : comment Btwinus met de l'AES-256 dans un lien

Ouvrez Signal, la référence absolue de la messagerie chiffrée, et la première chose qu'elle vous demande est votre numéro de téléphone. Ouvrez Telegram et ce sera pareil, et à moins d'ouvrir explicitement une « conversation secrète », vos messages restent sur les serveurs de Telegram sous une forme qu'ils peuvent lire. WhatsApp chiffre les messages de bout en bout, mais lie votre identité à un téléphone, synchronise les métadonnées chez Meta et stocke les messages non remis sur ses serveurs.

Rien de tout cela n'est une escroquerie, ces outils sont infiniment plus sûrs que les simples SMS, mais le discours sur le chiffrement a ses limites. Il protège le contenu en transit. Il ne vous rend pas anonyme, il ne rend pas la conversation éphémère, et il suppose que vous fassiez confiance à une entreprise.

Btwinus tente de répondre à une question plus étroite : peut-on avoir une conversation chiffrée ponctuelle avec quelqu'un, sans compte d'un côté ni de l'autre, sans serveur au milieu, et sans qu'il ne reste rien après avoir fermé l'onglet ? Il s'avère que la réponse est oui, et le mécanisme est intéressant.

Ce que « sans compte » exige réellement

Pour qu'un chat n'exige véritablement aucun compte, trois conditions doivent être réunies :

1. Aucun lien avec une identité. Pas de numéro de téléphone, pas d'e-mail, pas de nom d'utilisateur, parce que chacun de ces éléments est une ligne dans une base de données quelque part.
2. Aucune rétention sur serveur. Si un serveur stocke les messages « jusqu'à leur remise », c'est aussi une base de données. Même de façon éphémère.
3. Transport direct. Les messages doivent voyager d'un navigateur à l'autre sans passer par un relais capable de les lire.

La plupart des outils de chat « sans inscription » échouent au point 2 ou au point 3. Ils utilisent un serveur pour relayer les messages, et même s'ils les suppriment après remise, le serveur peut tout lire en transit.

Le modèle Btwinus : le chiffrement dans l'URL

Voici l'astuce : au lieu d'utiliser un serveur pour mettre deux navigateurs en relation, la mise en relation passe par le lien lui-même. Le lien contient les informations chiffrées nécessaires pour démarrer une connexion pair-à-pair. Le navigateur du destinataire les déchiffre, répond, et les deux navigateurs se connectent directement sans jamais parler à un serveur.

Étape par étape :

1. Alice clique sur « Démarrer un nouveau chat ». Son navigateur génère une nouvelle clé AES-256, dérivée d'une phrase secrète générée aléatoirement grâce à PBKDF2 avec 100 000 itérations. Le navigateur crée également une offre WebRTC, le matériel cryptographique de négociation nécessaire pour établir une connexion pair-à-pair.
2. L'offre est chiffrée avec la clé AES, encodée en base64 et intégrée dans un fragment d'URL (la partie après le #). Les fragments d'URL ne sont jamais envoyés à un serveur, pas même par le navigateur. L'offre chiffrée voyage donc uniquement côté client.
3. Alice envoie le lien par WhatsApp, e-mail, n'importe quoi. Elle envoie la phrase secrète par un canal différent, un appel téléphonique, un SMS, en personne.
4. Bob ouvre le lien. Son navigateur voit le blob chiffré dans le fragment, lui demande la phrase secrète, dérive la même clé et déchiffre l'offre.
5. Le navigateur de Bob génère une réponse WebRTC, la chiffre avec la même clé et produit un lien de réponse qu'il renvoie à Alice.
6. Alice colle le lien de réponse de Bob. Son navigateur déchiffre la réponse, la transmet à WebRTC, et les deux navigateurs terminent la négociation.
7. À partir de là, les deux navigateurs communiquent directement via un DataChannel WebRTC, chiffré avec DTLS 1.3. Aucun serveur n'intervient dans aucun message.

L'ensemble du dispositif n'exige aucun état côté serveur. La « mise en relation », c'est le lien ; l'« authentification », c'est la phrase secrète ; le « transport », c'est le DTLS intégré à WebRTC. Les seuls appels réseau se font directement de navigateur à navigateur.

Pourquoi deux canaux (lien + phrase secrète)

La propriété de sécurité la plus importante ici n'est pas l'AES-256, c'est une commodité. C'est la séparation en deux canaux.

Si vous envoyiez le lien chiffré et la phrase secrète par le même canal (disons, les deux par WhatsApp), un attaquant qui compromet ce canal obtient les deux moitiés et peut tout déchiffrer. Tout le discours sur le chiffrement s'effondre.

Les envoyer séparément oblige l'attaquant à compromettre deux canaux différents, votre WhatsApp et votre ligne téléphonique, votre e-mail et l'échange verbal en personne. C'est bien plus difficile. Cela signifie aussi que vous pouvez utiliser un canal pas très sécurisé pour le lien (le lien est chiffré, on peut donc le partager publiquement sans risque), tant que la phrase secrète emprunte un chemin plus étroit.

Ce schéma a un nom en cryptographie : c'est une forme de vérification « hors bande » ou par « canal secondaire », comparable au fonctionnement des numéros de sécurité de Signal, en plus léger.

Les briques, nommées

Composant	Ce qu'il fait
AES-256-GCM	Chiffrement symétrique de l'offre/réponse WebRTC. Un chiffrement AES-256 de bout en bout, standard éprouvé, ouvert et largement audité.
PBKDF2 (100 000 itérations)	Étire la phrase secrète lisible par un humain (« storm-fox-river-4821 ») en une clé de 256 bits. Les 100 000 itérations rendent la force brute coûteuse, même pour des phrases courtes.
DataChannel WebRTC	Le transport pair-à-pair. Natif au navigateur, aucune bibliothèque nécessaire. Une fois établi, les messages ne touchent aucun serveur.
DTLS 1.3	Le chiffrement de transport que WebRTC utilise par défaut. Moderne, rapide, avec confidentialité persistante parfaite, même si une clé est compromise plus tard, le trafic passé reste illisible.
Chaîne d'authentification courte	Un court condensé des clés de session affiché aux deux utilisateurs, pour qu'ils puissent le comparer de vive voix et confirmer qu'il n'y a pas d'intermédiaire malveillant.

Ce pour quoi cette approche est faite, et ce pour quoi elle ne l'est pas

Elle convient pour : les conversations ponctuelles avec quelqu'un avec qui vous ne partagez aucune relation de compte, un journaliste qui reçoit une information anonyme d'une source, un avocat avec un nouveau client, un moment confidentiel qui ne devrait exister nulle part ensuite. Envoyer un secret unique comme un mot de passe. Éviter qu'une entreprise, quelle qu'elle soit, sache que la conversation a eu lieu.

Elle ne convient pas pour : la messagerie quotidienne avec des amis. Les messages asynchrones (les deux navigateurs doivent être en ligne pour communiquer). Les discussions de groupe. Le transfert de fichiers au-delà de petits volumes. Tout ce qui doit persister après la fermeture de l'onglet.

C'est un périmètre délibéré. Les outils qui essaient d'être à la fois privés et toujours disponibles dérivent vers le besoin de serveurs et de comptes. Btwinus a choisi l'inverse, accepter les limites du « tous les deux en ligne, éphémère, une conversation à la fois » en échange des propriétés de confidentialité les plus fortes possible.

Le modèle mental, enfin

Un chat chiffré n'a pas vraiment besoin d'une application de chat. Il a besoin de :

• Un moyen pour deux navigateurs de se trouver (le lien)
• Un secret partagé qu'eux seuls connaissent (la phrase secrète)
• Un transport direct (WebRTC)

Une fois qu'on accepte que la « mise en relation » puisse voyager par n'importe quel canal contrôlé par un humain, WhatsApp pour le lien, appel téléphonique pour la phrase secrète, toute l'infrastructure serveur dont dépendent la plupart des applications de chat devient inutile. Le lien et la phrase secrète réunis sont la mise en relation.

C'est pourquoi Btwinus tient en une seule page HTML. Rien à héberger, rien où se connecter, rien qui puisse fuiter.