TerminalPhone – un talkie-walkie chiffré de bout en bout à utiliser en ligne de commande

 (gitlab.com)
7 points par GN⁺ 2026-02-28 | 1 commentaires | Partager sur WhatsApp
  • Outil de communication de type talkie-walkie basé sur Bash permettant d’échanger voix et texte de manière anonyme et chiffrée de bout en bout (E2EE) via le réseau Tor
  • Connexion directe avec l’autre correspondant via une simple adresse .onion, sans serveur, sans compte et sans numéro de téléphone, avec un fonctionnement push-to-talk (PTT) consistant à enregistrer puis envoyer les messages vocaux
  • Fonctions de sécurité robustes avec choix parmi 21 chiffrements, dont AES, ChaCha20, Camellia et ARIA, ainsi que l’authentification HMAC-SHA256 et la dérivation de clé PBKDF2
  • Compatible à la fois avec Linux et Android Termux, et fonctionne uniquement avec des outils standard comme sox·opus-tools·Tor·openssl
  • Composé d’un script unique, ce qui simplifie l’installation et la maintenance, et peut être utilisé pour la recherche en sécurité et les expérimentations de communication centrées sur la vie privée

Aperçu

  • TerminalPhone est un script Bash qui permet à deux utilisateurs d’échanger anonymement de la voix et du texte à l’aide des services cachés Tor
    • Toutes les communications sont protégées par un chiffrement sélectionnable, dont AES-256-CBC (par défaut)
    • L’adresse .onion sert d’identifiant utilisateur
    • Aucune infrastructure serveur ni inscription à un compte n’est nécessaire

Fonctionnalités principales

  • Messages vocaux façon talkie-walkie : enregistrement puis envoi, sans streaming en temps réel
  • Chat chiffré pendant l’appel : envoi et réception de messages texte avec la touche T
  • Détection automatique de fin d’appel et affichage de l’état du correspondant (enregistrement/en attente)
  • Sélection parmi 21 chiffrements et affichage de la négociation en temps réel, avec possibilité de changer de chiffrement en cours d’appel
  • Prise en charge du bridge Snowflake pour contourner la censure
  • Nombreuses fonctions supplémentaires comme le partage d’adresse par QR code, le voice changer, les sons de notification PTT et la réception automatique (auto-listen)
  • Authentification du protocole par HMAC-SHA256 pour éviter les attaques par rejeu
  • Affichage du chemin du circuit Tor et prise en charge de l’exclusion de certains pays
  • Un seul fichier Bash, pas besoin de privilèges root, fonctionnement même en faible bande passante (16 kbps)

Installation

  • Linux : après git clone, exécuter bash terminalphone.sh, puis installer automatiquement les dépendances via l’option 7 du menu
    • Paquets à installer : tor, opus-tools, sox, socat, openssl, alsa-utils
  • Android Termux :
    • Installer les applications Termux et Termux:API depuis F-Droid
    • Exécuter pkg install termux-api, puis bash terminalphone.sh
    • Paquets supplémentaires : ffmpeg, openssl-tool, tor, sox, socat, etc.

Utilisation

  • Procédure de base
    1. Exécuter bash terminalphone.sh
    2. Installer les dépendances via l’option 7 du menu
    3. Démarrer Tor via l’option 8 du menu
    4. Définir la clé secrète partagée dans l’option 4
    5. Transmettre l’adresse .onion à l’autre correspondant
  • Réception : option 1 du menu, “Listen for calls”
  • Émission : option 2 du menu, “Call an onion address”
  • Exemples de commandes en mode CLI :
    • bash terminalphone.sh call ADDRESS
    • bash terminalphone.sh listen

Fonctionnement

  • Modèle record-then-send
    • La voix enregistrée suit le traitement encodage Opus → chiffrement AES → encodage Base64 → transmission via Tor
    • Le côté réception effectue l’opération inverse pour déchiffrer et lire
  • Les messages du protocole sont textuels et incluent ID, CIPHER, PTT_START, AUDIO, MSG, HANGUP, PING, etc.
  • Dans Termux, ffmpeg convertit le M4A en PCM avant traitement

Architecture de sécurité

  • Chiffrement : utilisation de clés dérivées via PBKDF2 (10 000 itérations), avec une protection supplémentaire au niveau applicatif en plus du chiffrement de transport de Tor
  • Négociation du chiffrement : échange mutuel lors de la connexion et lors des changements ; en cas d’incohérence, un indicateur rouge apparaît dans l’en-tête
  • Chemin de transmission : communication via les circuits de services cachés Tor, sans exposition de l’adresse IP
  • Résistance à l’analyse de trafic : schémas de transmission irréguliers pour éviter l’empreinte de trafic
  • Authentification : si la clé secrète partagée ne correspond pas, le déchiffrement échoue
  • Signature HMAC-SHA256 : chaque message inclut un nonce aléatoire, bloquant les attaques par rejeu
  • Limites :
    • La clé secrète doit être échangée via un canal externe sûr
    • Pas de secret persistant, donc une fuite de clé permet de déchiffrer les communications passées
    • Aucune protection possible si la sécurité des terminaux est compromise

Licence

  • MIT License

À lire aussi

1 commentaires

 
GN⁺ 2026-02-28
Commentaires sur Hacker News

  • La structure qui utilise une adresse onion v3 à la fois comme ID cryptographique et comme couche de traversée du NAT est vraiment élégante
    Pas besoin de serveurs STUN/TURN ni de hole punching : il suffit de lancer le script et Tor s’occupe du routage
    Je me demande quelle est la latence réelle quand on envoie des blocs audio Opus d’environ 20 Ko via Tor — autour de 2 à 3 secondes, ou pire encore

    • La latence réelle est d’environ 2 à 3 secondes. Au début, j’ai essayé en full duplex, mais c’était horrible
      Le mode talkie-walkie impose aux utilisateurs de respecter un ordre « j’écoute, puis je parle », donc la latence ne pose pas un si gros problème
    • STUN/TUN est important pour l’efficacité en bande passante
      Avec STUN, le trafic circule seulement entre deux appareils, tandis qu’un VPN comme Tor passe par tous les serveurs intermédiaires, donc le coût en trafic est élevé
      Si un VPS est limité à quelques Go par mois, cela devient une contrainte majeure
    • Je ne suis pas sûr qu’il faille vraiment augmenter la latence en passant par des messages audio
      J’aurais plutôt tendance à préférer des messages texte. Cela dit, le projet lui-même est chouette
    • Ne laisser que les bips

  • C’est intéressant de voir un cas réel d’utilisation des services onion comme backend
    La prise en charge d’un client onion Arti, permettant d’embarquer Tor directement dans une application sous forme de bibliothèque Rust, devrait aussi arriver bientôt
    Plus ce type d’initiative se multipliera, plus le cover traffic du réseau augmentera

    • L’une des raisons pour lesquelles Tor est difficile à utiliser, c’est que beaucoup d’administrateurs IT l’associent à des activités illégales
      Du coup, il est presque impossible d’utiliser Tor dans des environnements contrôlés comme les réseaux d’entreprise ou les Wi-Fi publics

  • Si ce n’est pas du temps réel, le côté réception pourrait intégrer un ajustement de la vitesse de lecture ou la suppression des silences pour réduire la latence
    On pourrait aussi lire rapidement l’audio envoyé simultanément par plusieurs personnes
    Si vous utilisez Opus, il pourrait être intéressant d’exploiter comme codec la fonctionnalité expérimentale DRED error recovery scheme
    On pourrait l’organiser de manière à envoyer d’abord les données DRED pour que le destinataire reçoive au moins un minimum de voix même si Tor se coupe pendant la transmission

  • La mention « 21 algorithmes de chiffrement disponibles » est intrigante. Cela semble beaucoup

    • C’est à cause d’OpenSSL, et en réalité, c’est surtout du « je l’ai fait parce que je pouvais »
      Je voulais utiliser AES-GCM, mais l’authentification est difficile à gérer avec OpenSSL seul
      Tor est déjà en E2EE, donc cette couche est en pratique un chiffrement redondant. Mais j’aime l’idée que ce soit chiffré une fois de plus avant même d’atteindre le réseau
    • S’obséder sur un chiffrement particulier est risqué. Cela indique clairement une cible à l’attaquant et peut devenir au contraire une faille

  • J’ai l’impression que GitLab est devenu plus rapide récemment ; je me demande si c’est réellement optimisé ou si c’est juste un effet de lazy loading

  • J’aime vraiment beaucoup ce projet. Comment les utilisateurs devraient-ils échanger leurs identifiants de manière sûre ? Un email PGP serait-il adapté ?

    • Je pars du principe qu’on parle déjà à quelqu’un en qui on a confiance
      Si possible, l’idéal est d’échanger en personne ou via une messagerie sécurisée
    • Ou bien utiliser un service « oh by code » comme 0x.co pour y noter l’adresse onion,
      ou la laisser dans un espace physique (tableau, panneau d’affichage, signalétique, etc.)
      De cette manière, il est possible d’entrer en contact avec un interlocuteur futur même en étant totalement hors ligne

  • La fonction permettant d’exclure certains pays d’un circuit Tor est intéressante
    Il existe même des préréglages comme Five Eyes, Nine Eyes et Fourteen Eyes, et cela utilise ExcludeNodes et StrictNodes dans la configuration torrc
    Je me demande si cela améliore réellement la sécurité

    • C’est encore un cas de « je l’ai fait parce que je pouvais ». Si les développeurs de Tor l’ont mis comme option, c’est qu’il doit bien y avoir une raison
      L’existence de nœuds compromis est une réalité, donc qu’il y ait ou non un effet concret, il est intéressant d’avoir ce contrôle
    • Même si cela ne permet pas d’éviter des nœuds entièrement contrôlés, cela aide au moins à contourner les FAI contrôlés par ce gouvernement

  • Vu les caractéristiques de latence de Tor, le modèle talkie-walkie est un choix de conception très intelligent
    L’audio bidirectionnel en temps réel devient étrange au-delà de 150 ms aller-retour, alors que Tor ajoute 50 à 200 ms par saut
    Avec une conception en store-and-forward, on n’a pas besoin de lutter contre les propriétés du réseau
    Je me demande quel codec est utilisé — si ce n’est pas du temps réel, les compromis d’Opus peuvent être différents

    • Opus est utilisé, et la qualité peut être ajustée entre 6 kbps et 64 kbps
      J’ai été surpris de voir qu’à 6 kbps, l’intelligibilité vocale reste assez bonne
      Comme l’accès au micro ne fonctionne pas sous Termux, il faut convertir l’audio via l’application Termux API et ffmpeg
    • Quelqu’un a plaisanté en disant que ce commentaire avait l’air généré automatiquement par une IA
    • J’aime aussi cette approche qui laisse le temps de parler, un peu comme un email ou un SMS
      Même quelques secondes de latence peuvent réduire les échanges superflus

  • Je me demande s’il serait possible de configurer cela comme une communication de groupe, avec plusieurs personnes sur le même canal

    • Pour l’instant, seule la communication 1:1 est prise en charge, mais la fonction d’appel de groupe est aussi à l’étude
    • Avec une architecture E2EE, la communication de groupe n’est pas si simple

  • Ça avait l’air amusant, alors j’ai parcouru le code,
    et j’y ai trouvé '|| true' 76 fois, 'echo ""' 50 fois, ' [ ' 261 fois, et '=$(' 90 fois

    • J’aime moi aussi bash, donc ça m’intrigue. Je comprends pourquoi '[' est déconseillé,
      mais j’aimerais savoir pourquoi des motifs comme '|| true' posent problème. Je les utilise souvent avec set -euo pipefail pour une gestion d’erreurs personnalisée