TerminalPhone – Ende-zu-Ende-verschlüsseltes Walkie-Talkie für die Kommandozeile

 (gitlab.com)
7 Punkte von GN⁺ 2026-02-28 | 1 Kommentare | Auf WhatsApp teilen
  • Bash-basiertes Kommunikationstool im Walkie-Talkie-Stil, das Sprache und Text anonym und Ende-zu-Ende-verschlüsselt (E2EE) über das Tor-Netzwerk überträgt
  • Direkte Verbindung zum Gegenüber allein über eine .onion-Adresse, ohne Server, Konto oder Telefonnummer, mit einer Push-to-Talk-(PTT)-Struktur, bei der Sprachmitteilungen aufgenommen und anschließend gesendet werden
  • Bietet starke Sicherheitsfunktionen wie die Auswahl aus 21 Chiffren, darunter AES, ChaCha20, Camellia, ARIA, HMAC-SHA256-Authentifizierung und PBKDF2-Schlüsselableitung
  • Unterstützt sowohl Linux als auch Android Termux und läuft nur mit Standardwerkzeugen wie sox, opus-tools, Tor, openssl
  • Besteht aus einem einzelnen Skript, wodurch Installation und Wartung einfach bleiben, und eignet sich für Sicherheitsforschung und datenschutzorientierte Kommunikationsexperimente

Überblick

  • TerminalPhone ist ein Bash-Skript, das mithilfe von Tor Hidden Services zwei Nutzern den anonymen Austausch von Sprache und Text ermöglicht
    • Die gesamte Kommunikation wird durch auswählbare Chiffren wie AES-256-CBC (Standard) geschützt
    • Die .onion-Adresse dient als Benutzerkennung
    • Keine Server-Infrastruktur und keine Kontoregistrierung erforderlich

Hauptfunktionen

  • Sprachnachrichten im Walkie-Talkie-Stil: Aufnahme und anschließendes Senden, kein Echtzeit-Streaming
  • Verschlüsselter Chat während des Gesprächs: Senden und Empfangen von Textnachrichten mit der Taste T
  • Automatische Erkennung des Gesprächsendes und Anzeige des Gegenüber-Status (nimmt auf/wartet)
  • Auswahl aus 21 Chiffren und Anzeige der Aushandlung in Echtzeit, Chiffrenwechsel auch während eines laufenden Gesprächs möglich
  • Unterstützung für Snowflake-Bridges zur Umgehung von Zensur
  • Verschiedene Zusatzfunktionen wie Teilen der Adresse per QR-Code, Stimmverzerrung (voice changer), PTT-Benachrichtigungstöne und automatisches Empfangen (auto-listen)
  • HMAC-SHA256-Protokollauthentifizierung zum Schutz vor Replay-Angriffen
  • Anzeige des Tor-Circuit-Pfads und Einstellungen zum Ausschluss bestimmter Länder
  • Eine einzelne Bash-Datei, keine Root-Rechte erforderlich, funktioniert auch bei geringer Bandbreite (16 kbps)

Installation

  • Linux: Nach git clone bash terminalphone.sh ausführen und mit Menüpunkt 7 die Abhängigkeiten automatisch installieren
    • Installationspakete: tor, opus-tools, sox, socat, openssl, alsa-utils
  • Android Termux:
    • Apps Termux und Termux:API aus F-Droid installieren
    • Nach pkg install termux-api bash terminalphone.sh ausführen
    • Zusätzliche Pakete: ffmpeg, openssl-tool, tor, sox, socat usw.

Verwendung

  • Grundablauf
    1. bash terminalphone.sh ausführen
    2. Mit Menüpunkt 7 die Abhängigkeiten installieren
    3. Mit Menüpunkt 8 Tor starten
    4. In Menüpunkt 4 den gemeinsamen geheimen Schlüssel festlegen
    5. Die .onion-Adresse an das Gegenüber weitergeben
  • Empfangen: Menüpunkt 1 „Listen for calls“
  • Anrufen: Menüpunkt 2 „Call an onion address“
  • CLI-Modus Beispielbefehle:
    • bash terminalphone.sh call ADDRESS
    • bash terminalphone.sh listen

Funktionsweise

  • Record-then-send-Modell
    • Aufgenommene Sprache wird mit Opus codiert → mit AES verschlüsselt → in Base64 codiert → über Tor übertragen
    • Die empfangende Seite entschlüsselt und spielt in umgekehrter Reihenfolge ab
  • Protokollnachrichten sind textbasiert und enthalten u. a. ID, CIPHER, PTT_START, AUDIO, MSG, HANGUP, PING
  • Unter Termux wird M4A mit ffmpeg in PCM umgewandelt und anschließend verarbeitet

Sicherheitsarchitektur

  • Verschlüsselung: Verwendet mit PBKDF2 (10.000 Iterationen) abgeleitete Schlüssel und bietet zusätzlich zum Tor-Transport auf Anwendungsebene weiteren Schutz
  • Chiffrenaushandlung: Gegenseitiger Austausch beim Verbindungsaufbau und bei Änderungen; bei Abweichungen erscheint eine rote Markierung im Header
  • Übertragungsweg: Kommunikation über Tor-Hidden-Service-Circuits ohne Offenlegung der IP-Adresse
  • Widerstand gegen Traffic-Analyse: Unregelmäßige Übertragungsmuster verhindern Fingerprinting
  • Authentifizierung: Stimmen die gemeinsam genutzten geheimen Schlüssel nicht überein, schlägt die Entschlüsselung fehl
  • HMAC-SHA256-Signaturen: Alle Nachrichten enthalten einen zufälligen Nonce, um Replay-Angriffe zu blockieren
  • Einschränkungen:
    • Der geheime Schlüssel muss über einen externen sicheren Kanal ausgetauscht werden
    • Keine Forward Secrecy; bei Schlüsselverlust kann frühere Kommunikation entschlüsselt werden
    • Kein Schutz bei kompromittierter Endpunktsicherheit

Lizenz

  • MIT License

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-02-28
Hacker-News-Kommentare

  • Die Struktur, eine v3-onion-Adresse gleichzeitig als kryptografische ID und NAT-Traversal-Schicht zu verwenden, ist wirklich elegant
    Man braucht weder STUN/TURN-Server noch Hole Punching; wenn man das Skript ausführt, übernimmt Tor das Routing
    Ich frage mich, wie hoch die tatsächliche Latenz ist, wenn etwa 20 KB große Opus-Audio-Chunks über Tor übertragen werden — eher 2–3 Sekunden oder noch schlimmer

    • Die tatsächliche Latenz liegt bei etwa 2–3 Sekunden. Anfangs habe ich Vollduplex ausprobiert, aber das war furchtbar
      Das Walkie-Talkie-Modell sorgt dafür, dass Nutzer die Reihenfolge „zuhören, dann sprechen“ einhalten, wodurch die Latenz kein großes Problem mehr ist
    • STUN/TUN ist wegen der Bandbreiteneffizienz wichtig
      Bei STUN läuft der Traffic nur zwischen zwei Geräten, aber ein VPN wie Tor muss über alle Zwischenserver gehen, wodurch die Traffic-Kosten hoch sind
      Wenn ein VPS pro Monat nur einige GB erlaubt, ist das eine große Einschränkung
    • Ich bin mir nicht sicher, ob man die Latenz wirklich noch erhöhen muss, indem man auf Audionachrichten umstellt
      Ich denke, Textnachrichten wären eher mein Fall. Trotzdem ist das Projekt an sich cool
    • Es bleibt nur das Piepsen

  • Es ist interessant, ein praxisnahes Beispiel für onion-Services als Backend zu sehen
    Bald soll auch der Arti-onion-Client unterstützt werden, mit dem sich Tor als Rust-Bibliothek direkt in Apps einbetten lässt
    Je mehr solche Versuche es gibt, desto mehr Cover Traffic wird es auch im Netzwerk geben

    • Einer der Gründe, warum Tor schwer einsetzbar ist, liegt darin, dass viele IT-Administratoren Tor mit illegalen Aktivitäten gleichsetzen
      Deshalb ist die Nutzung von Tor in kontrollierten Umgebungen wie Unternehmensnetzen oder öffentlichem WLAN fast unmöglich

  • Wenn es nicht in Echtzeit sein muss, könnte man auf Empfängerseite auch Wiedergabegeschwindigkeit anpassen oder Pausen entfernen, um die Verzögerung zu verringern
    Man könnte auch Audio, das von mehreren Personen gleichzeitig gesendet wurde, schnell hintereinander abspielen
    Wenn ohnehin Opus verwendet wird, könnte man das experimentelle DRED-Fehlerwiederherstellungsschema als Codec-Funktion ausprobieren
    Selbst wenn Tor während der Übertragung abreißt, könnte man es so aufbauen, dass zuerst DRED-Daten gesendet werden, damit der Empfänger zumindest minimale Sprache erhält

  • Der Teil „Es werden 21 Verschlüsselungsalgorithmen angeboten“ ist interessant. Das wirkt nach sehr vielen

    • Das liegt an OpenSSL; im Grunde war es eher ein Fall von „weil es geht“
      Ich wollte AES-GCM verwenden, aber nur mit OpenSSL allein war die Authentifizierung schwierig
      Tor selbst ist bereits E2EE, daher ist diese Schicht praktisch zusätzliche Verschlüsselung. Trotzdem gefällt mir der Gedanke, dass noch einmal verschlüsselt wird, bevor es das Netzwerk erreicht
    • Sich auf eine bestimmte Chiffre zu versteifen, ist riskant. Der Angreifer weiß dann sehr genau, worauf er zielen muss, und das kann eher zur Schwachstelle werden

  • Es fühlt sich so an, als wäre GitLab in letzter Zeit schneller geworden; ich frage mich, ob es wirklich optimiert wurde oder ob das nur ein Lazy-Loading-Effekt ist

  • Mir gefällt dieses Projekt wirklich sehr. Wie sollten Nutzer Anmeldedaten sicher austauschen? Wäre PGP-E-Mail okay?

    • Ich gehe davon aus, dass man bereits mit jemandem spricht, dem man vertraut
      Wenn möglich, tauscht man sie idealerweise persönlich oder über einen sicheren Messenger aus
    • Oder man nutzt einen „oh by code“-Dienst wie 0x.co, um die onion-Adresse zu notieren,
      oder hinterlässt sie an einem physischen Ort (Tafel, Schwarzes Brett, Schild usw.)
      So kann man selbst in komplett offline Zuständen noch mit künftigen Gegenübern Verbindung aufnehmen

  • Die Funktion, bestimmte Länder in Tor-Circuits auszuschließen (Exclude Countries), ist interessant
    Es gibt auch Presets wie Five Eyes, Nine Eyes und Fourteen Eyes, und in der torrc-Konfiguration werden ExcludeNodes und StrictNodes verwendet
    Ich frage mich, ob das tatsächlich die Sicherheit verbessert

    • Das ist auch so ein Fall von „weil es geht“. Wenn die Tor-Entwickler es als Option eingebaut haben, wird es wohl irgendeinen Grund geben
      Dass es kompromittierte Nodes gibt, ist eine Tatsache; ob es hilft oder nicht, interessant ist, dass man überhaupt Kontrolle darüber hat
    • Selbst wenn man vollständig kontrollierte Nodes nicht komplett vermeiden kann, hilft es dabei, ISPs unter Kontrolle dieser Regierung zu umgehen

  • Wenn man die Latenzeigenschaften von Tor bedenkt, ist das Walkie-Talkie-Modell eine sehr kluge Entscheidung
    Echtzeit-Zweiwege-Audio wirkt ab einer Round-Trip-Zeit von über 150 ms unnatürlich, und Tor fügt pro Hop weitere 50–200 ms hinzu
    Wenn man es als Store-and-Forward-Modell entwirft, muss man nicht gegen die Eigenschaften des Netzwerks ankämpfen
    Ich frage mich, welcher Codec verwendet wird — wenn es nicht echtzeitkritisch ist, können die Trade-offs bei Opus anders aussehen

    • Es wird Opus verwendet, und die Qualität lässt sich zwischen 6 kbps und 64 kbps einstellen
      Ich war überrascht, wie hoch die Sprachverständlichkeit selbst bei 6 kbps noch ist
      In Termux gibt es keinen Mikrofonzugriff, daher muss Audio über die Termux-API-App und ffmpeg umgewandelt werden
    • Jemand scherzte, dieser Kommentar wirke, als sei er automatisch von einer KI erzeugt worden
    • Ich mag diesen Ansatz auch, weil er einem wie bei E-Mail oder SMS Zeit zum Formulieren gibt
      Schon ein paar Sekunden Verzögerung können unnötiges Füllgerede reduzieren

  • Ich frage mich, ob man das vielleicht als Gruppenkommunikation konfigurieren kann, sodass mehrere Personen am selben Kanal teilnehmen

    • Derzeit wird nur 1:1-Kommunikation unterstützt, aber Gruppenanrufe werden ebenfalls untersucht
    • Aufgrund der E2EE-Struktur ist Gruppenkommunikation nicht ganz so einfach

  • Es sah interessant aus, also habe ich den Code kurz überflogen,
    dabei tauchten '|| true' 76-mal, 'echo ""' 50-mal, ' [ ' 261-mal und '=$(' 90-mal auf

    • Ich mag bash auch und bin deshalb neugierig. Warum '[' nicht empfohlen wird, verstehe ich,
      aber ich würde gern wissen, warum Muster wie '|| true' problematisch sind. Ich nutze so etwas oft zusammen mit set -euo pipefail für benutzerdefinierte Fehlerbehandlung