TerminalPhone – walkie-talkie com criptografia de ponta a ponta via linha de comando

 (gitlab.com)
7 pontos por GN⁺ 2026-02-28 | 1 comentários | Compartilhar no WhatsApp
  • Ferramenta de comunicação em estilo walkie-talkie baseada em Bash que envia e recebe voz e texto de forma anônima e com criptografia de ponta a ponta (E2EE) pela rede Tor
  • Conecta-se diretamente à outra parte apenas com um endereço .onion, sem servidor, conta ou número de telefone, em uma estrutura push-to-talk (PTT) que grava a mensagem de voz antes de enviá-la
  • Oferece recursos robustos de segurança, como escolha entre 21 cifras, incluindo AES, ChaCha20, Camellia e ARIA, autenticação HMAC-SHA256 e derivação de chave PBKDF2
  • Compatível com Linux e Android Termux, funcionando apenas com ferramentas padrão como sox, opus-tools, Tor e openssl
  • Composto por um único script, tem instalação e manutenção simples e pode ser usado em pesquisas de segurança e experimentos de comunicação focados em privacidade

Visão geral

  • TerminalPhone é um script Bash que permite que dois usuários troquem voz e texto anonimamente usando Tor Hidden Services
    • Toda a comunicação é protegida por cifras selecionáveis, como AES-256-CBC (padrão)
    • O endereço .onion funciona como identificador do usuário
    • Não exige infraestrutura de servidor nem registro de conta

Principais recursos

  • Mensagens de voz no estilo walkie-talkie: grava e depois envia, sem streaming em tempo real
  • Chat criptografado durante a chamada: envio e recebimento de mensagens de texto com a tecla T
  • Detecção automática de encerramento e exibição do estado da outra parte (gravando/em espera)
  • Escolha entre 21 cifras e exibição da negociação em tempo real, com possibilidade de trocar a cifra durante a chamada
  • Suporte a bridge Snowflake para contornar censura
  • Vários recursos adicionais, como compartilhamento de endereço por QR code, modificador de voz (voice changer), som de notificação PTT e recebimento automático (auto-listen)
  • Autenticação de protocolo HMAC-SHA256 para evitar ataques de replay
  • Suporte à exibição da rota do circuito Tor e configuração para excluir países específicos
  • Arquivo Bash único, sem necessidade de privilégios de root, funcionando até em ambientes de baixa largura de banda (16 kbps)

Instalação

  • Linux: executar git clone e depois bash terminalphone.sh, com instalação automática de dependências pela opção 7 do menu
    • Pacotes instalados: tor, opus-tools, sox, socat, openssl, alsa-utils
  • Android Termux:
    • Instale os apps Termux e Termux:API pelo F-Droid
    • Após pkg install termux-api, execute bash terminalphone.sh
    • Pacotes adicionais: ffmpeg, openssl-tool, tor, sox, socat etc.

Como usar

  • Procedimento básico
    1. Execute bash terminalphone.sh
    2. Instale as dependências pela opção 7 do menu
    3. Inicie o Tor pela opção 8 do menu
    4. Defina a chave secreta compartilhada na opção 4 do menu
    5. Envie o endereço .onion para a outra parte
  • Receber: opção 1 do menu, “Listen for calls”
  • Ligar: opção 2 do menu, “Call an onion address”
  • Exemplos de comandos no modo CLI:
    • bash terminalphone.sh call ADDRESS
    • bash terminalphone.sh listen

Como funciona

  • Modelo gravar e depois enviar (record-then-send)
    • A voz gravada passa por codificação Opus → criptografia AES → codificação Base64 → envio via Tor
    • No recebimento, o processo é invertido para descriptografia e reprodução
  • As mensagens de protocolo são baseadas em texto e incluem ID, CIPHER, PTT_START, AUDIO, MSG, HANGUP, PING etc.
  • No Termux, o ffmpeg converte M4A em PCM antes do processamento

Estrutura de segurança

  • Criptografia: usa chaves derivadas com PBKDF2 (10.000 iterações), adicionando proteção na camada de aplicação além da criptografia de transporte do Tor
  • Negociação de cifra: ocorre na conexão e nas trocas posteriores; em caso de divergência, o cabeçalho é exibido em vermelho
  • Caminho de transmissão: comunicação via circuito de Hidden Service do Tor, sem expor o IP
  • Resistência à análise de tráfego: padrões de transmissão irregulares evitam fingerprinting
  • Autenticação: se a chave secreta compartilhada não corresponder, a descriptografia falha
  • Assinatura HMAC-SHA256: todas as mensagens incluem um nonce aleatório, bloqueando ataques de replay
  • Limitações:
    • A chave secreta precisa ser trocada por um canal externo seguro
    • Não há sigilo de encaminhamento (forward secrecy); se a chave vazar, comunicações passadas podem ser descriptografadas
    • Não oferece proteção se a segurança do endpoint for comprometida

Licença

  • MIT License

Leituras relacionadas

1 comentários

 
GN⁺ 2026-02-28
Comentários do Hacker News

  • A arquitetura de usar um endereço onion v3 ao mesmo tempo como ID criptográfico e camada de travessia de NAT é realmente elegante
    Sem precisar de servidor STUN/TURN nem hole punching, basta executar o script e o Tor cuida do roteamento
    Fico curioso sobre qual é a latência real ao transmitir chunks de áudio Opus de cerca de 20 KB pelo Tor — algo como 2–3 segundos, ou pior que isso

    • A latência real é de cerca de 2–3 segundos. No começo tentei fazer em full duplex, mas foi terrível
      O formato de walkie-talkie faz o usuário respeitar a ordem de “ouvir e depois falar”, então a latência não vira um grande problema
    • STUN/TUN é importante por causa da eficiência de largura de banda
      Com STUN, o tráfego circula só entre os dois dispositivos, mas uma VPN como o Tor passa por todos os servidores intermediários, então o custo de tráfego é alto
      Se você tem um limite mensal de alguns GB em um VPS, isso vira uma restrição séria
    • Não sei se faz sentido converter isso em mensagens de áudio e aumentar a latência
      Talvez mensagens de texto fossem melhores. Ainda assim, o projeto em si é muito legal
    • Só deixei o som de bip-bip

  • Foi interessante ver um caso real de uso de serviços onion como backend
    Em breve também deve haver suporte ao cliente onion Arti, que permite embutir o Tor diretamente no app em forma de biblioteca Rust
    Quanto mais tentativas desse tipo surgirem, mais cover traffic a rede também terá

    • Um dos motivos de ser difícil usar Tor é que muitos administradores de TI associam o Tor a atividade ilegal
      Por isso, em ambientes controlados como redes corporativas ou Wi‑Fi público, usar Tor quase sempre é impossível

  • Se não for em tempo real, o lado receptor poderia aplicar ajuste de velocidade de reprodução ou remoção de pausas para reduzir a latência
    Também seria possível reproduzir rapidamente o áudio enviado por várias pessoas ao mesmo tempo
    Se já está usando Opus, talvez valha testar o recurso experimental esquema de recuperação de erros DRED como parte do codec
    Dá para estruturar de modo que, se o Tor cair durante a transmissão, o receptor ainda consiga receber o mínimo de voz enviando primeiro os dados DRED

  • A parte de “são oferecidos 21 algoritmos de criptografia” chama atenção. Parece demais

    • Isso acontece por usar OpenSSL e, na verdade, foi mais um caso de “fiz porque dava para fazer”
      Eu queria usar AES-GCM, mas com OpenSSL sozinho era difícil lidar com autenticação
      O próprio Tor já é E2EE, então esta camada é basicamente criptografia redundante. Ainda assim, gosto da ideia de estar criptografado mais uma vez antes mesmo de tocar a rede
    • Ficar obcecado por uma cifra específica é perigoso. Isso deixa claro para o atacante qual é o alvo e pode acabar virando uma vulnerabilidade

  • O GitLab parece ter ficado mais rápido recentemente; fico me perguntando se realmente otimizaram algo ou se é só ilusão causada por lazy loading

  • Gostei muito deste projeto. Como os usuários deveriam trocar credenciais com segurança? E‑mail com PGP seria ok?

    • Estou assumindo um cenário em que já estou conversando com alguém em quem confio
      Se possível, o ideal é trocar isso pessoalmente ou por meio de um mensageiro seguro
    • Ou então usar um serviço “oh by code” como 0x.co para anotar o endereço onion,
      ou deixá-lo em um espaço físico (quadro, mural, placa etc.)
      Assim, dá para se conectar com alguém no futuro mesmo estando totalmente offline

  • Achei interessante a função de excluir países (Exclude Countries) no circuito do Tor
    Há presets como Five Eyes, Nine Eyes e Fourteen Eyes, e isso usa ExcludeNodes e StrictNodes na configuração do torrc
    Fico curioso se isso realmente ajuda a melhorar a segurança

    • É mais um caso de “fiz porque dava para fazer”. Se os desenvolvedores do Tor colocaram isso como opção, imagino que exista algum motivo
      É fato que existem nós comprometidos, então, funcione ou não, é interessante ter esse controle
    • Mesmo que isso não evite nós totalmente controlados, ajuda a contornar ISPs sob controle daquele governo

  • Considerando as características de latência do Tor, o modelo de walkie-talkie é uma escolha de design muito inteligente
    Áudio bidirecional em tempo real fica estranho acima de 150 ms de ida e volta, mas o Tor acrescenta de 50 a 200 ms por hop
    Se for projetado em modo store-and-forward, não precisa brigar contra as características da rede
    Fico curioso sobre qual codec está sendo usado — se não é em tempo real, os trade-offs do Opus podem ser diferentes

    • Está usando Opus, e a qualidade pode ser ajustada entre 6 kbps e 64 kbps
      Fiquei surpreso com o quão alta ainda era a inteligibilidade da fala mesmo em 6 kbps
      No Termux não há acesso ao microfone, então é preciso converter o áudio com o app Termux API e ffmpeg
    • Alguém brincou dizendo que este comentário parece ter sido gerado automaticamente por IA
    • Eu também gosto desse formato que te dá tempo para pensar, como e‑mail ou SMS
      Só alguns segundos de atraso já bastam para reduzir conversas supérfluas

  • Fico curioso se seria possível configurar isso como comunicação em grupo, com várias pessoas participando do mesmo canal

    • Por enquanto só há suporte para comunicação 1:1, mas a função de chamada em grupo também está sendo explorada
    • Por causa da estrutura E2EE, comunicação em grupo não é algo tão simples

  • Pareceu divertido, então dei uma olhada rápida no código,
    '|| true' aparece 76 vezes, 'echo ""' 50 vezes, ' [ ' 261 vezes, '=$(' 90 vezes

    • Eu também gosto de bash, então fiquei curioso. Entendo por que '[' não é recomendado,
      mas queria saber por que padrões como '|| true' seriam um problema. Eu uso bastante isso com set -euo pipefail para tratamento de erro customizado