TerminalPhone – วอล์กกี้ทอล์กกี้เข้ารหัสแบบ end-to-end ที่ใช้งานจากบรรทัดคำสั่ง

 (gitlab.com)
7 คะแนน โดย GN⁺ 2026-02-28 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เครื่องมือสื่อสารสไตล์วอล์กกี้ทอล์กกี้ที่พัฒนาด้วย Bash สำหรับส่ง เสียงและข้อความแบบไม่ระบุตัวตนและเข้ารหัสแบบ end-to-end (E2EE) ผ่านเครือข่าย Tor
  • เชื่อมต่อกับอีกฝ่ายได้โดยตรงด้วยที่อยู่ .onion เท่านั้น โดยไม่ต้องมีเซิร์ฟเวอร์ บัญชี หรือหมายเลขโทรศัพท์ และใช้โครงสร้างแบบ push-to-talk (PTT) ที่อัดข้อความเสียงก่อนแล้วค่อยส่ง
  • มีความสามารถด้านความปลอดภัยที่แข็งแกร่ง เช่น เลือกอัลกอริทึมเข้ารหัสได้ 21 แบบ รวมถึง AES, ChaCha20, Camellia, ARIA, การยืนยันตัวตนด้วย HMAC-SHA256, และการสร้างกุญแจด้วย PBKDF2
  • รองรับทั้งสภาพแวดล้อม Linux และ Android Termux และทำงานได้ด้วยเครื่องมือมาตรฐานอย่าง sox·opus-tools·Tor·openssl เท่านั้น
  • ประกอบด้วยสคริปต์เพียงไฟล์เดียว ทำให้ ติดตั้งและดูแลรักษาง่าย และสามารถนำไปใช้กับ การวิจัยด้านความปลอดภัยและการทดลองสื่อสารที่เน้นความเป็นส่วนตัว ได้

ภาพรวม

  • TerminalPhone เป็นสคริปต์ Bash ที่ใช้ Tor hidden service เพื่อให้ผู้ใช้สองคนสามารถ แลกเปลี่ยนเสียงและข้อความแบบไม่ระบุตัวตน ได้
    • การสื่อสารทั้งหมดได้รับการป้องกันด้วยอัลกอริทึมที่เลือกได้ เช่น AES-256-CBC (ค่าเริ่มต้น)
    • ที่อยู่ .onion ทำหน้าที่เป็นตัวระบุผู้ใช้
    • ไม่ต้องมีโครงสร้างพื้นฐานฝั่งเซิร์ฟเวอร์หรือการสมัครบัญชี

ความสามารถหลัก

  • ข้อความเสียงแบบวอล์กกี้ทอล์กกี้: อัดเสียงก่อนแล้วส่ง ไม่มีการสตรีมแบบเรียลไทม์
  • แชตเข้ารหัสระหว่างการสนทนา: ส่งและรับข้อความด้วยปุ่ม T
  • ตรวจจับการวางสายอัตโนมัติ และ แสดงสถานะของอีกฝ่าย (กำลังอัดเสียง/รออยู่)
  • เลือกอัลกอริทึมเข้ารหัสได้ 21 แบบและแสดงผลการเจรจาแบบเรียลไทม์ พร้อม เปลี่ยนอัลกอริทึมได้ระหว่างการสนทนา
  • รองรับ Snowflake bridge เพื่อหลีกเลี่ยงการเซ็นเซอร์
  • มีฟีเจอร์เสริมหลากหลาย เช่น แชร์ที่อยู่ด้วย QR code, voice changer, เสียงแจ้งเตือน PTT, รับฟังอัตโนมัติ (auto-listen)
  • ป้องกัน replay attack ด้วย การยืนยันโปรโตคอลแบบ HMAC-SHA256
  • รองรับ การแสดงเส้นทางวงจรของ Tor และการตั้งค่าให้ยกเว้นบางประเทศ
  • เป็น ไฟล์ Bash เพียงไฟล์เดียว, ไม่ต้องใช้สิทธิ์ root, และทำงานได้แม้ในสภาพแวดล้อม แบนด์วิดท์ต่ำ (16kbps)

การติดตั้ง

  • Linux: รัน git clone แล้วตามด้วย bash terminalphone.sh จากนั้นใช้เมนูหมายเลข 7 เพื่อติดตั้ง dependency อัตโนมัติ
    • แพ็กเกจที่ต้องติดตั้ง: tor, opus-tools, sox, socat, openssl, alsa-utils
  • Android Termux:
    • ติดตั้งแอป Termux และ Termux:API จาก F-Droid
    • รัน pkg install termux-api แล้วตามด้วย bash terminalphone.sh
    • แพ็กเกจเพิ่มเติม: ffmpeg, openssl-tool, tor, sox, socat เป็นต้น

วิธีใช้งาน

  • ขั้นตอนพื้นฐาน
    1. รัน bash terminalphone.sh
    2. ใช้เมนูหมายเลข 7 เพื่อติดตั้ง dependency
    3. ใช้เมนูหมายเลข 8 เพื่อเริ่ม Tor
    4. ตั้งค่า shared secret key ในเมนูหมายเลข 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 encoding → AES encryption → Base64 encoding → ส่งผ่าน Tor
    • ฝั่งรับจะทำงานย้อนลำดับเพื่อ ถอดรหัสและเล่นเสียง
  • ข้อความของโปรโตคอล เป็นแบบข้อความล้วน โดยมี ID, CIPHER, PTT_START, AUDIO, MSG, HANGUP, PING เป็นต้น
  • บน Termux จะใช้ ffmpeg แปลง M4A เป็น PCM ก่อนประมวลผล

โครงสร้างด้านความปลอดภัย

  • การเข้ารหัส: ใช้กุญแจที่สร้างจาก PBKDF2 (ทำซ้ำ 10,000 รอบ) และเพิ่มการป้องกันในระดับแอปพลิเคชันแยกจากการเข้ารหัสการส่งผ่านของ Tor
  • การเจรจาอัลกอริทึมเข้ารหัส: มีการแลกเปลี่ยนกันตอนเชื่อมต่อและตอนเปลี่ยนค่า หากไม่ตรงกันจะแสดงหัวข้อเป็นสีแดง
  • เส้นทางการส่งข้อมูล: สื่อสารผ่านวงจร hidden service ของ Tor โดยไม่เปิดเผย IP
  • ความทนทานต่อการวิเคราะห์ทราฟฟิก: ใช้รูปแบบการส่งที่ไม่สม่ำเสมอเพื่อหลีกเลี่ยงการสร้างลายนิ้วมือ
  • การยืนยันตัวตน: หาก shared secret key ไม่ตรงกัน จะถอดรหัสไม่สำเร็จ
  • ลายเซ็น HMAC-SHA256: ทุกข้อความมี nonce แบบสุ่มเพื่อป้องกัน replay attack
  • ข้อจำกัด:
    • ต้องแลกเปลี่ยน secret key ผ่านช่องทางภายนอกที่ปลอดภัย
    • ไม่มี forward secrecy หากกุญแจรั่ว การสื่อสารในอดีตอาจถูกถอดรหัสได้
    • ไม่สามารถป้องกันได้หากความปลอดภัยของ endpoint ถูกเจาะ

ใบอนุญาต

  • MIT License

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2026-02-28
ความคิดเห็นจาก Hacker News

  • โครงสร้างที่ใช้ที่อยู่ onion v3 เป็นทั้ง ID เชิงเข้ารหัส และชั้น NAT traversal พร้อมกันนั้นดูเรียบสวยมาก
    ไม่ต้องมี STUN/TURN server หรือ hole punching แค่รันสคริปต์แล้ว Tor ก็จัดการ routing ให้
    อยากรู้ว่าตอนส่ง Opus audio chunk ขนาดราว 20KB ผ่าน Tor นั้น latency จริงอยู่ที่เท่าไร — ประมาณ 2–3 วินาที หรือหนักกว่านั้น

    • latency จริงอยู่ราว 2–3 วินาที ตอนแรกลองทำเป็น full duplex แต่แย่มาก
      แนวทางแบบวอล์กกี้ทอล์กกี้บังคับให้ผู้ใช้สลับจังหวะ ‘ฟัง-พูด’ จึงทำให้ latency ไม่ใช่ปัญหาใหญ่
    • STUN/TUN สำคัญในแง่ ประสิทธิภาพการใช้แบนด์วิดท์
      STUN มีทราฟฟิกวิ่งแค่ระหว่างอุปกรณ์สองฝั่ง แต่ VPN อย่าง Tor ต้องผ่านเซิร์ฟเวอร์กลางหลายจุด จึงมีต้นทุนทราฟฟิกสูง
      ถ้าใช้ VPS ที่จำกัดปริมาณข้อมูลต่อเดือนแค่ไม่กี่ GB ก็จะเป็นข้อจำกัดใหญ่
    • รู้สึกว่าไม่จำเป็นต้องเปลี่ยนเป็นข้อความเสียงแล้วเพิ่ม latency เลย
      ข้อความตัวอักษรน่าจะดีกว่า ถึงอย่างนั้นตัวโปรเจกต์เองก็เจ๋งมาก
    • ทิ้งไว้แค่เสียงบี๊บๆ

  • น่าสนใจที่ได้เห็น กรณีใช้งานจริงที่ใช้ onion service เป็นแบ็กเอนด์
    อีกไม่นานก็น่าจะรองรับ Arti onion client ที่สามารถฝัง Tor ลงในแอปได้โดยตรงในรูปแบบ Rust library
    ยิ่งมีความพยายามแบบนี้มากขึ้น cover traffic ของเครือข่ายก็น่าจะเพิ่มขึ้นด้วย

    • เหตุผลหนึ่งที่ใช้ Tor ได้ยาก คือผู้ดูแลระบบไอทีจำนวนมากมองว่า Tor เท่ากับกิจกรรมผิดกฎหมาย
      ทำให้แทบเป็นไปไม่ได้เลยที่จะใช้ Tor บนเครือข่ายองค์กรหรือ public Wi‑Fi ที่มีการควบคุม

  • ถ้าไม่จำเป็นต้องเป็นแบบเรียลไทม์ ฝั่งรับอาจใส่ การปรับความเร็วการเล่น หรือการตัดช่วงเงียบเพื่อช่วยลดความหน่วงได้
    และยังสามารถเล่นเสียงจากหลายคนที่ส่งมาพร้อมกันแบบเร่งความเร็วได้ด้วย
    ถ้าใช้ Opus อยู่ ก็อาจลองใช้ฟีเจอร์ทดลองอย่าง DRED error recovery scheme เป็นส่วนหนึ่งของ codec ได้
    อาจจัดให้ส่งข้อมูล DRED มาก่อน เพื่อให้ผู้รับยังได้ยินเสียงขั้นต่ำบางส่วนแม้ Tor จะหลุดระหว่างส่ง

  • ประโยคที่ว่า “มี อัลกอริทึมเข้ารหัส ให้เลือก 21 แบบ” น่าสนใจดี ดูเหมือนจะเยอะเกินไปหน่อย

    • เป็นเพราะใช้ OpenSSL และจริงๆ ก็เป็นแนว “ทำได้ก็เลยทำ”
      เดิมอยากใช้ AES-GCM แต่ถ้าใช้ OpenSSL อย่างเดียวจะจัดการส่วน authentication ได้ยาก
      ตัว Tor เองก็เป็น E2EE อยู่แล้ว ดังนั้นชั้นนี้จึงเป็น การเข้ารหัสซ้ำซ้อน อยู่บ้าง แต่ก็ชอบตรงที่มีการเข้ารหัสอีกชั้นก่อนถึงเครือข่าย
    • การยึดติดกับ cipher บางตัวมากเกินไปเป็นเรื่องอันตราย เพราะทำให้ผู้โจมตีรู้เป้าหมายชัดขึ้น และอาจกลายเป็น ช่องโหว่ ได้

  • รู้สึกว่า GitLab เร็วขึ้นกว่าเดิม ในช่วงนี้ เลยสงสัยว่าเขาปรับแต่งจริงหรือแค่เป็นภาพลวงจาก lazy loading

  • ชอบโปรเจกต์นี้มาก คำถามคือผู้ใช้จะแลกเปลี่ยน ข้อมูลยืนยันตัวตน กันอย่างปลอดภัยได้อย่างไร? ใช้ PGP email จะโอเคไหม?

    • ผมตั้งสมมติฐานว่าเป็นการคุยกับคนที่เชื่อใจกันอยู่แล้ว
      ถ้าเป็นไปได้ การเจอกันต่อหน้าเพื่อแลกเปลี่ยนกันตรงๆ หรือใช้ secure messenger จะเหมาะที่สุด
    • หรือจะใช้บริการ “oh by code” อย่าง 0x.co เพื่อเขียนที่อยู่ onion ทิ้งไว้ก็ได้ หรือ
      จะทิ้งไว้ใน พื้นที่ทางกายภาพ (กระดานดำ บอร์ดประกาศ ป้าย ฯลฯ) ก็ได้เช่นกัน
      แบบนี้ทำให้เชื่อมต่อกับคู่สนทนาในอนาคตได้แม้อยู่ในสภาวะออฟไลน์ทั้งหมด

  • ฟีเจอร์ในวงจร Tor ที่ให้ ยกเว้นบางประเทศ (Exclude Countries) น่าสนใจดี
    มีทั้งพรีเซ็ตอย่าง Five Eyes, Nine Eyes, Fourteen Eyes และใช้ ExcludeNodes กับ StrictNodes ในการตั้งค่า torrc
    สงสัยว่ามันช่วยเพิ่มความปลอดภัยได้จริงหรือไม่

    • ก็เป็นอีกอย่างในหมวด “ทำได้ก็เลยทำ” เหมือนกัน ถ้า Tor developers ใส่เป็นตัวเลือกมา ก็น่าจะมีเหตุผลบางอย่าง
      การมีอยู่ของ โหนดที่ถูกเจาะหรือถูกควบคุม เป็นเรื่องจริงอยู่แล้ว ดังนั้นไม่ว่าจะได้ผลแค่ไหน การที่ผู้ใช้มีสิทธิ์ควบคุมก็ถือว่าน่าสนใจ
    • ถึงจะไม่สามารถหลีกเลี่ยงโหนดที่ถูกควบคุมทั้งหมดได้ แต่อย่างน้อยก็ช่วยเลี่ยง ISP ที่รัฐบาลนั้นควบคุมอยู่ได้

  • เมื่อดูจากลักษณะ latency ของ Tor แล้ว โมเดลแบบวอล์กกี้ทอล์กกี้ ถือว่าออกแบบได้ฉลาดมาก
    เสียงสองทางแบบเรียลไทม์จะเริ่มฟังแปลกเมื่อ round-trip เกิน 150ms แต่ Tor เพิ่มความหน่วงต่อ hop อีกราว 50–200ms
    ถ้าออกแบบเป็นแบบ store-and-forward ก็ไม่ต้องฝืนสู้กับธรรมชาติของเครือข่าย
    อยากรู้ว่าใช้ codec อะไร — ถ้าไม่ใช่เรียลไทม์ จุดแลกเปลี่ยนของ Opus อาจต่างออกไป

    • ตอนนี้ใช้ Opus อยู่ และปรับคุณภาพได้ตั้งแต่ 6kbps~64kbps
      น่าประหลาดใจที่แม้ที่ 6kbps ก็ยังฟังรู้เรื่องได้ดีพอสมควร
      บน Termux เข้าถึงไมค์ไม่ได้ จึงต้องแปลงเสียงผ่าน แอป Termux API กับ ffmpeg
    • มีคนแซวว่าคอมเมนต์นี้ เหมือน AI สร้างอัตโนมัติ
    • ผมก็ชอบวิธีนี้เหมือนกัน เพราะมันคล้ายอีเมลหรือข้อความที่ให้เวลาคิดก่อนพูด
      latency แค่ไม่กี่วินาทีก็ช่วยลด บทสนทนาน้ำท่วมทุ่ง ที่ไม่จำเป็นได้

  • ไม่แน่ใจว่าสามารถตั้งให้เป็นแบบ การสื่อสารแบบกลุ่ม ที่หลายคนเข้าช่องเดียวกันได้ไหม

    • ตอนนี้ยังรองรับแค่ 1:1 แต่ก็กำลังสำรวจ ฟีเจอร์การโทรแบบกลุ่ม อยู่
    • ด้วยโครงสร้าง E2EE แล้ว การสื่อสารแบบกลุ่มไม่ได้ง่ายขนาดนั้น

  • ดูน่าสนุกดีเลยลองไล่โค้ดคร่าวๆ แล้วพบว่า
    '|| true' 76 ครั้ง, 'echo ""' 50 ครั้ง, ' [ ' 261 ครั้ง, '=$(' 90 ครั้ง

    • ผมก็ชอบ bash เลยสงสัยเหมือนกัน เข้าใจว่าทำไม '[' ถึงไม่ค่อยแนะนำใช้ แต่
      อยากรู้ว่าแพตเทิร์นอย่าง '|| true' มีปัญหาตรงไหน เพราะผมก็ใช้มันบ่อยกับ set -euo pipefail สำหรับทำ custom error handling