터미널폰 – 명령줄에서 사용하는 종단간 암호화 워키토키

 (gitlab.com)
7P by GN⁺ | ★ favorite | 댓글 1개
  • Tor 네트워크를 통해 음성과 텍스트를 익명·종단간 암호화(E2EE) 방식으로 주고받는 Bash 기반 워키토키형 통신 도구
  • 서버, 계정, 전화번호 없이 .onion 주소만으로 상대와 직접 연결하며, 음성 메시지를 녹음 후 전송하는 푸시투토크(PTT) 구조
  • AES, ChaCha20, Camellia, ARIA 등 21종 암호 선택, HMAC-SHA256 인증, PBKDF2 키 파생 등 강력한 보안 기능 제공
  • Linux와 Android Termux 환경 모두 지원하며, sox·opus-tools·Tor·openssl 등 표준 도구만으로 동작
  • 단일 스크립트로 구성되어 설치와 유지보수가 단순하며, 보안 연구·프라이버시 중심 통신 실험에 활용 가능

개요

  • TerminalPhone은 Tor 히든 서비스를 이용해 두 사용자가 익명으로 음성과 텍스트를 교환할 수 있게 하는 Bash 스크립트
    • 모든 통신은 AES-256-CBC(기본값) 등 선택 가능한 암호로 보호
    • .onion 주소가 사용자 식별자 역할을 수행
    • 서버 인프라나 계정 등록이 필요 없음

주요 기능

  • 워키토키 방식 음성 메시지: 녹음 후 전송하며 실시간 스트리밍 없음
  • 통화 중 암호화 채팅: T 키로 텍스트 메시지 송수신
  • 자동 종료 감지 및 상대방 상태 표시(녹음 중/대기 중)
  • 21종 암호 선택 및 실시간 협상 표시, 중간 통화 중 암호 변경 가능
  • Snowflake 브리지 지원으로 검열 회피 가능
  • QR 코드 주소 공유, 음성 변조(voice changer), PTT 알림음, 자동 수신(auto-listen) 등 다양한 부가 기능
  • HMAC-SHA256 프로토콜 인증으로 재전송 공격 방지
  • Tor 회로 경로 표시 및 특정 국가 제외 설정 지원
  • 단일 Bash 파일, 루트 권한 불필요, 저대역폭(16kbps) 환경에서도 작동

설치

  • Linux: git clone 후 bash terminalphone.sh 실행, 메뉴 7번으로 의존성 자동 설치
    • 설치 패키지: tor, opus-tools, sox, socat, openssl, alsa-utils
  • Android Termux:
    • F-Droid에서 Termux와 Termux:API 앱 설치
    • pkg install termux-api 후 bash terminalphone.sh 실행
    • 추가 패키지: ffmpeg, openssl-tool, tor, sox, socat 등

사용법

  • 기본 절차
    1. bash terminalphone.sh 실행
    2. 메뉴 7번으로 의존성 설치
    3. 메뉴 8번으로 Tor 시작
    4. 메뉴 4번에서 공유 비밀키 설정
    5. .onion 주소를 상대에게 전달
  • 수신: 메뉴 1번 “Listen for calls”
  • 발신: 메뉴 2번 “Call an onion address”
  • CLI 모드 명령 예시:
    • bash terminalphone.sh call ADDRESS
    • bash terminalphone.sh listen

작동 방식

  • 녹음 후 전송(record-then-send) 모델
    • 녹음된 음성은 Opus 인코딩 → AES 암호화 → Base64 인코딩 → Tor 전송
    • 수신 측은 역순으로 복호화 및 재생
  • 프로토콜 메시지는 텍스트 기반으로 ID, CIPHER, PTT_START, AUDIO, MSG, HANGUP, PING 등을 포함
  • Termux에서는 ffmpeg로 M4A를 PCM으로 변환 후 처리

보안 구조

  • 암호화: PBKDF2(10,000회 반복)로 파생된 키를 사용, Tor 전송 암호화와 별개로 애플리케이션 계층에서 추가 보호
  • 암호 협상: 연결 시 및 변경 시 상호 교환, 불일치 시 헤더에 빨간 표시
  • 전송 경로: Tor 히든 서비스 회로를 통해 IP 노출 없이 통신
  • 트래픽 분석 저항성: 불규칙한 전송 패턴으로 지문화 방지
  • 인증: 공유 비밀키가 일치하지 않으면 복호화 실패
  • HMAC-SHA256 서명: 모든 메시지에 난수 nonce 포함, 재전송 공격 차단
  • 제한 사항:
    • 비밀키는 외부 안전 채널로 교환 필요
    • 전방 비밀성 없음, 키 유출 시 과거 통신 복호화 가능
    • 엔드포인트 보안 침해 시 보호 불가

라이선스

  • MIT License

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • v3 onion 주소를 암호학적 ID와 NAT 트래버설 계층으로 동시에 쓰는 구조가 정말 깔끔함
    STUN/TURN 서버도, 홀펀칭도 필요 없이 스크립트를 실행하면 Tor가 라우팅을 처리해줌
    Tor로 약 20KB짜리 Opus 오디오 청크를 전송할 때 실제 지연이 얼마나 되는지 궁금함 — 2~3초 정도인지, 아니면 더 심한지

    • 실제 지연은 2~3초 정도임. 처음엔 풀 듀플렉스로 시도했는데 너무 끔찍했음
      워키토키 방식은 사용자가 ‘듣고-말하고’ 순서를 지키게 되니 지연이 큰 문제가 되지 않음
    • STUN/TUN은 대역폭 효율 때문에 중요함
      STUN은 두 기기 간에만 트래픽이 오가지만, Tor 같은 VPN은 중간 서버들을 모두 거치므로 트래픽 비용이 큼
      VPS에서 월 수 GB 제한이 있는 경우엔 큰 제약이 됨
    • 굳이 오디오 메시지로 바꿔서 지연을 늘릴 필요가 있나 싶음
      차라리 텍스트 메시지가 낫겠다는 생각임. 그래도 프로젝트 자체는 멋짐
    • 삐빕 소리만 남김

  • onion 서비스를 백엔드로 활용한 실제 사례를 보니 흥미로움
    곧 Rust 라이브러리 형태로 Tor를 앱에 직접 임베드할 수 있는 Arti onion 클라이언트도 지원될 예정임
    이런 시도가 많아질수록 네트워크의 커버 트래픽도 늘어날 것임

    • Tor를 쓰기 어려운 이유 중 하나는 많은 IT 관리자들이 Tor를 불법 활동과 동일시한다는 인식 때문임
      그래서 기업망이나 공공 Wi-Fi 같은 통제된 환경에서는 Tor 사용이 거의 불가능함

  • 실시간이 아니라면 수신 측에서 재생 속도 조절이나 공백 제거 처리를 넣어 지연을 줄일 수도 있음
    여러 사람이 동시에 보낸 오디오를 빠르게 재생하는 것도 가능함
    Opus를 쓰고 있다면, 실험적 기능인 DRED 오류 복원 스킴을 코덱으로 활용해볼 만함
    전송 중 Tor가 끊겨도 수신자가 최소한의 음성을 받을 수 있게 DRED 데이터를 먼저 보내는 식으로 구성할 수 있음

  • “21개의 암호화 알고리즘이 제공됨”이라는 부분이 흥미로움. 너무 많은 것 같음

    • OpenSSL을 사용해서 그렇고, 사실 “할 수 있으니까 한 것”임
      AES-GCM을 쓰고 싶었지만 OpenSSL 단독으로는 인증 처리가 어려움
      Tor 자체가 이미 E2EE라 이 계층은 사실상 중복 암호화임. 그래도 네트워크에 닿기 전 한 번 더 암호화된다는 점이 마음에 듦
    • 특정 암호에 집착하는 건 위험함. 공격자가 목표를 명확히 알게 되니까 오히려 취약점이 될 수 있음

  • GitLab이 최근 더 빨라진 것처럼 느껴짐, 실제로 최적화된 건지 아니면 lazy loading 착시인지 궁금함

  • 이 프로젝트 정말 마음에 듦. 사용자들이 자격 증명을 안전하게 교환하려면 어떻게 해야 할까? PGP 이메일이 괜찮을까?

    • 나는 이미 신뢰하는 사람과 대화 중인 상황을 가정함
      가능하면 직접 만나서 교환하거나, 보안 메신저를 통한 교환이 이상적임
    • 혹은 0x.co 같은 “oh by code” 서비스를 이용해 onion 주소를 적어두거나,
      물리적인 공간(칠판, 게시판, 표지판 등)에 남겨두는 방법도 있음
      이렇게 하면 완전히 오프라인 상태에서도 미래의 상대와 연결 가능함

  • Tor 회로에서 특정 국가를 제외(Exclude Countries) 하는 기능이 흥미로움
    Five Eyes, Nine Eyes, Fourteen Eyes 같은 프리셋도 있고, torrc 설정에서 ExcludeNodes와 StrictNodes를 사용함
    실제로 보안 향상에 도움이 되는지 궁금함

    • “할 수 있으니까 한 것” 중 하나임. Tor 개발자들이 옵션으로 넣은 걸 보면 뭔가 이유는 있을 듯함
      손상된 노드가 존재하는 건 사실이니, 효과가 있든 없든 제어권이 있다는 점이 흥미로움
    • 완전히 통제된 노드를 피하진 못하더라도, 해당 정부가 통제하는 ISP를 우회하는 데는 도움이 됨

  • Tor의 지연 특성을 고려하면 워키토키 모델은 매우 현명한 설계임
    실시간 양방향 오디오는 왕복 150ms 이상이면 어색해지는데, Tor는 홉당 50~200ms를 추가함
    스토어-포워드 방식으로 설계하면 네트워크 특성과 싸우지 않아도 됨
    어떤 코덱을 쓰는지 궁금함 — 실시간이 아니라면 Opus의 트레이드오프가 달라질 수 있음

    • Opus를 사용 중이며, 6kbps~64kbps 사이에서 품질을 조정 가능함
      6kbps에서도 음성 인식률이 꽤 높아 놀랐음
      Termux에서는 마이크 접근이 안 되기 때문에 Termux API 앱과 ffmpeg를 통해 오디오를 변환해야 함
    • 누군가 이 댓글을 AI가 자동 생성한 것 같다고 농담함
    • 나도 이메일이나 문자처럼 생각하고 말할 시간을 주는 이 방식이 좋음
      몇 초의 지연만으로도 불필요한 군더더기 대화를 줄일 수 있음

  • 혹시 이걸 그룹 통신처럼 여러 명이 같은 채널에 참여하도록 설정할 수 있는지 궁금함

    • 현재는 1:1 통신만 지원하지만, 그룹 통화 기능도 탐색 중임
    • E2EE 구조상 그룹 통신은 그렇게 간단하지 않음

  • 재미있어 보여서 코드를 훑어봤는데,
    '|| true' 76회, 'echo ""' 50회, ' [ ' 261회, '=$(' 90회 등장함

    • 나도 bash를 좋아해서 궁금함. '['이 비추천되는 이유는 알겠는데,
      '|| true' 같은 패턴은 왜 문제인지 알고 싶음. 나는 set -euo pipefail과 함께 커스텀 에러 처리용으로 자주 씀
답변달기