Wie es funktioniert – und was wir nicht versprechen.
Diese Seite ist für alle, die nachprüfen wollen. Zu jeder Komponente sagen wir, wovor sie schützt und wovor nicht.
Die Architektur in einer Zeile
Ein Client auf jedem Gerät, ein Hub pro Gemeinschaft (der Outpost), nur als Tor-v3-Onion-Service erreichbar, Ende-zu-Ende-Verschlüsselung mit MLS zwischen den Clients. Der Hub ordnet, speichert vorübergehend und leitet Nachrichten weiter, die er nicht lesen kann. Kein zentraler Server, keine GiBSeS-Komponente im Datenpfad.
Tor Onion v3 mit Arti
Outpost und Clients sprechen nur über Tor miteinander. Der Outpost veröffentlicht einen v3-Onion-Service: Die Adresse leitet sich aus dem Schlüssel des Dienstes ab, bleibt also gleich, wenn der PC Netz oder IP wechselt, und am Router müssen keine Ports geöffnet werden. Wir nutzen Arti, die Tor-Implementierung des Tor Project in Rust, direkt ins Binary integriert: Es muss kein externer Tor-Prozess installiert werden.
- Die Latenz ist die von Tor. In unseren Tests lag die Umlaufzeit einer Nachricht über den Hub zwischen 168 und 627 ms (Median je Szenario). Große Anhänge brauchen länger als über eine direkte Verbindung.
- Wo das Tor-Netz blockiert ist, verbindet sich Naisho nicht. Wir liefern weder Bridges noch Werkzeuge zur Umgehung von Sperren mit.
Web-Version
Die Web-Version ist die im Browser geöffnete Oberfläche eines kleinen lokalen Programms, das Tor spricht. Es gibt keinen entfernten Webserver: Der Browser spricht nur mit dem Programm auf deinem Computer, das die Nachrichten über Tor zum Outpost bringt.
MLS (RFC 9420) mit OpenMLS
Jede Unterhaltung, auch die zu zweit, ist eine MLS-Gruppe nach RFC 9420, implementiert mit OpenMLS. Suite: X25519 für den Schlüsselaustausch, ChaCha20-Poly1305 für die Verschlüsselung, Ed25519 für die Signaturen. Auf dem Gerät verschlüsselt werden Text, Fotos, Sprachnachrichten, Dateien und auch Namen und Typen der Anhänge.
- Vorerst kein Post-Quantum Die hybriden Suiten für MLS sind noch im Entwurf. Wir versprechen sie nicht, solange sie nicht stabil sind.
- Die Nachrichten sind nicht abstreitbar Jede Nachricht ist vom Absender signiert: Wer sie empfängt, kann Dritten beweisen, dass du sie geschrieben hast. Mit derselben Signatur lässt sich eine Nachricht beim Betreiber melden, samt Nachweis, dass sie echt ist.
MLS bietet Forward Secrecy und Post-Compromise Security: Ein heute gestohlener Schlüssel entschlüsselt weder den Verkehr von gestern noch, nach einer Schlüsselaktualisierung, den von morgen. Es schützt die Nachrichten unterwegs, nicht den schon auf dem Handy gespeicherten Verlauf: Der ist durch die Verschlüsselung der lokalen Datenbank und die App-Sperre (PIN oder Biometrie) geschützt.
Wir haben das mit Sentinel-Strings geprüft, die in Testnachrichten eingefügt wurden: null Treffer in den Daten des Hubs.
Wer einer Gruppe beitritt, liest den Verlauf nicht. Wer austritt oder entfernt wird, liest nicht, was danach geschrieben wird. In einem Test mit 100 Mitgliedern erzeugt das Entfernen eines Mitglieds einen Commit von 8,7 KB in 6,5 ms.
Identität und Schlüssel
Die Schlüssel des Outpost werden beim Beitritt über die Einladung festgelegt. Jede persönliche ID (QR-Code oder 32-stelliger Code) enthält den Fingerabdruck des Schlüssels: Versucht jemand, auch der Hub, ihn auszutauschen, blockiert die App das Senden und zeigt eine ganzseitige Warnung. Zwei Personen können einen 60-stelligen Sicherheitscode oder einen QR-Code vergleichen. Jede Gemeinschaft hat eine eigene Identität, mit anderen Schlüsseln.
- Beim ersten Beitritt vertraut der Client dem Zertifikat des Betreibers. Ein böswilliger Betreiber kann dir ein falsches neues Mitglied unterschieben: Die Gegenmaßnahme ist der Vergleich der Codes, den wir für wichtige Kontakte empfehlen.
- Getrennte Identitäten zwischen Gemeinschaften erschweren die Verknüpfung, machen sie aber nicht unmöglich. Zwei Betreiber, die lange die Verbindungszeiten vergleichen, können dieselbe Person verknüpfen.
- Wer einen Einladungslink abfängt, kann ihn vor dem Empfänger benutzen. Der persönlich gezeigte QR-Code hat dieses Problem nicht.
Der Hub ist blind für Inhalte. Für Metadaten nicht.
Lies diese Tabelle ganz. Sie gilt für den Outpost und damit für die Person, die ihn verwaltet.
| Daten | Sieht der Hub sie? |
|---|---|
| Text, Fotos, Sprachnachrichten, Dateien, Namen und Typen der Anhänge | Nein |
| Audio und Video der Meetings (beide Modi) | Ja |
| IP der Clients | Nein (Tor), außer bei Teilnehmenden an Meetings im Modus Hohe Qualität |
| IP des Hubs, für die Clients | Nein (Onion), außer bei Teilnehmenden an Meetings im Modus Hohe Qualität |
| Mitgliederliste, mit Schlüsseln und Labels, auch die nicht öffentlichen | Ja |
| Sichtbarkeit, die jeder selbst wählt | Ja |
| Wer in welchem Raum ist, Namen der Räume | Ja |
| Wer wem in Chats zu zweit schreibt | Ja |
| Wer Inhalte in einen Raum hochlädt | Ja |
| Wann und wie oft sich jemand verbindet | Ja |
| Größe der Nachrichten | Ja |
| Wer aus einem Raum heraus mit wem einen privaten Chat öffnet | Ja |
GiBSeS sieht nichts davon: keine Server, keine Konten, keine Telemetrie, keine Absturzberichte, keine Online-Aktivierung. Wer „nur für Personen mit meiner ID sichtbar“ ist, bleibt für die Mitglieder der Räume sichtbar, denen er beitritt.
Store-and-Forward
Ist der Empfänger offline, bleibt der verschlüsselte Umschlag bis zu 30 Tage (einstellbar) auf dem Outpost, dann läuft er ab. Sobald er zugestellt ist, wird er gelöscht: Der Outpost dient nur der Durchleitung und führt kein Nachrichtenarchiv. Auf der Festplatte bleiben die Liste der Mitglieder und Räume und die Warteschlange der nicht abgeholten Nachrichten, in einem Ordner, der im Ruhezustand mit dem Passwort des Betreibers verschlüsselt ist (Argon2id). In Chats zu zweit siehst du „in der Warteschlange“, „zugestellt“ oder „abgelaufen“. Anhänge werden in Teilen übertragen, mit Fortsetzung nach einer Unterbrechung, bis zu 100 MB pro Element.
Kein Push
Keine Benachrichtigung läuft über die Push-Dienste von Android und iOS. Zwei Modi: keine Abfrage im Hintergrund (Standard) oder eine regelmäßige Abfrage über Tor alle 15, 30, 60 oder 240 Minuten, mit einer lokalen Benachrichtigung ohne Inhalt. Unter Android kann der Energiesparmodus die Abfragen verzögern; unter iOS schränkt das System die Hintergrundaktivität ein, voller Empfang also nur bei geöffneter App.
Sprachanrufe
Anrufe, 1:1 und in der Gruppe bis zu etwa 10 Personen, laufen über Tor und über den Hub, der sie nur im Arbeitsspeicher weiterleitet, ohne sie auf die Festplatte zu schreiben. Die Latenz ist die von zwei Onion-Strecken: Rechne mit einer spürbaren Verzögerung, eher wie bei einem Walkie-Talkie als bei einem klassischen Telefonat. Ist der Kontakt nicht erreichbar, gilt der Anruf als verpasst und du kannst eine Sprachnachricht hinterlassen. Es gibt auch eine einfache Bildschirmfreigabe.
Zwei Modi
Optionale Komponente, standardmäßig aus, die auf dem Hub als SFU (Selective Forwarding Unit) läuft. Die Medien sind beim Transport verschlüsselt, aber die SFU entschlüsselt sie zum Weiterleiten: Der Hub sieht Audio und Video der Meetings in beiden Modi. Wir nutzen kein SFrame. Beim Video vertraust du dem Hub, also der Person, die ihn verwaltet.
Geschützt
Die Medien laufen über Tor, vom Outpost als Relay weitergeleitet, in niedriger Auflösung, um in Bandbreite und Latenz eines Onion-Circuits zu passen. Keine IP sichtbar: weder die der Teilnehmenden noch die des Hubs. Keine zusätzliche Netzwerkkonfiguration.
Hohe Qualität
Direkte WebRTC-Verbindung zwischen Client und Outpost, außerhalb von Tor, mit DTLS-SRTP-Verschlüsselung und integriertem TURN. Nötig sind eine öffentliche IP am Hub und ein oder zwei offene Ports. Selbstsigniertes Zertifikat: Sein Fingerabdruck und die Adresse erreichen die Clients über Tor, ohne externen Dienst. Die IPs der Teilnehmenden sieht nur der Outpost der Gemeinschaft, nicht die anderen Teilnehmenden. Die Teilnehmenden kennen die IP des Hubs. Wie bei jeder direkten Verbindung sieht der Netzanbieter jedes Einzelnen, dass eine Verbindung zu dieser Adresse besteht.
Die Chats laufen immer über Tor, egal welchen Modus du für das Video wählst.
Anforderungen
Der Hub macht wenig schwere Kryptografie: Er leitet Umschläge weiter und ordnet die MLS-Commits. Die eigentliche Last tragen der Datenträger (Warteschlange der Anhänge, bis zu 30 Tage) und die Tor-Bandbreite. Das Arbeitslaufwerk muss eine SSD sein: Die Warteschlange schreibt ständig. Der gemessene Knoten belegt im Dauerbetrieb 34-46 MB RAM.
| Gemeinschaft | Empfohlene Konfiguration |
|---|---|
| Bis ~25 Personen | Eingeschalteter PC oder Laptop, 4 GB RAM, 32 GB frei auf SSD |
| Von ~25 bis 100 Personen | Ein Computer oder Mini-PC, 8 GB RAM, SSD mit 64-128 GB |
| Über 100 Personen | Mehrere Outposts |
| Video Hohe Qualität, 5 Teilnehmende | ~10 Mbit/s Upload am Hub, öffentliche IP, 1-2 Ports |
| Video Hohe Qualität, 10 Teilnehmende | ~45 Mbit/s Upload am Hub; Computer mit 8 GB |
| Video Geschützt | Keine zusätzlichen Netzwerkanforderungen; Qualität durch die Tor-Bandbreite begrenzt |
Outpost für Windows 10/11 x64 und Linux x86_64. Automatischer Start, online innerhalb von 3 Minuten nach dem Einschalten. Für den Chat reicht ein Heimanschluss mit ein paar Mbit/s Upload: Die praktische Grenze ist die Latenz von Tor, nicht die Hardware.
Code
Client und Outpost sind in Rust geschrieben: Arti für Tor, OpenMLS für die Verschlüsselung. Der Outpost ist ein einziges Binary, ohne Installation und ohne Administratorrechte.
Hier geht’s weiter
Für dich und deine Gruppe
Die Fotos der Kinder, die Sprachnachrichten der Oma, der Chat des Vereins bleiben unter euch. Hier steht, was die Person tun muss, die die Gruppe verwaltet, und warum Chat Control dich betrifft.
Für dein Unternehmen
Projekte unter NDA, Videomeetings, Chats unter Kollegen: Die Daten bleiben auf einem Computer in deinem Büro. Naisho ergänzt die Werkzeuge, die ihr schon nutzt.