Relayium

Sicherheit & Bedrohungsmodell

Zuletzt aktualisiert: 2026-08-02

Relayium ist so gebaut, dass die Personen, die Dateien oder temporäre Texte ü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 selben Netzwerk fließen Echtzeitdateien und -nachrichten direkt zwischen Geräten. Netzwerkübergreifende Browsersitzungen nutzen ein Relay, das nur Ende-zu-Ende-verschlüsselten Chiffretext transportiert und keinen Inhaltsschlüssel besitzt. Frische Sitzungsschlüssel gibt es immer; ein optionaler, außerhalb des Kanals verglichener Prüfcode hilft beiden Personen zusätzlich, Eingriffe in die Signalisierung zu erkennen. Es folgen die Details.

Browser-Echtzeitverschlüsselung für Dateien (X25519 + AES-256-GCM)

Bei Echtzeit-Dateiübertragungen im Browser erzeugt jede Übertragung auf jedem Gerät ein frisches, kurzlebiges X25519-Schlüsselpaar. Die beiden Browser führen einen Schlüsselaustausch durch und leiten einen gemeinsamen AES-256-GCM-Schlüssel ab. Jeder Datei-Chunk wird mit diesem Schlüssel und einer eindeutigen Nonce verschlüsselt, sodass Signalisierungsserver und Relay Chiffretext statt Dateiklartext sehen. CLI-Übertragungen verwenden ein anderes direktes TLS-1.3-Protokoll, das unten beschrieben wird.

Der Verifizierungscode (SAS) — einen bösartigen Server erkennen

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. Relayium leitet deshalb aus den öffentlichen Schlüsseln beider Seiten einen 6-stelligen Short Authentication String (SAS) ab, der auf beiden Bildschirmen angezeigt werden kann. Übereinstimmende Codes bieten nur dann die stärkste Erkennung eines Eingriffs, wenn beide Personen sie außerhalb des Kanals vergleichen. Ob dieser Code angezeigt wird und ob für den Vergleich angehalten wird, ist eine Einstellung — im Web „erweiterte Verifizierung“ (standardmäßig aus), in der CLI `--verify`. Ausgeschaltet ändert sie, was angezeigt wird und welche Schritte für eine Bestätigung pausieren; an der Verschlüsselung ändert sie nichts. Der Commit-dann-Offenlegen-Handshake unten läuft auf jeder Verbindung und weist eine Verbindung mit nicht passender Offenlegung ab, Schlüssel entstehen weiterhin auf deinem Gerät und gehen nie an uns, das Relay trägt weiterhin nur Chiffretext, und im Browser wird beim Empfang von Dateien weiterhin vor dem Speichern gefragt — die native macOS-App schreibt stattdessen ohne Rückfrage in ihren eingestellten Zielordner (standardmäßig „Downloads“). Diese Rückfrage verhindert ungefragtes Schreiben auf die Festplatte; wer am anderen Ende sitzt, klärt allein der Codevergleich.

Ein bloßer 6-stelliger Code (etwa 20 Bit) ließe sich im Prinzip durch Brute Force erzwingen. Relayium schließt diese Lücke mit einem Commit-dann-Offenlegen-Handshake. CLI-Übertragungen verwenden einen separaten SAS, der durch einen Commit-dann-Offenlegen-Austausch der gepinnten TLS-Zertifikat-Fingerabdrücke abgeleitet wird; auch er erkennt nur dann etwas, wenn ihn jemand tatsächlich außerhalb des Kanals vergleicht — dafür hält `--verify` an.

Klartext, den der Server weder sehen noch entschlüsseln kann

Der Dienst ist so gestaltet, dass unsere Server den folgenden Klartext weder sehen noch entschlüsseln können:

Im Browser-Echtzeitmodus fließen Datei- und Nachrichtendaten im selben Netzwerk direkt zwischen den Geräten. Netzwerkübergreifend passieren sie TURN als Chiffretext; das Relay besitzt keinen Inhaltsschlüssel. Der Signalisierungsdienst verarbeitet dennoch Verbindungsdaten und kann Metadaten wie öffentliche IP-Adressen, Raumzugehörigkeit, Zeitpunkt, gewählten Gerätenamen und Anwesenheit sehen.

Wenn Browser-Dateien und -Texte weitergeleitet werden (TURN)

Netzwerkübergreifende Datei- und Textübertragungen im Browser — Pairing-Code-Sitzungen einschließlich ihrer Beitrittslinks — laufen konstruktionsbedingt über TURN, nicht als Rückfall. Wegen restriktiver NATs und Firewalls erzwingt die App den Relay-Weg von Anfang an. Browser-Sitzungen im selben Netzwerk erhalten keine Relay-Anmeldedaten und verbinden sich direkt. Datei- und Textübertragungen der CLI verwenden nie TURN; sie sind ausschließlich direkt und schlagen fehl, wenn kein direkter Weg gefunden wird.

Temporäre Textübertragung

Text-Sitzungen im Browser verwenden das Web-Protokoll: Die Peers führen einen kurzlebigen X25519-Austausch durch und leiten richtungsgetrennte AES-256-GCM-Unterschlüssel in einer von Dateiübertragungsschlüsseln getrennten Domäne ab. Jede gültige UTF-8-Nachricht wird als eigener Frame authentifiziert und verschlüsselt. Netzwerkübergreifend verwenden Browser-Sitzungen konstruktionsbedingt TURN; das Relay trägt Chiffretext und besitzt keinen Nachrichtenschlüssel. Mit eingeschalteter erweiterter Verifizierung erkennt ein Vergleich des SAS außerhalb des Kanals zusätzlich einen Eingriff in die Signalisierung.

CLI-Text nutzt ein anderes, ausschließlich direktes Protokoll über TLS 1.3 mit Zertifikat-Pinning. Es verwendet weder das X25519/AES-Nachrichtenformat des Browsers noch TURN und schlägt fehl, wenn kein direkter Weg aufgebaut werden kann. Relayium speichert keine Nachrichteninhalte, aber beide Endpunkte können empfangenen Text kopieren, protokollieren, als Bildschirmfoto aufnehmen oder anderweitig behalten.

Zwischengespeicherte Download-Links — der Schlüssel verlässt Ihren Browser nie

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.

Dateiintegrität (SHA-256)

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

Wovor Relayium nicht schützt

Ende-zu-Ende-Verschlüsselung schützt Daten während der Übertragung zwischen zwei ehrlichen Endpunkten. Konstruktionsbedingt kann sie nicht schützen vor:

Browserunterstützung und ihre Grenzen

Relayium läuft in jedem modernen Browser mit WebRTC über HTTPS. Einige Fähigkeiten unterscheiden sich je nach Browser:

Open Source und Melden von Problemen

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.