TerminalPhone – Bộ đàm mã hóa đầu cuối dùng trên dòng lệnh

 (gitlab.com)
7 điểm bởi GN⁺ 2026-02-28 | 1 bình luận | Chia sẻ qua WhatsApp
  • Công cụ liên lạc kiểu bộ đàm dựa trên Bash cho phép trao đổi giọng nói và văn bản ẩn danh, mã hóa đầu cuối (E2EE) qua mạng Tor
  • Không cần máy chủ, tài khoản hay số điện thoại, kết nối trực tiếp với đối phương chỉ bằng địa chỉ .onion, theo cơ chế push-to-talk (PTT) ghi âm rồi gửi
  • Cung cấp các tính năng bảo mật mạnh như lựa chọn 21 loại mã hóa gồm AES, ChaCha20, Camellia, ARIA, xác thực HMAC-SHA256, dẫn xuất khóa PBKDF2
  • Hỗ trợ cả môi trường Linux và Android Termux, hoạt động chỉ với các công cụ tiêu chuẩn như sox·opus-tools·Tor·openssl
  • Được cấu thành từ một script duy nhất nên cài đặt và bảo trì đơn giản, có thể dùng cho nghiên cứu bảo mật và thử nghiệm liên lạc ưu tiên quyền riêng tư

Tổng quan

  • TerminalPhone là một script Bash sử dụng Tor Hidden Service để hai người dùng có thể trao đổi giọng nói và văn bản một cách ẩn danh
    • Mọi liên lạc đều được bảo vệ bằng các mã hóa có thể lựa chọn như AES-256-CBC (mặc định)
    • Địa chỉ .onion đóng vai trò làm định danh người dùng
    • Không cần hạ tầng máy chủ hay đăng ký tài khoản

Tính năng chính

  • Tin nhắn thoại kiểu bộ đàm: ghi âm xong rồi gửi, không có streaming thời gian thực
  • Chat mã hóa trong khi gọi: gửi và nhận tin nhắn văn bản bằng phím T
  • Tự động phát hiện ngắt kết nối và hiển thị trạng thái đối phương (đang ghi âm/đang chờ)
  • Lựa chọn 21 loại mã hóa và hiển thị thương lượng theo thời gian thực, có thể đổi mã hóa ngay trong cuộc gọi
  • Hỗ trợ cầu nối Snowflake để vượt kiểm duyệt
  • Nhiều tính năng bổ sung như chia sẻ địa chỉ bằng mã QR, biến đổi giọng nói (voice changer), âm báo PTT, tự động nhận (auto-listen)
  • Xác thực giao thức bằng HMAC-SHA256 để ngăn tấn công phát lại
  • Hỗ trợ hiển thị tuyến mạch Tor và cấu hình loại trừ một số quốc gia cụ thể
  • Một file Bash duy nhất, không cần quyền root, vẫn hoạt động trong môi trường băng thông thấp (16kbps)

Cài đặt

  • Linux: chạy git clone rồi bash terminalphone.sh, dùng mục 7 trong menu để tự động cài phụ thuộc
    • Các gói cần cài: tor, opus-tools, sox, socat, openssl, alsa-utils
  • Android Termux:
    • Cài ứng dụng Termux và Termux:API từ F-Droid
    • Sau pkg install termux-api, chạy bash terminalphone.sh
    • Gói bổ sung: ffmpeg, openssl-tool, tor, sox, socat v.v.

Cách dùng

  • Quy trình cơ bản
    1. Chạy bash terminalphone.sh
    2. Cài phụ thuộc bằng mục 7 trong menu
    3. Khởi động Tor bằng mục 8 trong menu
    4. Đặt khóa bí mật dùng chung ở mục 4 trong menu
    5. Gửi địa chỉ .onion cho đối phương
  • Nhận cuộc gọi: mục 1 “Listen for calls”
  • Gọi đi: mục 2 “Call an onion address”
  • Ví dụ lệnh chế độ CLI:
    • bash terminalphone.sh call ADDRESS
    • bash terminalphone.sh listen

Cách hoạt động

  • Mô hình ghi âm rồi gửi (record-then-send)
    • Âm thanh đã ghi được mã hóa Opus → mã hóa AES → mã hóa Base64 → truyền qua Tor
    • Bên nhận thực hiện theo thứ tự ngược lại để giải mã và phát lại
  • Thông điệp giao thức ở dạng văn bản, gồm ID, CIPHER, PTT_START, AUDIO, MSG, HANGUP, PING v.v.
  • Trên Termux, ffmpeg được dùng để chuyển M4A sang PCM trước khi xử lý

Cấu trúc bảo mật

  • Mã hóa: dùng khóa được dẫn xuất bằng PBKDF2 (10.000 vòng lặp), bổ sung lớp bảo vệ ở tầng ứng dụng tách biệt với mã hóa truyền tải của Tor
  • Thương lượng mã hóa: trao đổi lẫn nhau khi kết nối và khi thay đổi, nếu không khớp sẽ hiển thị màu đỏ ở phần header
  • Đường truyền: liên lạc qua mạch Tor Hidden Service mà không lộ IP
  • Khả năng chống phân tích lưu lượng: mẫu truyền không đều để tránh bị tạo dấu vân tay
  • Xác thực: nếu khóa bí mật dùng chung không khớp thì giải mã sẽ thất bại
  • Chữ ký HMAC-SHA256: mọi thông điệp đều kèm nonce ngẫu nhiên để chặn tấn công phát lại
  • Giới hạn:
    • Khóa bí mật phải được trao đổi qua một kênh an toàn bên ngoài
    • Không có perfect forward secrecy, nếu lộ khóa thì có thể giải mã liên lạc trong quá khứ
    • Không thể bảo vệ nếu an ninh ở endpoint bị xâm phạm

Giấy phép

  • MIT License

Bài viết liên quan

1 bình luận

 
GN⁺ 2026-02-28
Ý kiến trên Hacker News

  • Cấu trúc dùng địa chỉ onion v3 đồng thời làm ID mật mã và tầng NAT traversal thật sự rất gọn gàng
    Không cần STUN/TURN server hay hole punching, chỉ cần chạy script là Tor sẽ xử lý việc định tuyến
    Tò mò không biết độ trễ thực tế khi truyền các đoạn âm thanh Opus khoảng 20KB qua Tor là bao nhiêu — tầm 2~3 giây hay còn tệ hơn nữa

    • Độ trễ thực tế vào khoảng 2~3 giây. Ban đầu tôi thử full-duplex nhưng quá kinh khủng
      Kiểu walkie-talkie buộc người dùng phải theo thứ tự “nghe-rồi-nói”, nên độ trễ không còn là vấn đề lớn
    • STUN/TUN quan trọng vì hiệu quả băng thông
      Với STUN, lưu lượng chỉ đi giữa hai thiết bị, còn VPN như Tor phải đi qua toàn bộ các máy chủ trung gian nên chi phí lưu lượng cao
      Nếu VPS chỉ có giới hạn vài GB mỗi tháng thì đây là một ràng buộc lớn
    • Tôi không chắc có cần biến nó thành tin nhắn âm thanh để tăng thêm độ trễ hay không
      Có lẽ tin nhắn văn bản sẽ tốt hơn. Dù vậy bản thân dự án vẫn rất ngầu
    • Chỉ để lại tiếng bíp bíp

  • Thật thú vị khi thấy một ví dụ thực tế dùng onion service làm backend
    Sắp tới cũng sẽ hỗ trợ Arti onion client, cho phép nhúng Tor trực tiếp vào ứng dụng dưới dạng thư viện Rust
    Càng nhiều thử nghiệm như vậy thì cover traffic của mạng cũng sẽ tăng lên

    • Một trong những lý do khiến Tor khó dùng là nhiều quản trị viên IT xem Tor là đồng nghĩa với hoạt động bất hợp pháp
      Vì vậy trong các môi trường bị kiểm soát như mạng doanh nghiệp hay Wi‑Fi công cộng, gần như không thể dùng Tor

  • Nếu không cần thời gian thực thì phía nhận có thể thêm điều chỉnh tốc độ phát hoặc xử lý loại bỏ khoảng lặng để giảm độ trễ
    Cũng có thể phát nhanh âm thanh do nhiều người gửi cùng lúc
    Nếu đang dùng Opus thì có thể thử dùng cơ chế khôi phục lỗi DRED thử nghiệm làm codec
    Có thể thiết kế theo kiểu gửi dữ liệu DRED trước để người nhận vẫn nghe được tối thiểu một phần giọng nói ngay cả khi Tor bị ngắt trong lúc truyền

  • Phần “cung cấp 21 thuật toán mã hóa” khá thú vị. Có vẻ hơi nhiều

    • Là vì dùng OpenSSL, và thật ra kiểu “làm vì có thể làm được” thôi
      Tôi muốn dùng AES-GCM nhưng chỉ với riêng OpenSSL thì việc xử lý xác thực khá khó
      Bản thân Tor đã là E2EE, nên tầng này thực chất là mã hóa chồng thêm. Dù vậy tôi vẫn thích việc dữ liệu được mã hóa thêm một lần trước khi chạm tới mạng
    • Quá ám ảnh với một loại mã hóa cụ thể là nguy hiểm. Nó khiến kẻ tấn công biết rõ mục tiêu, từ đó lại trở thành điểm yếu

  • Gần đây GitLab có cảm giác nhanh hơn, không biết là thật sự đã được tối ưu hay chỉ là ảo giác do lazy loading

  • Tôi thật sự thích dự án này. Người dùng nên trao đổi thông tin xác thực một cách an toàn như thế nào? Email PGP có ổn không?

    • Tôi giả định là đang nói chuyện với người mà mình đã tin cậy sẵn
      Nếu có thể thì trao đổi trực tiếp khi gặp mặt, hoặc qua messenger bảo mật là lý tưởng nhất
    • Hoặc có thể dùng dịch vụ kiểu “oh by code” như 0x.co để ghi lại địa chỉ onion,
      hay để lại nó trong không gian vật lý (bảng đen, bảng thông báo, biển hiệu, v.v.)
      Cách này cho phép kết nối với đối tượng trong tương lai ngay cả khi hoàn toàn offline

  • Tính năng loại trừ quốc gia (Exclude Countries) trong mạch Tor khá thú vị
    Có cả preset như Five Eyes, Nine Eyes, Fourteen Eyes, và dùng ExcludeNodes cùng StrictNodes trong cấu hình torrc
    Tò mò không biết nó có thực sự giúp cải thiện bảo mật hay không

    • Đây cũng là một kiểu “làm vì có thể làm được”. Nếu các nhà phát triển Tor đưa nó vào như một tùy chọn thì chắc hẳn phải có lý do nào đó
      Việc tồn tại node bị xâm phạm là có thật, nên dù có hiệu quả hay không thì việc có quyền kiểm soát vẫn rất đáng chú ý
    • Dù không thể tránh hoàn toàn các node bị kiểm soát, nó vẫn giúp đi vòng qua ISP do chính phủ đó kiểm soát

  • Xét đến đặc tính độ trễ của Tor thì mô hình walkie-talkie là một thiết kế rất thông minh
    Âm thanh hai chiều thời gian thực sẽ trở nên gượng gạo nếu độ trễ khứ hồi vượt quá 150ms, trong khi Tor cộng thêm 50~200ms cho mỗi hop
    Nếu thiết kế theo kiểu store-and-forward thì không cần phải chống lại bản chất của mạng
    Tôi tò mò không biết dùng codec nào — nếu không phải thời gian thực thì trade-off của Opus có thể sẽ khác

    • Đang dùng Opus, và có thể điều chỉnh chất lượng trong khoảng 6kbps~64kbps
      Tôi khá ngạc nhiên vì ngay cả ở 6kbps thì khả năng nhận diện giọng nói vẫn khá cao
      Trên Termux không thể truy cập microphone, nên phải chuyển đổi âm thanh qua ứng dụng Termux API và ffmpeg
    • Có người đùa rằng bình luận này trông như do AI tự động tạo ra
    • Tôi cũng thích cách làm này vì nó cho thời gian để suy nghĩ giống như email hay tin nhắn
      Chỉ với vài giây độ trễ cũng có thể giảm bớt những đoạn đối thoại thừa không cần thiết

  • Không biết liệu có thể cấu hình cái này thành kiểu liên lạc nhóm, để nhiều người cùng tham gia một kênh hay không

    • Hiện tại chỉ hỗ trợ liên lạc 1:1, nhưng cũng đang khám phá tính năng gọi nhóm
    • Với cấu trúc E2EE thì liên lạc nhóm không hề đơn giản đến vậy

  • Trông khá vui nên tôi lướt qua code,
    '|| true' xuất hiện 76 lần, 'echo ""' 50 lần, ' [ ' 261 lần, '=$(' 90 lần

    • Tôi cũng thích bash nên thấy tò mò. Tôi hiểu vì sao '[' không được khuyến nghị,
      nhưng muốn biết vì sao các pattern như '|| true' lại bị xem là vấn đề. Tôi khá hay dùng nó cùng set -euo pipefail để xử lý lỗi tùy chỉnh