Principe de fonctionnement

Hard-Chat propose un échange de messages texte entre deux navigateurs via WebRTC, sans aucune composante serveur côté application. L’utilisateur crée ou rejoint une « Room » en générant une chaîne aléatoire de 100 caractères, qui constitue le seul secret partagé. Cette clé doit être transmise hors‑bande (voix, rencontre physique, autre canal chiffré) avant que la connexion ne s’établisse.

Le protocole repose sur le Web Crypto API du navigateur pour dériver une clé de chiffrement à partir de la Room Key et sur le WebRTC DataChannel pour le transport. Aucun cookie, aucune entrée dans le localStorage et aucune base de données ne sont utilisés ; la fermeture de l’onglet supprime immédiatement toutes les données en mémoire.

Architecture et échange de clés

Le processus de dérivation utilise PBKDF2 avec 100 000 itérations, SHA‑256 comme fonction de hachage et un sel fixe "p2p-zero-trace-salt-v1". Le résultat est une clé AES‑GCM de 256 bits, appliquée à chaque message. Le code suivant montre la dérivation :

PBKDF2(
  password = Room Key,
  salt = "p2p-zero-trace-salt-v1",
  iterations = 100000,
  hash = SHA-256
) → 256‑bit AES‑GCM key

Parallèlement, le même Room Key est haché en SHA‑256 et les 32 premiers caractères hexadécimaux sont préfixés par "ztt-" pour former l’identifiant PeerJS. Cet identifiant sert uniquement au signalement auprès du broker public PeerJS ; il n’intervient pas dans le chiffrement.

Gestion de la connexion et des serveurs ICE

Après l’échange d’identifiants, les deux pairs initient la négociation ICE. Hard‑Chat configure 18 serveurs ICE : un serveur TURN dédié (metered.ca) suivi de 7 serveurs STUN publics (Google, Cloudflare, Twilio, etc.) et de 10 serveurs TURN publics supplémentaires. Le navigateur teste chaque combinaison selon l’algorithme ICE standard et sélectionne la première voie fonctionnelle, qu’il s’agisse d’une adresse locale, d’une adresse publique découverte via STUN ou d’un relais TURN.

Si aucune voie n’est établie en 120 secondes, la session expire : le PeerJS object est détruit, la connexion DataChannel est fermée et le statut passe à [EXPIRED]. Un nouveau Room Key doit alors être généré, garantissant que la clé ne reste pas active indéfiniment sur le broker.

Analyse de la sécurité et limites

Chaque message est chiffré individuellement : un IV de 12 octets est généré aléatoirement, le texte clair est encrypté en AES‑GCM, puis le IV est préfixé au ciphertext avant l’envoi. Le récepteur extrait l’IV, déchiffre le payload et vérifie l’authenticité grâce au tag GCM de 16 octets. Toute altération entraîne une erreur de déchiffrement, empêchant la récupération de données corrompues.

Le modèle présente deux limites majeures. Premièrement, l’absence de secret éphémère signifie qu’une réutilisation de la même Room Key créerait une clé de chiffrement identique, compromettant la confidentialité inter‑sessions. Deuxièmement, l’authentification de l’identité du pair repose uniquement sur la possession du Room Key ; un tiers qui obtient la clé peut se connecter sans preuve supplémentaire. Le sel fixe de PBKDF2 n’est pas un facteur de faiblesse majeur ici, car la clé brute possède déjà un niveau d’entropie très élevé (≈ 600 bits). Enfin, le projet ne garantit pas l’anonymat réseau : le trafic passe par les serveurs STUN/TURN qui peuvent voir les adresses IP, d’où la recommandation d’utiliser un VPN sur chaque appareil.