Comment Relayium chiffre vos fichiers de bout en bout

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

« Relayium est-il sécurisé ? » est une question légitime — tout outil de transfert de fichiers prétend protéger la vie privée. Cette page explique exactement, en langage simple, comment Relayium garde vos fichiers privés, pour que vous puissiez juger l'affirmation plutôt que la croire sur parole.

Deux mécanismes de chiffrement différents entrent en jeu, parce qu'il y a deux situations différentes : envoyer un fichier en direct à quelqu'un qui est en ligne à l'instant, et laisser un lien de téléchargement pour que quelqu'un le récupère plus tard. Les deux empêchent le serveur d'accéder à votre fichier, mais y parviennent par des chemins différents — et il vaut la peine de savoir lequel s'applique quand.

Transferts en direct : deux appareils s'accordent sur un secret que le serveur ne voit jamais

Quand vous envoyez un fichier en temps réel — les deux personnes en ligne, navigateur à navigateur —, Relayium commence par faire générer à chaque appareil une nouvelle paire de clés avec X25519, le même échange de clés à courbe elliptique utilisé dans la messagerie sécurisée moderne (techniquement, crypto_kx de libsodium). Chaque appareil garde sa clé privée pour lui et n'envoie que sa clé publique à l'autre partie.

À partir de ces deux clés publiques, chaque appareil calcule indépendamment le même secret partagé — un processus qui fonctionne précisément grâce à la construction mathématique de l'échange de clés à courbe elliptique, et non parce que le secret aurait été envoyé quelque part. Ce secret partagé devient une clé AES-256-GCM qui n'existe qu'à l'intérieur des deux navigateurs. Chaque bloc du fichier est scellé avec cette clé et un nonce unique avant même de quitter l'appareil de l'expéditeur, si bien que tout ce qui traverse le réseau — y compris le serveur de signalisation qui a aidé les deux navigateurs à se trouver — ne voit jamais que du texte chiffré.

Une nouvelle paire de clés est générée à chaque transfert — rien n'est réutilisé d'une session à l'autre.
La clé AES-256-GCM partagée est dérivée indépendamment sur chaque appareil ; elle n'est jamais transmise nulle part, y compris aux propres serveurs de Relayium.
Le chiffrement s'applique au niveau applicatif, au-dessus de la sécurité de transport propre à WebRTC, et tient donc même si cette couche de transport venait à être compromise.

Le code à 6 chiffres qui démasque un serveur malhonnête

Ce qu'il vous faut pour cette comparaison

Les deux appareils devant vous, ou une autre personne qui est devant le sien en ce moment.
Un canal qui n'est pas ce transfert : un appel, ou la pièce où vous êtes tous les deux. Coller le code dans la conversation même qui vous inquiète ne prouve rien.
Dix secondes. C'est tout le coût de la seule vérification capable de démasquer un serveur malhonnête.

Il y a une subtilité qu'il vaut la peine d'exposer honnêtement. Le chiffrement intégré de WebRTC (DTLS) échange les empreintes de clés via le serveur de signalisation qui présente les deux appareils l'un à l'autre. Si ce serveur était malhonnête, il pourrait en théorie s'interposer et substituer ses propres clés — une attaque classique de l'homme du milieu — sans qu'aucun des deux navigateurs ne le remarque immédiatement.

Relayium comble cette faille avec un court code de vérification. Les deux appareils dérivent le même Short Authentication String (SAS) à 6 chiffres à partir de leurs deux clés publiques et peuvent l'afficher à l'écran. L'afficher et s'arrêter pour le comparer relève de la « vérification avancée », désactivée par défaut — un transfert par défaut n'affiche donc aucun code. Tout le reste de ce qui est décrit ici s'applique à chaque transfert : les clés régénérées, le chiffrement, la poignée de main « engagement puis révélation » et l'authentification de chaque fragment. Ce qui manque à un transfert par défaut, c'est cette comparaison elle-même — détecter une clé substituée, ou un inconnu à l'autre bout, suppose la vérification avancée activée et deux personnes qui comparent réellement le code par un autre canal. Si les codes correspondent, les clés publiques n'ont pas été substituées : le serveur de signalisation ou de relais n'a usurpé aucun des deux terminaux ni interrompu le chiffrement de bout en bout au niveau applicatif. Cela ne signifie pas qu'aucun serveur ne se trouvait sur le chemin réseau — le texte chiffré entre réseaux peut toujours transiter par TURN comme prévu. Mais un simple code à 6 chiffres ne représente qu'environ 20 bits, ce qu'un attaquant bien placé pourrait en principe tenter de forcer par force brute pour obtenir une correspondance après avoir vu les deux vraies clés. Pour l'empêcher, Relayium utilise une poignée de main « engagement puis révélation » : chaque partie envoie d'abord un hachage qui l'engage sur sa clé, et ne révèle la vraie clé qu'après avoir reçu l'engagement de l'autre. Cet ordre oblige un serveur malveillant à s'engager sur une fausse clé à l'aveugle, avant d'avoir vu la vraie — il ne peut donc pas choisir après coup une clé provoquant une collision, et le code court reste digne de confiance.

Lancez un transfert entre les deux appareils et attendez qu'un code de vérification s'affiche sur chaque écran.
```
https://relayium.com/
```
Lisez l'un d'eux à voix haute, chiffre par chiffre, par le canal hors bande — sans le copier dans l'application ni dans le même fil de discussion.
Comparez les six chiffres. Une correspondance partielle est une divergence.
N'acceptez que s'ils sont identiques. S'ils diffèrent, refusez et déterminez sur quelle machine se trouve réellement l'autre personne avant de recommencer.
En ligne de commande, rendez la comparaison bloquante plutôt qu'optionnelle : --verify arrête le transfert à cet endroit et attend votre confirmation, si bien qu'aucun octet ne bouge tant que personne n'a réellement regardé.
```
relayium send --verify ./report.pdf
```

Ce qu'une comparaison concordante prouve, et ce qu'elle ne prouve pas

Deux écrans affichant les mêmes six chiffres signifient que les empreintes de certificat épinglées par les deux extrémités concordent : le rendez-vous n'a donc pas substitué d'extrémité ni usurpé l'identité de l'une des deux. C'est exactement l'attaque dont parle cette section.

Cela authentifie les deux extrémités. Cela ne prouve rien sur chaque saut réseau intermédiaire, et cela ne prouve rien du tout si personne ne compare — d'où l'existence de --verify.

Pour la garantie la plus forte, activez la vérification avancée, puis lisez le code à voix haute lors d'un appel ou comparez-le en personne, pas seulement des yeux sur deux écrans côte à côte.
Si les deux codes ne correspondent pas, arrêtez-vous — considérez cela comme un signe que quelqu'un intercepte peut-être la connexion.

S'assurer que ce qui arrive est exactement ce qui a été envoyé

Le chiffrement protège la confidentialité, mais ne prouve pas automatiquement que rien n'a été corrompu ou altéré en chemin. Relayium le vérifie séparément : chaque bloc porte sa propre étiquette d'authentification AES-GCM, si bien qu'un bloc modifié échoue purement et simplement à se déchiffrer. En plus de cela, pendant l'envoi de chaque fichier, les deux parties calculent en continu un hachage SHA-256 sur son contenu en clair ; une fois le fichier terminé, le hachage de l'expéditeur est comparé à celui du destinataire. S'ils correspondent, ce qui atterrit sur le disque est identique octet par octet à ce qui a été envoyé — sinon, le fichier est signalé plutôt qu'accepté silencieusement.

Liens stockés : une clé différente, générée une seule fois, présente uniquement dans le lien

Le transfert en temps réel exige que les deux personnes soient en ligne en même temps. Quand ce n'est pas possible, Relayium propose à la place un lien de téléchargement stocké — qui utilise un mécanisme réellement différent, à ne pas confondre avec celui du temps réel décrit ci-dessus.

Il n'y a pas d'échange de clés ici, car il n'existe pas encore de second appareil avec qui échanger. À la place, votre navigateur génère une unique clé AES-256-GCM aléatoire et l'utilise pour chiffrer les fichiers avant tout envoi. Cette clé n'est jamais envoyée au serveur — elle est ajoutée au lien de téléchargement après un caractère #, dans ce qu'on appelle le fragment d'URL, une partie de l'adresse que les navigateurs ne transmettent délibérément jamais à un serveur. Le serveur finit par ne stocker que du texte chiffré qu'il n'a aucun moyen de déchiffrer, plus des informations de gestion comme la taille du texte chiffré et un horodatage d'expiration. Quiconque ouvre le lien complet — fragment compris — peut déchiffrer le fichier localement dans son navigateur ; quiconque ne l'a pas ne voit qu'un bloc opaque sur le serveur. C'est la partie « divulgation nulle » : le serveur détient le fichier chiffré sans jamais détenir les moyens de le lire.

Créer un lien stocké exige que l'expéditeur se connecte ; ouvrir un lien pour le télécharger ne l'exige jamais.
Les liens peuvent être réglés pour expirer après 1 heure, 1, 3, 7 ou jusqu'à 14 jours selon votre offre, ou pour s'effacer après le premier téléchargement complet.
Traitez le lien complet comme le fichier lui-même — quiconque le possède peut le déchiffrer, alors partagez-le comme vous partageriez le fichier.

Ce que le serveur peut voir — et ce qu'il ne peut pas

Il vaut la peine de préciser exactement où se situe le serveur dans tout cela, car « chiffré de bout en bout » est une affirmation facile à faire et plus difficile à faire avec précision. En mode temps réel sur le même réseau, le fichier lui-même ne touche jamais les serveurs de Relayium — il circule directement entre les deux navigateurs. Le rôle du serveur de signalisation se limite à relayer les messages d'établissement de connexion (les informations techniques SDP/ICE dont WebRTC a besoin pour établir un lien direct) afin que les deux appareils puissent se trouver ; il ne voit jamais le contenu des fichiers, leurs noms, ni les clés.

Entre réseaux — où des NAT ou des pare-feu restrictifs excluent souvent tout chemin direct —, le flux chiffré passe par un serveur relais TURN. Le relais ne transmet que du texte chiffré ; il n'a pas de clé et ne peut pas déchiffrer ce qui le traverse. Ce qu'il fait, c'est compter les octets qu'il relaie au titre du quota mensuel de relais du compte expéditeur, uniquement à des fins de mesure et de prévention des abus — sans jamais inspecter ce qu'il contient.

Quand la comparaison tourne mal

Trois issues, et seule la première est une urgence. Savoir laquelle vous avez sous les yeux constitue déjà l'essentiel de l'intérêt.

Ce que vous voyez, ce qu'il faut vérifier, ce que cela signifie

Les deux écrans affichent des codes différents.

https://relayium.com/   # the two screens show different verification codes

Arrêtez-vous et n'envoyez pas le fichier. Des codes différents signifient que les deux extrémités ont épinglé des empreintes de certificat distinctes : l'autre bout n'est donc pas la machine que vous croyez. Confirmez hors bande sur quel appareil se trouve l'autre personne, puis recommencez. Relancer avec --verify fait attendre le transfert à cette comparaison au lieu de la laisser à votre vigilance.

Aucun code de vérification n'est apparu.

https://relayium.com/   # no verification code on screen yet

Le code se dérive d'une connexion : il existe donc dès que les deux extrémités sont connectées. Avant cela il n'y a rien à comparer, et un transfert qui ne se connecte jamais est un problème différent d'un transfert dont les codes divergent.

Vous avez comparé les codes en en collant un dans la conversation que vous utilisiez déjà.

relayium send --verify ./report.pdf   # holds the transfer at the comparison

Cela ne teste pas ce que vous vouliez tester. Si c'est précisément ce canal qui vous inquiète, un attaquant capable de modifier le transfert peut aussi modifier le code collé. Lisez-le à voix haute, ou utilisez un canal dont le mode de défaillance diffère de celui que vous êtes en train de contrôler.

Questions fréquentes

Relayium peut-il lire mes fichiers ?

Non. En mode temps réel, la clé de chiffrement est dérivée indépendamment sur les deux appareils et ne les quitte jamais — les serveurs de Relayium ne la voient jamais, pas plus que le contenu des fichiers. Pour les liens stockés, la clé ne vit que dans le fragment d'URL, que les navigateurs n'envoient jamais à un serveur, si bien que le serveur ne détient jamais que du texte chiffré qu'il ne peut pas déchiffrer.

Que voit réellement le serveur ?

En mode temps réel sur le même réseau, uniquement les informations d'établissement de connexion nécessaires pour présenter deux appareils l'un à l'autre — jamais les octets du fichier. Entre réseaux, le relais TURN transporte bien ces octets, mais uniquement sous forme de texte chiffré dont il n'a pas la clé. Pour les liens stockés, il voit du texte chiffré ainsi que des informations de gestion comme la taille et la date d'expiration — jamais le contenu en clair, les noms de fichiers, ni la clé de déchiffrement.

Le relais TURN est-il un point faible ?

Dans le navigateur, il achemine par conception tous les transferts entre réseaux, et pas seulement ceux où une liaison directe a échoué — mais il ne traite toujours que du texte chiffré, et il n'a pas de clé, donc il ne peut pas lire ce qu'il relaie. Relayium compte les octets relayés au titre du quota mensuel de votre compte, mais n'inspecte jamais leur contenu.

Relayium est-il open source ?

Oui. La conception du protocole et tout le code client et serveur sont publics sur GitHub sous licence AGPL-3.0, si bien que la cryptographie décrite ici peut être auditée de façon indépendante plutôt que crue sur parole.

Que faire si les deux codes de vérification à l'écran ne correspondent pas ?

Arrêtez le transfert. Deux codes différents signifient que les deux appareils ne voient pas la même connexion — c'est exactement ce que produirait une clé substituée ou un homme du milieu, et non un incident bénin. (L'échec de la poignée de main « engagement puis révélation » est une autre défaillance, plus précoce : elle interrompt la connexion elle-même, avant qu'un code soit affiché.) Ne poursuivez pas avant d'avoir compris pourquoi.

Curieux de voir à quoi cela ressemble en pratique ? Activez la vérification avancée avant de lancer une nouvelle connexion : la comparaison du code et les étapes de confirmation s'appliquent alors dès le début.

Essayer Relayium maintenant