Sécurité et modèle de menace

Dernière mise à jour: 2026-08-02

Relayium est conçu pour que ce soient les personnes qui transfèrent les fichiers ou textes temporaires — 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 : sur le même réseau, les fichiers et messages en temps réel circulent directement entre appareils. Entre réseaux, les sessions du navigateur utilisent un relais qui ne transporte que du chiffré de bout en bout et ne possède aucune clé de contenu. Des clés de session neuves sont toujours utilisées ; un code facultatif, comparé hors bande, permet en plus aux deux personnes de détecter une interception de la signalisation. Les détails suivent.

Chiffrement des fichiers en temps réel dans le navigateur (X25519 + AES-256-GCM)

Pour les fichiers en temps réel dans le navigateur, chaque transfert crée une paire de clés X25519 éphémère sur chaque appareil. Les deux navigateurs dérivent une clé AES-256-GCM partagée et chiffrent chaque bloc avec un nonce unique : la signalisation et le relais voient du chiffré, jamais le fichier en clair. Les transferts CLI utilisent un protocole direct TLS 1.3 distinct décrit plus bas.

• Les clés sont éphémères et propres à chaque transfert — rien n'est réutilisé d'une session à l'autre.
• La clé partagée est dérivée sur les deux appareils ; elle n'est jamais envoyée à un serveur ni stockée sur celui-ci.
• Le chiffrement est appliqué au niveau applicatif, au-dessus de la sécurité de transport propre à WebRTC, et tient donc même si la couche de transport est compromise.

Le code de vérification (SAS) — détecter un serveur malveillant

Le chiffrement intégré de WebRTC (DTLS) échange les empreintes via le serveur de signalisation, qui pourrait tenter de permuter les clés. Relayium peut donc afficher un Short Authentication String (SAS) à 6 chiffres sur les deux écrans. Des codes identiques offrent le contrôle le plus fort uniquement si les deux personnes les comparent hors bande. Afficher ce code et s'arrêter pour le comparer est un réglage — « vérification avancée » sur le web (désactivée par défaut), `--verify` dans la CLI. Le désactiver change ce qui est affiché et les étapes qui s'interrompent pour une confirmation ; cela ne change pas le chiffrement. La poignée de main « engagement puis révélation » ci-dessous s'exécute sur chaque connexion et refuse celle dont la révélation ne correspond pas, les clés sont toujours générées sur votre appareil et ne nous sont jamais envoyées, le relais ne transporte toujours que du chiffré, et dans le navigateur, la réception de fichiers demande toujours avant d'enregistrer quoi que ce soit : l'application native macOS, elle, écrit sans demander dans son dossier de destination configuré (« Téléchargements » par défaut). Cette demande empêche une écriture non sollicitée sur votre disque ; elle ne dit rien de l'identité de votre interlocuteur, que seule la comparaison du code établit.

La poignée de main « engagement puis révélation » empêche le serveur de choisir après coup une clé produisant une collision. Les transferts CLI utilisent un SAS distinct, dérivé par engagement puis révélation des empreintes du certificat TLS épinglé ; lui aussi ne détecte rien si personne ne le compare réellement hors bande, ce pour quoi `--verify` s'arrête.

• Pour la garantie la plus forte, activez la vérification avancée et comparez le code hors bande — en personne ou par appel vocal.
• Si les deux codes diffèrent, interrompez le transfert : quelqu'un intercepte peut-être la connexion.

Le clair que le serveur ne peut ni voir ni déchiffrer

Nos serveurs sont conçus pour ne pouvoir ni voir ni déchiffrer les éléments suivants en clair :

Sur le même réseau, fichiers et messages en temps réel circulent directement entre appareils. Entre réseaux, ils passent par TURN sous forme chiffrée, sans que le relais possède la clé. La signalisation traite néanmoins les données de connexion et voit des métadonnées comme les IP publiques, l'appartenance à la salle, l'heure, le nom d'appareil choisi et la présence.

• Le contenu de vos fichiers.
• Les noms de vos fichiers.
• Le texte en clair de vos messages.
• Vos clés de chiffrement.

Quand les fichiers et textes du navigateur sont relayés (TURN)

Les transferts de fichiers et de texte du navigateur entre réseaux passent par TURN par conception, et non en repli. L'application impose ce trajet car les NAT et pare-feu rendent une liaison directe improbable. Les sessions navigateur sur le même réseau se connectent directement sans identifiants de relais. Les transferts CLI de fichiers et de texte n'utilisent jamais TURN : ils sont uniquement directs et échouent sans trajet direct.

• Le relais ne transmet que du chiffré — il ne peut lire ni vos fichiers ni vos messages, qui restent chiffrés de bout en bout.
• Nous enregistrons le nombre d'octets relayés par compte, afin d'appliquer un quota de relais mensuel et de prévenir les abus — nous n'inspectons jamais ce qui est relayé, seulement le nombre d'octets.
• Nous n'inspectons jamais le contenu relayé.

Transfert de texte temporaire

Les sessions de texte du navigateur utilisent le protocole Web : les pairs effectuent un échange X25519 éphémère et dérivent des sous-clés AES-256-GCM séparées par direction, dans un domaine distinct des clés de transfert de fichiers. Chaque message UTF-8 valide est authentifié et chiffré dans sa propre trame. Entre réseaux, les sessions du navigateur utilisent TURN par conception ; le relais transporte du chiffré et ne possède aucune clé de message. Avec la vérification avancée activée, comparer le SAS hors bande détecte en plus une interception de la signalisation.

Le texte CLI utilise un protocole différent, exclusivement direct, sur TLS 1.3 avec certificat épinglé. Il n'utilise ni les trames X25519/AES du navigateur ni TURN, et échoue si aucun trajet direct ne peut être établi. Relayium ne stocke pas le corps des messages, mais chaque extrémité peut copier, journaliser, capturer ou conserver autrement le texte reçu.

• Les deux personnes doivent être en ligne en même temps ; Relayium ne fournit ni livraison de texte hors ligne ni historique de messages côté serveur.
• Les serveurs traitent nécessairement des métadonnées de connexion telles que les adresses IP, l'appartenance à la salle, l'heure, le nom d'appareil et la présence pour les sessions navigateur, ainsi que, le cas échéant, le compte associé à la création d'un code d'appairage.
• Pour les sessions TURN, Relayium peut comptabiliser les octets relayés afin d'appliquer les quotas et de prévenir les abus, mais n'inspecte pas le texte en clair des messages.

Liens de téléchargement stockés — la clé ne quitte jamais votre navigateur

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.

• Le serveur ne stocke que du chiffré, plus la taille du chiffré et des horodatages pour les quotas et le nettoyage — jamais de clair, de noms de fichiers ni de clés.
• Quiconque possède le lien complet peut déchiffrer ; traitez donc le lien comme le fichier lui-même et partagez-le par un canal de confiance.
• Les liens peuvent être réglés pour expirer (de 1 heure à 14 jours au maximum, selon votre offre) ou pour s'effacer après le premier téléchargement complet.

Intégrité des fichiers (SHA-256)

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.

Ce contre quoi Relayium ne protège pas

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 :

• Un appareil ou un navigateur compromis à l'une des extrémités — logiciel malveillant, extension de navigateur hostile, ou quelqu'un qui regarde l'écran.
• Les métadonnées nécessaires : horaires de session, nombre d'octets relayés et, pour un lien stocké ou une session par code d'appairage, le compte qui a créé le lien ou le code.
• Un destinataire qui conserve, copie ou transmet des fichiers ou messages après réception.
• Le partage d'un lien de téléchargement par un canal non fiable, puisque la clé de déchiffrement voyage dans le lien.

Prise en charge des navigateurs et ses limites

Relayium fonctionne dans tout navigateur moderne prenant en charge WebRTC via HTTPS. Quelques capacités diffèrent selon le navigateur :

• Chrome et Edge sur ordinateur disposent de l'API File System Access et diffusent les gros fichiers directement sur le disque, sans plafond de mémoire pratique.
• Firefox, Safari et tous les navigateurs mobiles (sur iOS, tous les navigateurs sont WebKit) n'ont pas cette API et assemblent le fichier en mémoire sur le trajet temps réel ; l'application avertit donc au-delà d'environ 256 Mo — un repère volontairement prudent, pas une limite mesurée. Pour des fichiers de cette taille, préférez Chrome/Edge sur ordinateur, ou le mode lien de téléchargement, dont la page de téléchargement peut en outre écrire sur le disque via un service worker.
• WebRTC exige un contexte sécurisé (HTTPS) ; l'application ne se connecte pas en HTTP simple.

Open source et signalement des problèmes

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.