TerminalPhone – कमांड लाइन में इस्तेमाल होने वाला end-to-end encrypted वॉकी-टॉकी

 (gitlab.com)
7 पॉइंट द्वारा GN⁺ 2026-02-28 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Tor नेटवर्क के ज़रिए वॉइस और टेक्स्ट को anonymous तथा end-to-end encrypted (E2EE) तरीके से भेजने-लेने वाला Bash-आधारित वॉकी-टॉकी शैली का कम्युनिकेशन टूल
  • सर्वर, अकाउंट, या फोन नंबर के बिना केवल .onion पते से सामने वाले से सीधे कनेक्ट होता है, और रिकॉर्ड की गई वॉइस मैसेज भेजने वाली push-to-talk (PTT) संरचना का उपयोग करता है
  • AES, ChaCha20, Camellia, ARIA सहित 21 एन्क्रिप्शन विकल्प, HMAC-SHA256 authentication, PBKDF2 key derivation जैसी मज़बूत सुरक्षा सुविधाएँ देता है
  • Linux और Android Termux दोनों वातावरणों को सपोर्ट करता है, और sox·opus-tools·Tor·openssl जैसे मानक टूल्स से ही चलता है
  • एक ही स्क्रिप्ट से बना होने के कारण इंस्टॉलेशन और मेंटेनेंस सरल है, और security research·privacy-केंद्रित कम्युनिकेशन प्रयोगों में उपयोग किया जा सकता है

अवलोकन

  • TerminalPhone एक Bash स्क्रिप्ट है जो Tor hidden service का उपयोग करके दो यूज़र्स को anonymous तरीके से वॉइस और टेक्स्ट का आदान-प्रदान करने देती है
    • सभी संचार AES-256-CBC (डिफॉल्ट) सहित चुने जा सकने वाले cipher से सुरक्षित होते हैं
    • .onion पता यूज़र पहचानकर्ता की भूमिका निभाता है
    • सर्वर इंफ्रास्ट्रक्चर या अकाउंट रजिस्ट्रेशन की आवश्यकता नहीं है

मुख्य विशेषताएँ

  • वॉकी-टॉकी शैली के वॉइस मैसेज: रिकॉर्ड करने के बाद भेजे जाते हैं, रियल-टाइम स्ट्रीमिंग नहीं है
  • कॉल के दौरान encrypted चैट: T key से टेक्स्ट मैसेज भेजना और प्राप्त करना
  • ऑटोमैटिक hangup detection और सामने वाले की स्थिति दिखाना (रिकॉर्डिंग/प्रतीक्षा)
  • 21 cipher विकल्प और रियल-टाइम negotiation display, कॉल के बीच में cipher बदलने की सुविधा
  • Snowflake bridge support के ज़रिए censorship से बचाव संभव
  • QR code address sharing, voice changer, PTT notification sound, auto-listen जैसी कई अतिरिक्त सुविधाएँ
  • HMAC-SHA256 protocol authentication से replay attack की रोकथाम
  • Tor circuit path display और specific country exclusion setting का समर्थन
  • single Bash file, root permission की आवश्यकता नहीं, और low-bandwidth (16kbps) वातावरण में भी काम करता है

इंस्टॉलेशन

  • Linux: git clone के बाद bash terminalphone.sh चलाएँ, और मेनू 7 से dependencies का ऑटोमैटिक इंस्टॉलेशन करें
    • इंस्टॉल पैकेज: 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 से dependencies इंस्टॉल करें
    3. मेनू 8 से Tor शुरू करें
    4. मेनू 4 में shared secret key सेट करें
    5. .onion पता सामने वाले को दें
  • रिसीव करना: मेनू 1 “Listen for calls”
  • कॉल करना: मेनू 2 “Call an onion address”
  • CLI mode कमांड उदाहरण:
    • bash terminalphone.sh call ADDRESS
    • bash terminalphone.sh listen

कार्य करने का तरीका

  • record-then-send मॉडल
    • रिकॉर्ड की गई वॉइस को Opus encoding → AES encryption → Base64 encoding → Tor transmission के क्रम में प्रोसेस किया जाता है
    • रिसीवर पक्ष पर यही प्रक्रिया उल्टे क्रम में decrypt और playback के लिए होती है
  • protocol messages टेक्स्ट-आधारित हैं और इनमें ID, CIPHER, PTT_START, AUDIO, MSG, HANGUP, PING आदि शामिल हैं
  • Termux में ffmpeg के ज़रिए M4A को PCM में बदलकर प्रोसेस किया जाता है

सुरक्षा संरचना

  • एन्क्रिप्शन: PBKDF2 (10,000 iterations) से निकाली गई key का उपयोग होता है, और Tor ट्रांसपोर्ट एन्क्रिप्शन से अलग application layer पर अतिरिक्त सुरक्षा दी जाती है
  • cipher negotiation: कनेक्शन के समय और बदलाव के समय आपसी आदान-प्रदान होता है; mismatch होने पर header में लाल संकेत दिखता है
  • ट्रांसमिशन पथ: Tor hidden service circuit के माध्यम से IP उजागर किए बिना संचार
  • traffic analysis resistance: अनियमित ट्रांसमिशन पैटर्न से fingerprinting को रोकने की कोशिश
  • authentication: shared secret key मेल न खाने पर decryption विफल हो जाती है
  • HMAC-SHA256 signature: हर संदेश में random nonce शामिल होता है, जिससे replay attack रुकता है
  • सीमाएँ:
    • secret key का आदान-प्रदान बाहरी सुरक्षित चैनल से करना होगा
    • forward secrecy नहीं है, इसलिए key लीक होने पर पुराने संचार को decrypt किया जा सकता है
    • endpoint security compromise होने पर सुरक्षा संभव नहीं

लाइसेंस

  • MIT License

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2026-02-28
Hacker News टिप्पणियाँ

  • v3 onion address को cryptographic ID और NAT traversal layer, दोनों के रूप में साथ में इस्तेमाल करने वाली यह संरचना वाकई बहुत साफ-सुथरी है
    STUN/TURN server या hole punching की ज़रूरत नहीं पड़ती; बस script चलाइए और routing Tor संभाल लेता है
    Tor पर लगभग 20KB के Opus audio chunk भेजते समय असली latency कितनी होती है, यह जानने की जिज्ञासा है — करीब 2~3 सेकंड, या उससे भी ज़्यादा?

    • असली latency लगभग 2~3 सेकंड है। शुरू में इसे full duplex के रूप में आज़माया था, लेकिन वह बहुत खराब था
      walkie-talkie तरीका उपयोगकर्ता को ‘सुनो-फिर बोलो’ क्रम का पालन करने देता है, इसलिए latency बड़ी समस्या नहीं बनती
    • STUN/TUN bandwidth efficiency की वजह से महत्वपूर्ण हैं
      STUN में traffic सिर्फ़ दो डिवाइसों के बीच जाता है, लेकिन Tor जैसे VPN में बीच के सभी serverों से होकर गुजरना पड़ता है, इसलिए traffic cost ज़्यादा होती है
      अगर VPS पर हर महीने कुछ GB की सीमा हो, तो यह बड़ा प्रतिबंध बन जाता है
    • समझ नहीं आता कि इसे audio message में बदलकर latency बढ़ाने की ज़रूरत क्यों है
      शायद text message बेहतर होता। फिर भी project अपने आप में शानदार है
    • सिर्फ़ बीप-बीप की आवाज़ छोड़ दें

  • onion service को backend के रूप में इस्तेमाल किए गए वास्तविक उदाहरण को देखना दिलचस्प है
    जल्द ही Rust library के रूप में Tor को सीधे app में embed करने वाले Arti onion client का भी समर्थन आने वाला है
    ऐसे प्रयास जितने बढ़ेंगे, network का cover traffic भी उतना बढ़ेगा

    • Tor का उपयोग करना कठिन होने के कारणों में से एक यह धारणा भी है कि बहुत से IT admin Tor को गैरकानूनी गतिविधियों के बराबर मानते हैं
      इसलिए enterprise network या public Wi‑Fi जैसे नियंत्रित माहौल में Tor का इस्तेमाल लगभग असंभव होता है

  • अगर real-time ज़रूरी न हो, तो receiver side पर playback speed control या silence removal जैसी processing जोड़कर latency घटाई जा सकती है
    कई लोगों द्वारा एक साथ भेजे गए audio को तेज़ी से चलाना भी संभव है
    अगर Opus इस्तेमाल हो रहा है, तो उसके experimental feature DRED error recovery scheme को codec के रूप में आज़माया जा सकता है
    इसे ऐसे बनाया जा सकता है कि transmission के दौरान Tor कट जाने पर भी receiver को कम-से-कम कुछ आवाज़ मिल जाए, इसके लिए DRED data पहले भेजा जाए

  • “21 cryptographic algorithms उपलब्ध हैं” वाला हिस्सा दिलचस्प है। यह कुछ ज़्यादा ही लगता है

    • यह OpenSSL के इस्तेमाल की वजह से है, और सच कहें तो “कर सकते थे, इसलिए कर दिया” वाली बात है
      AES-GCM इस्तेमाल करना चाहता था, लेकिन सिर्फ़ OpenSSL से authentication संभालना कठिन था
      Tor ख़ुद पहले से E2EE है, इसलिए यह layer वास्तव में redundant encryption है। फिर भी network तक पहुँचने से पहले एक बार और encrypt होना अच्छा लगता है
    • किसी खास cipher पर ज़रूरत से ज़्यादा अटकना जोखिमभरा है। इससे attacker को लक्ष्य साफ़ दिख जाता है और उल्टा vulnerability बन सकती है

  • लगता है GitLab हाल में ज़्यादा तेज़ हो गया है; समझ नहीं आता कि सचमुच optimize हुआ है या यह lazy loading का भ्रम है

  • यह project सच में बहुत पसंद आया। users को credentials सुरक्षित तरीके से exchange कैसे करने चाहिए? क्या PGP email ठीक रहेगा?

    • मैं यह मानकर चल रहा हूँ कि बात पहले से भरोसेमंद व्यक्ति से हो रही है
      संभव हो तो आमने-सामने मिलकर exchange करना, या secure messenger के ज़रिए exchange करना आदर्श है
    • या 0x.co जैसी “oh by code” service का उपयोग करके onion address लिखकर छोड़ा जा सकता है,
      या उसे physical space (blackboard, notice board, signboard आदि) में भी छोड़ा जा सकता है
      इससे पूरी तरह offline स्थिति में भी भविष्य के किसी संपर्क से जुड़ना संभव है

  • Tor circuit में कुछ देशों को exclude (Exclude Countries) करने की सुविधा दिलचस्प है
    Five Eyes, Nine Eyes, Fourteen Eyes जैसे preset भी हैं, और torrc setting में ExcludeNodes और StrictNodes का उपयोग होता है
    जानना चाहता हूँ कि क्या यह वास्तव में security बेहतर करने में मदद करता है

    • यह भी “कर सकते थे, इसलिए कर दिया” वाली चीज़ों में से एक है। Tor developers ने इसे option के रूप में रखा है, तो शायद कुछ वजह होगी
      compromised node का होना वास्तविक संभावना है, इसलिए असर हो या न हो, control होना अपने आप में दिलचस्प है
    • भले ही पूरी तरह नियंत्रित node से बचना संभव न हो, लेकिन उस सरकार के नियंत्रण वाले ISP को bypass करने में यह मदद कर सकता है

  • Tor की latency विशेषताओं को देखते हुए walkie-talkie model बहुत समझदारी भरा design है
    real-time two-way audio में round-trip 150ms से ऊपर हो जाए तो बातचीत अटपटी लगने लगती है, जबकि Tor हर hop पर 50~200ms जोड़ देता है
    अगर इसे store-and-forward तरीके से design किया जाए, तो network की प्रकृति से लड़ना नहीं पड़ता
    यह जानने की जिज्ञासा है कि कौन-सा codec इस्तेमाल हो रहा है — अगर यह real-time नहीं है, तो Opus के trade-off अलग हो सकते हैं

    • Opus इस्तेमाल किया जा रहा है, और 6kbps~64kbps के बीच quality adjust की जा सकती है
      6kbps पर भी speech intelligibility काफ़ी अच्छी देखकर हैरानी हुई
      Termux में mic access नहीं मिलता, इसलिए Termux API app और ffmpeg के ज़रिए audio convert करना पड़ता है
    • किसी ने मज़ाक में कहा कि यह टिप्पणी AI द्वारा अपने-आप बनाई हुई लगती है
    • मुझे भी यह तरीका पसंद है, क्योंकि यह email या text की तरह सोचकर बोलने का समय देता है
      सिर्फ़ कुछ सेकंड की देरी भी अनावश्यक फालतू बातचीत को कम कर सकती है

  • क्या इसे group communication की तरह सेट किया जा सकता है, ताकि कई लोग एक ही channel में शामिल हो सकें?

    • अभी केवल 1:1 communication समर्थित है, लेकिन group call feature भी तलाशा जा रहा है
    • E2EE संरचना में group communication उतना सरल नहीं है

  • मज़ेदार लगा, इसलिए code पर सरसरी नज़र डाली,
    '|| true' 76 बार, 'echo ""' 50 बार, ' [ ' 261 बार, '=$(' 90 बार दिखाई दिया

    • मुझे भी bash पसंद है, इसलिए जिज्ञासा हुई। '[' के खिलाफ सलाह क्यों दी जाती है, यह तो समझता हूँ,
      लेकिन '|| true' जैसे pattern समस्या क्यों माने जाते हैं, यह जानना चाहता हूँ। मैं इसे set -euo pipefail के साथ custom error handling के लिए अक्सर इस्तेमाल करता हूँ