Dernière mise à jour: 2026-07-01
Relayium est conçu pour que ce soient les personnes qui transfèrent les fichiers — et non le serveur — qui détiennent les clés. Cette page décrit précisément ce qui est protégé, comment cela fonctionne, et les limites de cette protection.
En bref : en mode temps réel, vos fichiers ne touchent jamais nos serveurs ; les clés de chiffrement sont générées à neuf sur chaque appareil et n'en sortent jamais ; et un court code de vérification permet à deux personnes de détecter un serveur malveillant. Les détails suivent.
Chaque transfert génère une paire de clés X25519 éphémère et nouvelle sur chaque appareil. Les deux appareils effectuent un échange de clés pour dériver une clé AES-256-GCM partagée qui n'existe qu'à l'intérieur des deux navigateurs. Chaque bloc est chiffré avec cette clé et un nonce unique, si bien que le serveur de signalisation — et tout relais — ne voit jamais que du chiffré.
Le chiffrement intégré de WebRTC (DTLS) échange les empreintes de clés via le serveur de signalisation, si bien qu'un serveur malhonnête pourrait s'interposer et permuter les clés. Pour le détecter, Relayium dérive un Short Authentication String (SAS) à 6 chiffres à partir des clés publiques des deux parties et l'affiche sur les deux écrans. Si les deux codes correspondent, personne ne s'est interposé.
Un simple code à 6 chiffres (environ 20 bits) pourrait en principe être forcé par un relais cherchant à produire un code correspondant. Relayium comble cette faille par une poignée de main « engagement puis révélation » : chaque partie s'engage d'abord sur sa clé en envoyant un hachage, et ne révèle la clé qu'après avoir reçu l'engagement de l'autre. Un serveur ne peut donc pas choisir après coup une clé provoquant une collision, et le court code reste digne de confiance.
Le service est conçu pour que les éléments suivants n'atteignent jamais nos serveurs, quel que soit le mode :
En mode temps réel, les données des fichiers ne touchent pas du tout le serveur — elles circulent directement entre les deux appareils. Le serveur de signalisation ne relaie que les messages d'établissement de connexion et voit l'appartenance à un salon (votre IP publique), un nom d'appareil que vous choisissez, et la présence.
Lorsque deux appareils ne peuvent pas ouvrir de connexion directe entre différents réseaux (NAT restrictifs ou pare-feu), le flux chiffré est relayé via un serveur TURN afin que le transfert puisse tout de même aboutir. Le pair à pair direct est toujours tenté en premier ; le relais est un repli, et les identifiants de relais ne sont délivrés qu'aux sessions par code d'appariement et par lien de partage.
Le mode optionnel de lien de téléchargement est prévu pour les cas où le destinataire n'est pas en ligne. Votre navigateur chiffre les fichiers avec AES-256-GCM avant tout envoi, et la clé de déchiffrement n'est placée que dans le fragment d'URL — la partie après le # —, que les navigateurs n'envoient jamais au serveur.
Au-delà de la confidentialité, l'intégrité de chaque fichier est vérifiée. Chaque bloc porte une étiquette d'authentification AES-GCM, et un hachage SHA-256 par fichier est vérifié de bout en bout côté destinataire, de sorte qu'un fichier corrompu ou altéré est détecté plutôt qu'accepté silencieusement.
Le chiffrement de bout en bout protège les données en transit entre deux extrémités honnêtes. Par conception, il ne peut pas protéger contre :
Relayium fonctionne dans tout navigateur moderne prenant en charge WebRTC via HTTPS. Quelques capacités diffèrent selon le navigateur :
La conception du protocole ainsi que tout le code client et serveur sont publics sur GitHub, de sorte que chacun peut auditer la cryptographie, exploiter son propre serveur ou contribuer. Si vous découvrez un problème de sécurité, veuillez le signaler en privé via le signalement de vulnérabilité GitHub du dépôt, plutôt que d'ouvrir un ticket public.