Zuletzt aktualisiert: 2026-07-01
Relayium ist so gebaut, dass die Personen, die Dateien übertragen — nicht der Server — die Schlüssel besitzen. Diese Seite beschreibt genau, was geschützt ist, wie es funktioniert und wo die Grenzen dieses Schutzes liegen.
Kurz gesagt: Im Echtzeitmodus berühren Ihre Dateien nie unsere Server; die Verschlüsselungsschlüssel werden auf jedem Gerät neu erzeugt und verlassen es nie; und ein kurzer Prüfcode erlaubt zwei Personen, einen bösartigen Server zu erkennen. Es folgen die Details.
Jede Übertragung erzeugt auf jedem Gerät ein frisches, kurzlebiges X25519-Schlüsselpaar. Die beiden Geräte führen einen Schlüsselaustausch durch und leiten daraus einen gemeinsamen AES-256-GCM-Schlüssel ab, der nur in den beiden Browsern existiert. Jeder Chunk wird mit diesem Schlüssel und einer eindeutigen Nonce verschlüsselt, sodass der Signalisierungsserver — und jede Weiterleitung — stets nur Chiffretext sieht.
Die eingebaute Verschlüsselung von WebRTC (DTLS) tauscht Schlüssel-Fingerabdrücke über den Signalisierungsserver aus, sodass ein unehrlicher Server sich dazwischenschalten und Schlüssel austauschen könnte. Um das zu erkennen, leitet Relayium aus den öffentlichen Schlüsseln beider Seiten einen 6-stelligen Short Authentication String (SAS) ab und zeigt ihn auf beiden Bildschirmen an. Stimmen die beiden Codes überein, ist niemand dazwischen.
Ein bloßer 6-stelliger Code (etwa 20 Bit) ließe sich im Prinzip von einer Weiterleitung durch Brute Force zu einem passenden Code zwingen. Relayium schließt diese Lücke mit einem Commit-dann-Offenlegen-Handshake: Jede Seite legt sich zunächst durch das Senden eines Hashes auf ihren Schlüssel fest und gibt den Schlüssel erst preis, nachdem sie die Festlegung der Gegenseite erhalten hat. Ein Server kann daher nicht nachträglich einen kollidierenden Schlüssel wählen, und der kurze Code bleibt vertrauenswürdig.
Der Dienst ist so gestaltet, dass Folgendes in keinem Modus unsere Server erreicht:
Im Echtzeitmodus berühren die Dateidaten den Server überhaupt nicht — sie fließen direkt zwischen den beiden Geräten. Der Signalisierungsserver leitet nur Nachrichten zum Verbindungsaufbau weiter und sieht die Raumzugehörigkeit (Ihre öffentliche IP), einen von Ihnen gewählten Gerätenamen und die Anwesenheit.
Wenn zwei Geräte über verschiedene Netzwerke hinweg keine direkte Verbindung aufbauen können (restriktive NATs oder Firewalls), wird der verschlüsselte Datenstrom über einen TURN-Server weitergeleitet, damit die Übertragung dennoch abgeschlossen werden kann. Zuerst wird stets eine direkte Peer-to-Peer-Verbindung versucht; die Weiterleitung ist ein Rückfall, und Weiterleitungs-Anmeldedaten werden nur an Sitzungen mit Kopplungscode und Freigabelink ausgegeben.
Der optionale Download-Link-Modus ist für den Fall gedacht, dass der Empfänger nicht online ist. Ihr Browser verschlüsselt die Dateien mit AES-256-GCM, bevor irgendetwas hochgeladen wird, und der Entschlüsselungsschlüssel wird ausschließlich im URL-Fragment abgelegt — dem Teil nach dem # —, das Browser nie an den Server senden.
Über die Vertraulichkeit hinaus wird die Integrität jeder Datei überprüft. Jeder Chunk trägt ein AES-GCM-Authentifizierungs-Tag, und ein SHA-256-Hash pro Datei wird Ende-zu-Ende auf der Empfängerseite überprüft, sodass eine beschädigte oder manipulierte Datei erkannt und nicht stillschweigend akzeptiert wird.
Ende-zu-Ende-Verschlüsselung schützt Daten während der Übertragung zwischen zwei ehrlichen Endpunkten. Konstruktionsbedingt kann sie nicht schützen vor:
Relayium läuft in jedem modernen Browser mit WebRTC über HTTPS. Einige Fähigkeiten unterscheiden sich je nach Browser:
Das Protokolldesign sowie der gesamte Client- und Servercode sind auf GitHub öffentlich, sodass jeder die Kryptografie prüfen, einen eigenen Server betreiben oder beitragen kann. Wenn Sie ein Sicherheitsproblem finden, melden Sie es bitte vertraulich über die GitHub-Schwachstellenmeldung im Repository, anstatt ein öffentliches Issue zu eröffnen.