Zuletzt aktualisiert: 2026-07-09
„Ist Relayium sicher?“ ist eine berechtigte Frage — jedes Dateiübertragungs-Tool behauptet, privat zu sein. Diese Seite erklärt in einfachen Worten, wie Relayium Dateien tatsächlich privat hält, damit Sie die Behauptung selbst beurteilen können, statt sie einfach zu glauben.
Es sind zwei unterschiedliche Verschlüsselungsverfahren im Spiel, weil es zwei unterschiedliche Situationen gibt: eine Datei live an jemanden zu senden, der gerade online ist, und einen Download-Link zu hinterlassen, den sich jemand später abholt. Beide halten den Server von Ihrer Datei fern, kommen aber auf unterschiedlichen Wegen dorthin — und es lohnt sich zu wissen, welches Verfahren wann gilt.
Wenn Sie eine Datei in Echtzeit senden — beide online, Browser zu Browser —, lässt Relayium zuerst jedes Gerät ein frisches Schlüsselpaar mit X25519 erzeugen, demselben Verfahren zum Schlüsselaustausch auf Basis elliptischer Kurven, das auch in moderner sicherer Kommunikation verbreitet ist (technisch: crypto_kx aus libsodium). Jedes Gerät behält seinen privaten Schlüssel für sich und sendet nur den öffentlichen Schlüssel an die Gegenseite.
Aus diesen beiden öffentlichen Schlüsseln berechnet jedes Gerät unabhängig dasselbe gemeinsame Geheimnis — das funktioniert genau deshalb, weil ein Schlüsselaustausch über elliptische Kurven so konstruiert ist, nicht weil das Geheimnis irgendwohin gesendet wurde. Aus diesem gemeinsamen Geheimnis wird ein AES-256-GCM-Schlüssel, der nur innerhalb der beiden Browser existiert. Jeder Chunk der Datei wird mit diesem Schlüssel und einer eindeutigen Nonce versiegelt, bevor er das Gerät des Absenders überhaupt verlässt — alles, was das Netzwerk durchquert, einschließlich des Signalisierungsservers, der den beiden Browsern half, sich zu finden, sieht also nur Chiffretext.
Hier gibt es eine Feinheit, die man offen ansprechen sollte. Die in WebRTC eingebaute Verschlüsselung (DTLS) tauscht Schlüssel-Fingerabdrücke über den Signalisierungsserver aus, der die beiden Geräte einander vorstellt. Wäre dieser Server unehrlich, könnte er sich theoretisch dazwischenschalten und eigene Schlüssel unterschieben — ein klassischer Man-in-the-Middle-Angriff, den keiner der beiden Browser sofort bemerken würde.
Relayium schließt diese Lücke mit einem kurzen Prüfcode. Beide Geräte leiten aus ihren beiden öffentlichen Schlüsseln denselben sechsstelligen Short Authentication String (SAS) ab und zeigen ihn auf dem Bildschirm an. Stimmen die Codes überein, wurden die Schlüssel nicht ausgetauscht, und niemand sitzt dazwischen. Ein einfacher sechsstelliger Code hat jedoch nur etwa 20 Bit, was ein gut positionierter Angreifer im Prinzip per Brute Force zu einem passenden Code verarbeiten könnte, nachdem er beide echten Schlüssel gesehen hat. Um das zu verhindern, nutzt Relayium einen Commit-dann-Offenlegen-Handshake: Jede Seite sendet zunächst einen Hash, der sich auf ihren Schlüssel festlegt, und gibt den echten Schlüssel erst preis, nachdem sie die Festlegung der Gegenseite erhalten hat. Diese Reihenfolge zwingt einen bösartigen Server dazu, sich blind — bevor er den echten Schlüssel gesehen hat — auf einen gefälschten Schlüssel festzulegen; er kann also nicht nachträglich einen kollidierenden Schlüssel wählen, weshalb der kurze Code vertrauenswürdig bleibt.
Verschlüsselung schützt die Vertraulichkeit, beweist aber nicht automatisch, dass unterwegs nichts beschädigt oder manipuliert wurde. Relayium prüft das gesondert: Jeder Chunk trägt sein eigenes AES-GCM-Authentifizierungs-Tag, sodass ein veränderter Chunk erst gar nicht entschlüsselt werden kann. Zusätzlich berechnen beide Seiten während der Übertragung jeder Datei fortlaufend einen SHA-256-Hash über deren Klartextinhalt; ist die Datei fertig übertragen, wird der Hash des Absenders mit dem des Empfängers verglichen. Stimmen sie überein, ist das, was auf der Festplatte gelandet ist, Byte für Byte identisch mit dem Gesendeten — stimmen sie nicht überein, wird die Datei markiert, statt stillschweigend akzeptiert zu werden.
Die Echtzeitübertragung setzt voraus, dass beide gleichzeitig online sind. Ist das nicht möglich, bietet Relayium stattdessen einen gespeicherten Download-Link an — und dieser nutzt einen wirklich anderen Mechanismus, den man nicht mit dem oben beschriebenen Echtzeitverfahren verwechseln sollte.
Hier findet kein Schlüsselaustausch statt, weil es noch kein zweites Gerät gibt, mit dem ausgetauscht werden könnte. Stattdessen erzeugt Ihr Browser einen einzigen zufälligen AES-256-GCM-Schlüssel und verschlüsselt damit die Dateien, bevor überhaupt etwas hochgeladen wird. Dieser Schlüssel wird niemals an den Server gesendet — er wird dem Download-Link nach einem #-Zeichen angehängt, im sogenannten URL-Fragment, einem Teil der Adresse, den Browser bewusst nie an einen Server übermitteln. Der Server speichert am Ende nur Chiffretext, den er auf keine Weise entschlüsseln kann, dazu Verwaltungsdaten wie die Größe des Chiffretexts und einen Ablauf-Zeitstempel. Wer den vollständigen Link öffnet — Fragment eingeschlossen —, kann die Datei lokal im eigenen Browser entschlüsseln; wer ihn nicht hat, sieht auf dem Server nur einen undurchsichtigen Datenblock. Das ist der Zero-Knowledge-Teil: Der Server hält die verschlüsselte Datei, ohne je die Mittel zu besitzen, sie zu lesen.
Es lohnt sich, genau zu benennen, wo der Server bei alldem steht, denn „Ende-zu-Ende verschlüsselt“ ist eine Behauptung, die sich leicht aufstellen, aber schwerer präzise belegen lässt. Im Echtzeitmodus berührt die Datei selbst Relayiums Server überhaupt nicht — sie wird direkt zwischen den beiden Browsern gestreamt. Die Aufgabe des Signalisierungsservers beschränkt sich darauf, Nachrichten zum Verbindungsaufbau weiterzuleiten (die technischen SDP/ICE-Informationen, die WebRTC benötigt, um eine direkte Verbindung herzustellen), damit sich die beiden Geräte finden können; er sieht nie Dateiinhalte, Dateinamen oder Schlüssel.
Ist eine direkte Verbindung nicht möglich — beide Seiten hinter restriktiven NATs oder Firewalls —, weicht der verschlüsselte Datenstrom statt komplett zu scheitern auf einen TURN-Relay-Server aus. Das Relay leitet ausschließlich Chiffretext weiter; es besitzt keinen Schlüssel und kann nicht entschlüsseln, was es durchleitet. Was es tut, ist die Anzahl der weitergeleiteten Bytes gegen das monatliche Weiterleitungskontingent des sendenden Kontos zu zählen, rein zur Abrechnung und Missbrauchsprävention — der Inhalt wird dabei nie eingesehen.
Nein. Im Echtzeitmodus wird der Verschlüsselungsschlüssel auf beiden Geräten unabhängig abgeleitet und verlässt sie nie — Relayiums Server sehen ihn ebenso wenig wie den Dateiinhalt. Bei gespeicherten Links liegt der Schlüssel nur im URL-Fragment, das Browser nie an einen Server senden, sodass der Server stets nur Chiffretext hält, den er nicht entschlüsseln kann.
Im Echtzeitmodus nur die Informationen zum Verbindungsaufbau, die nötig sind, um zwei Geräte einander vorzustellen — nie Dateidaten. Bei gespeicherten Links sieht er Chiffretext sowie Verwaltungsdaten wie Größe und Ablaufzeit — nie den Klartext, Dateinamen oder den Entschlüsselungsschlüssel.
Es ist ein Rückfall, der nur genutzt wird, wenn eine direkte Verbindung nicht möglich ist, und es verarbeitet stets nur Chiffretext — es besitzt keinen Schlüssel und kann daher nicht lesen, was es weiterleitet. Relayium zählt die weitergeleiteten Bytes gegen das monatliche Kontingent Ihres Kontos, prüft aber nie deren Inhalt.
Ja. Das Protokolldesign und der gesamte Client- und Servercode sind unter der MIT-Lizenz auf GitHub öffentlich, sodass die hier beschriebene Kryptografie unabhängig geprüft werden kann, statt sie einfach glauben zu müssen.
Brechen Sie die Übertragung ab. Eine Abweichung bedeutet, dass die Commit-dann-Offenlegen-Prüfung fehlgeschlagen ist — das deutet eher auf einen möglichen Man-in-the-Middle als auf eine harmlose Störung hin. Fahren Sie erst fort, wenn Sie den Grund verstanden haben.
Neugierig, wie das in der Praxis aussieht? Starten Sie eine Übertragung und sehen Sie den Prüfcode mit eigenen Augen erscheinen.
Relayium jetzt ausprobieren