Wie Relayium deine Dateien Ende-zu-Ende verschlüsselt

Zuletzt aktualisiert: 2026-08-06

„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 du die Behauptung selbst beurteilen kannst, 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 deiner Datei fern, kommen aber auf unterschiedlichen Wegen dorthin — und es lohnt sich zu wissen, welches Verfahren wann gilt.

Live-Übertragungen: Zwei Geräte einigen sich auf ein Geheimnis, das der Server nie sieht

Wenn du eine Datei in Echtzeit sendest — 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 Block 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.

Für jede Übertragung wird ein neues Schlüsselpaar erzeugt — nichts wird über Sitzungen hinweg wiederverwendet.
Der gemeinsame AES-256-GCM-Schlüssel wird auf jedem Gerät unabhängig abgeleitet; er wird nie irgendwohin übertragen, auch nicht an Relayiums eigene Server.
Die Verschlüsselung erfolgt auf der Anwendungsebene, oberhalb der eigenen Transportsicherheit von WebRTC, und bleibt daher selbst dann wirksam, wenn diese Transportebene jemals kompromittiert würde.

Der sechsstellige Code, der einen unehrlichen Server entlarvt

Was du für diesen Vergleich brauchst

Beide Geräte vor dir — oder eine andere Person, die gerade an ihrem sitzt.
Einen Kanal, der nicht diese Übertragung ist: ein Telefonat, oder der Raum, in dem ihr beide seid. Den Code in genau den Chat zu kopieren, um den du dir Sorgen machst, beweist nichts.
Zehn Sekunden. Das ist der gesamte Preis der einzigen Prüfung, die einen unehrlichen Server auffliegen lässt.

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 Verifizierungscode. Beide Geräte leiten aus ihren beiden öffentlichen Schlüsseln denselben sechsstelligen Short Authentication String (SAS) ab und können ihn auf dem Bildschirm anzeigen. Ob er angezeigt und für den Vergleich angehalten wird, ist die „erweiterte Verifizierung“ und standardmäßig aus — eine Standardübertragung zeigt also keinen Code. Alles andere hier Beschriebene läuft bei jeder Übertragung unverändert weiter: die frischen Schlüssel, die Verschlüsselung, der Commit-dann-Offenlegen-Handshake und die Authentifizierung jedes Chunks. Was einer Standardübertragung fehlt, ist genau diese Prüfung — einen ausgetauschten Schlüssel oder eine fremde Gegenstelle erkennt man nur mit eingeschalteter erweiterter Verifizierung und wenn beide Personen den Code tatsächlich über einen anderen Kanal vergleichen. Stimmen die Codes überein, wurden die öffentlichen Schlüssel nicht ausgetauscht: Der Signalisierungs- oder Relay-Server hat sich weder als einer der Endpunkte ausgegeben noch die Ende-zu-Ende-Verschlüsselung auf Anwendungsebene beendet. Das bedeutet nicht, dass sich kein Server im Netzwerkpfad befand — netzwerkübergreifender Geheimtext kann weiterhin planmäßig über TURN laufen. 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.

Starte eine Übertragung zwischen den beiden Geräten und warte, bis auf jedem Bildschirm ein Verifizierungscode steht.
```
https://relayium.com/
```
Lies einen davon Ziffer für Ziffer über den Nebenkanal vor — nicht in die App kopieren und nicht in denselben Chat-Verlauf.
Vergleiche alle sechs Ziffern. Teilweise Übereinstimmung ist keine Übereinstimmung.
Nimm nur an, wenn sie gleich sind. Weichen sie ab, lehn ab und kläre erst, an welchem Rechner die andere Person wirklich sitzt.
Auf der CLI machst du den Vergleich verbindlich statt optional: --verify hält die Übertragung genau dort an und wartet auf deine Bestätigung, es bewegt sich also kein Byte, bevor jemand wirklich hingesehen hat.
```
relayium send --verify ./report.pdf
```

Was ein übereinstimmender Vergleich beweist — und was nicht

Zwei Bildschirme mit denselben sechs Ziffern heißen, dass die von beiden Enden gepinnten Zertifikat-Fingerprints übereinstimmen — der Rendezvous hat also keine Gegenstelle ausgetauscht und keine Seite imitiert. Genau darum geht es in diesem Abschnitt.

Er authentifiziert die beiden Endpunkte. Über jeden Netzwerk-Hop dazwischen sagt er nichts, und wenn ihn niemand vergleicht, sagt er überhaupt nichts — dafür gibt es --verify.

Für die stärkste Garantie schalte die erweiterte Verifizierung ein und lies den Code laut in einem Anruf vor oder vergleiche ihn persönlich — nicht nur mit den Augen auf zwei nebeneinanderliegenden Bildschirmen.
Stimmen die beiden Codes nicht überein, brich ab — das ist ein Hinweis darauf, dass jemand die Verbindung abfangen könnte.

Sicherstellen, dass ankommt, was gesendet wurde

Verschlüsselung schützt die Vertraulichkeit, beweist aber nicht automatisch, dass unterwegs nichts beschädigt oder manipuliert wurde. Relayium prüft das gesondert: Jeder Block trägt sein eigenes AES-GCM-Authentifizierungs-Tag, sodass ein veränderter Block 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.

Gespeicherte Links: ein anderer Schlüssel, einmal erzeugt, nur im Link vorhanden

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 dein 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.

Das Erstellen eines gespeicherten Links erfordert die Anmeldung des Absenders; das Öffnen zum Herunterladen erfordert nie ein Konto.
Links können so eingestellt werden, dass sie nach 1 Stunde, 1, 3, 7 oder bis zu 14 Tagen je nach Tarif ablaufen, oder dass sie nach dem ersten vollständigen Download verfallen.
Behandle den vollständigen Link wie die Datei selbst — jeder, der ihn besitzt, kann ihn entschlüsseln, teile ihn also so, wie du die Datei teilen würdest.

Was der Server sehen kann — und was nicht

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 im selben Netzwerk 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.

Netzübergreifend — wo restriktive NATs oder Firewalls einen direkten Pfad ohnehin oft ausschließen — läuft der verschlüsselte Datenstrom über einen TURN-Relay-Server. 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.

Wenn der Vergleich schiefgeht

Drei Ausgänge, und nur der erste ist ein Notfall. Zu erkennen, welchen du vor dir hast, ist schon der größte Teil des Nutzens.

Was du siehst, was du prüfst, was es bedeutet

Die beiden Bildschirme zeigen unterschiedliche Codes.

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

Hör auf und schick die Datei nicht. Unterschiedliche Codes heißen, dass die beiden Enden verschiedene Zertifikat-Fingerprints gepinnt haben — die Gegenstelle ist also nicht der Rechner, für den du sie hältst. Kläre über einen Nebenkanal, an welchem Gerät die andere Person sitzt, und fang neu an. Ein erneuter Lauf mit --verify lässt die Übertragung an diesem Vergleich warten, statt ihn deiner Aufmerksamkeit zu überlassen.

Es ist noch kein Verifizierungscode erschienen.

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

Der Code wird aus einer Verbindung abgeleitet, er existiert also, sobald die beiden Enden verbunden sind. Vorher gibt es nichts zu vergleichen, und eine Übertragung, die nie zustande kommt, ist ein anderes Problem als eine mit abweichenden Codes.

Du hast die Codes verglichen, indem du einen in den ohnehin benutzten Chat kopiert hast.

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

Damit prüfst du nicht, was du prüfen wolltest. Wenn genau dieser Kanal deine Sorge ist, kann ein Angreifer, der die Übertragung verändern kann, auch den hineinkopierten Code verändern. Lies ihn vor, oder nimm einen Kanal, der anders ausfällt als der, den du gerade überprüfst.

Häufige Fragen

Kann Relayium meine Dateien lesen?

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.

Was sieht der Server tatsächlich?

Im Echtzeitmodus im selben Netzwerk nur die Informationen zum Verbindungsaufbau, die nötig sind, um zwei Geräte einander vorzustellen — nie Dateidaten. Netzübergreifend transportiert das TURN-Relay die Dateidaten sehr wohl, aber nur als Chiffretext, für den es keinen Schlüssel besitzt. Bei gespeicherten Links sieht er Chiffretext sowie Verwaltungsdaten wie Größe und Ablaufzeit — nie den Klartext, Dateinamen oder den Entschlüsselungsschlüssel.

Ist das TURN-Relay eine Schwachstelle?

Im Browser trägt es von Grund auf jede netzwerkübergreifende Übertragung, nicht nur die, bei denen ein direkter Pfad scheiterte — es verarbeitet dabei aber stets nur Chiffretext und besitzt keinen Schlüssel, kann also nicht lesen, was es weiterleitet. Relayium zählt die weitergeleiteten Bytes gegen das monatliche Kontingent deines Kontos, prüft aber nie deren Inhalt.

Ist Relayium Open Source?

Ja. Das Protokolldesign und der gesamte Client- und Servercode sind unter der AGPL-3.0-Lizenz auf GitHub öffentlich, sodass die hier beschriebene Kryptografie unabhängig geprüft werden kann, statt sie einfach glauben zu müssen.

Was, wenn die beiden Verifizierungscodes auf dem Bildschirm nicht übereinstimmen?

Brich die Übertragung ab. Zwei verschiedene Codes bedeuten, dass die beiden Geräte nicht dieselbe Verbindung sehen — genau das, was ein ausgetauschter Schlüssel oder ein Man-in-the-Middle erzeugt, und keine harmlose Störung. (Ein fehlgeschlagener Commit-dann-Offenlegen-Handshake ist ein anderer, früherer Fehler: Er bricht die Verbindung selbst ab, bevor überhaupt ein Code angezeigt wird.) Fahre erst fort, wenn du den Grund verstanden hast.

Neugierig, wie das in der Praxis aussieht? Schalte die erweiterte Verifizierung ein, bevor du eine neue Verbindung startest — dann gelten der Codevergleich und die Bestätigungsschritte von Anfang an.

Relayium jetzt ausprobieren