TerminalPhone – Komut satırında kullanılan uçtan uca şifreli bir telsiz

 (gitlab.com)
7 puan yazan GN⁺ 2026-02-28 | 1 yorum | WhatsApp'ta paylaş
  • Tor ağı üzerinden ses ve metni anonim ve uçtan uca şifreli (E2EE) biçimde ileten, Bash tabanlı telsiz tarzı bir iletişim aracı
  • Sunucu, hesap veya telefon numarası olmadan, yalnızca .onion adresiyle karşı tarafa doğrudan bağlanır; sesli mesajı kaydedip gönderen bas-konuş (PTT) yapısını kullanır
  • AES, ChaCha20, Camellia, ARIA dahil 21 şifre seçeneği, HMAC-SHA256 kimlik doğrulaması, PBKDF2 anahtar türetme gibi güçlü güvenlik özellikleri sunar
  • Linux ve Android Termux ortamlarının ikisini de destekler ve yalnızca sox·opus-tools·Tor·openssl gibi standart araçlarla çalışır
  • Tek bir betikten oluştuğu için kurulum ve bakım basittir; güvenlik araştırmaları ve mahremiyet odaklı iletişim deneyleri için kullanılabilir

Genel bakış

  • TerminalPhone, Tor hidden service kullanarak iki kullanıcının anonim olarak ses ve metin alışverişi yapmasını sağlayan bir Bash betiğidir
    • Tüm iletişim, varsayılan olarak AES-256-CBC dahil seçilebilir şifrelerle korunur
    • .onion adresi kullanıcı tanımlayıcısı görevi görür
    • Sunucu altyapısı veya hesap kaydı gerekmez

Başlıca özellikler

  • Telsiz tarzı sesli mesajlaşma: kaydedip gönderir, gerçek zamanlı akış yoktur
  • Görüşme sırasında şifreli sohbet: T tuşuyla metin mesajı gönderip alma
  • Otomatik kapanış algılama ve karşı taraf durum göstergesi (kayıtta/beklemede)
  • 21 şifre seçimi ve anlık anlaşma durumu gösterimi, görüşme ortasında şifre değiştirme imkanı
  • Snowflake bridge desteği ile sansürü aşma
  • QR kodla adres paylaşımı, ses değiştirici (voice changer), PTT bildirim sesi, otomatik dinleme (auto-listen) gibi çeşitli ek özellikler
  • HMAC-SHA256 protokol kimlik doğrulaması ile yeniden oynatma saldırılarını önleme
  • Tor devre yolunu gösterme ve belirli ülkeleri hariç tutma ayarı desteği
  • Tek Bash dosyası, root yetkisi gerekmez, düşük bant genişliğinde (16kbps) bile çalışır

Kurulum

  • Linux: git clone sonrası bash terminalphone.sh çalıştırın, bağımlılıkları otomatik kurmak için menüde 7. seçeneği kullanın
    • Kurulan paketler: tor, opus-tools, sox, socat, openssl, alsa-utils
  • Android Termux:
    • F-Droid üzerinden Termux ve Termux:API uygulamalarını kurun
    • pkg install termux-api sonrasında bash terminalphone.sh çalıştırın
    • Ek paketler: ffmpeg, openssl-tool, tor, sox, socat vb.

Kullanım

  • Temel adımlar
    1. bash terminalphone.sh çalıştırın
    2. Menüde 7. seçenekle bağımlılıkları kurun
    3. Menüde 8. seçenekle Tor'u başlatın
    4. Menüde 4. seçenekten paylaşılan gizli anahtarı ayarlayın
    5. .onion adresini karşı tarafa iletin
  • Gelen çağrı alma: menüde 1. seçenek “Listen for calls”
  • Arama yapma: menüde 2. seçenek “Call an onion address”
  • CLI modu komut örnekleri:
    • bash terminalphone.sh call ADDRESS
    • bash terminalphone.sh listen

Çalışma şekli

  • Kaydet ve gönder (record-then-send) modeli
    • Kaydedilen ses, Opus kodlama → AES şifreleme → Base64 kodlama → Tor üzerinden iletim adımlarından geçer
    • Alıcı taraf bunu ters sırayla deşifre eder ve oynatır
  • Protokol mesajları metin tabanlıdır ve ID, CIPHER, PTT_START, AUDIO, MSG, HANGUP, PING gibi öğeleri içerir
  • Termux üzerinde ffmpeg ile M4A, PCM'e dönüştürüldükten sonra işlenir

Güvenlik yapısı

  • Şifreleme: PBKDF2 (10.000 yineleme) ile türetilen anahtar kullanılır; Tor taşıma şifrelemesinden ayrı olarak uygulama katmanında ek koruma sağlar
  • Şifre anlaşması: bağlantı kurarken ve değiştirirken karşılıklı olarak paylaşılır; uyuşmazlık varsa başlıkta kırmızı gösterilir
  • İletim yolu: IP açığa çıkmadan Tor hidden service devresi üzerinden iletişim kurulur
  • Trafik analizi direnci: düzensiz iletim desenleriyle parmak izi çıkarılmasını zorlaştırır
  • Kimlik doğrulama: paylaşılan gizli anahtar eşleşmezse deşifre başarısız olur
  • HMAC-SHA256 imzası: tüm mesajlara rastgele nonce eklenir, yeniden oynatma saldırıları engellenir
  • Sınırlamalar:
    • Gizli anahtarın harici güvenli bir kanal üzerinden paylaşılması gerekir
    • İleriye dönük gizlilik yoktur; anahtar sızarsa geçmiş iletişim çözülebilir
    • Uç nokta güvenliği ihlal edilirse koruma sağlanamaz

Lisans

  • MIT License

İlgili okumalar

1 yorum

 
GN⁺ 2026-02-28
Hacker News yorumları

  • v3 onion adresini aynı anda hem kriptografik kimlik hem de NAT geçiş katmanı olarak kullanma fikri gerçekten çok zarif
    STUN/TURN sunucularına ya da hole punching’e gerek kalmadan, betiği çalıştırınca yönlendirmeyi Tor’un halletmesi çok hoş
    Tor üzerinden yaklaşık 20KB’lık Opus ses parçaları gönderirken gerçek gecikmenin ne kadar olduğunu merak ediyorum — 2–3 saniye civarında mı, yoksa daha mı kötü

    • Gerçek gecikme yaklaşık 2–3 saniye. Başta full duplex denedim ama korkunçtu
      Telsiz tarzı kullanımda insanlar doğal olarak ‘dinle-sonra konuş’ sırasını izlediği için gecikme büyük sorun olmuyor
    • STUN/TUN, bant genişliği verimliliği açısından önemli
      STUN’da trafik yalnızca iki cihaz arasında akar, ama Tor gibi bir VPN’de ara sunucuların hepsinden geçtiği için trafik maliyeti yükselir
      VPS üzerinde aylık birkaç GB sınırı varsa bu ciddi bir kısıt olur
    • Sırf sesli mesaja çevirip gecikmeyi artırmaya gerek var mı emin değilim
      Düz metin mesajlar belki daha iyi olurdu. Yine de projenin kendisi harika
    • Sadece bip sesini bırakmış

  • onion servislerinin arka uç olarak kullanıldığı gerçek bir örneği görmek ilginç
    Yakında Tor’u doğrudan uygulamaya gömebilen Rust kütüphanesi biçimindeki Arti onion istemcisi de desteklenecekmiş
    Bu tür denemeler arttıkça ağın cover traffic miktarı da artacaktır

    • Tor kullanmanın zor olmasının nedenlerinden biri, birçok BT yöneticisinin Tor’u yasadışı faaliyetlerle özdeşleştirmesi
      Bu yüzden kurumsal ağlar veya halka açık Wi‑Fi gibi denetimli ortamlarda Tor kullanmak neredeyse imkânsız

  • Gerçek zamanlı olmak zorunda değilse, alıcı tarafında oynatma hızını ayarlama veya sessizlikleri kaldırma işlemleriyle gecikme azaltılabilir
    Aynı anda birden fazla kişinin gönderdiği sesleri hızlandırılmış şekilde çalmak da mümkün olur
    Opus kullanılıyorsa, deneysel DRED hata kurtarma şeması da kodek içinde değerlendirilebilir
    Aktarım sırasında Tor bağlantısı kopsa bile, DRED verisini önce göndererek alıcının en azından asgari düzeyde sesi alması sağlanabilir

  • “21 adet şifreleme algoritması sunuluyor” kısmı ilginç. Biraz fazla gibi duruyor

    • Bunun sebebi OpenSSL kullanılması; açıkçası biraz da “yapabiliyorken yaptım” durumu
      AES-GCM kullanmak istemiştim ama yalnızca OpenSSL ile kimlik doğrulamayı düzgün yapmak zordu
      Tor zaten başlı başına E2EE sağladığı için bu katman aslında tekrarlı şifreleme oluyor. Yine de ağa ulaşmadan önce bir kez daha şifrelenmesi hoşuma gidiyor
    • Belirli bir şifreye aşırı takılmak tehlikeli olabilir. Saldırgana hedefi net gösterdiğiniz için bu başlı başına bir zayıflık yaratabilir

  • GitLab son zamanlarda daha hızlıymış gibi hissettiriyor; gerçekten optimize edildi mi, yoksa bu sadece lazy loading kaynaklı bir yanılsama mı merak ediyorum

  • Bu projeyi gerçekten sevdim. Kullanıcılar kimlik bilgilerini güvenli şekilde nasıl değiş tokuş etmeli? PGP e-postası uygun olur mu?

    • Ben zaten güvenilen biriyle konuşulduğunu varsayıyorum
      Mümkünse yüz yüze paylaşmak ya da güvenli bir mesajlaşma uygulaması üzerinden iletmek en ideali
    • Ya da 0x.co gibi “oh by code” servisleriyle onion adresini bırakabilir,
      hatta bunu fiziksel bir mekâna (tahta, ilan panosu, tabela vb.) yazabilirsiniz
      Böylece tamamen çevrimdışı koşullarda bile gelecekteki bir karşı tarafla bağlantı kurulabilir

  • Tor devresinde belirli ülkeleri hariç tutma (Exclude Countries) özelliği ilginç
    Five Eyes, Nine Eyes, Fourteen Eyes gibi hazır seçenekler de var; torrc içinde ExcludeNodes ve StrictNodes kullanılıyor
    Bunun gerçekten güvenliği artırıp artırmadığını merak ediyorum

    • Bu da biraz “yapabiliyorken yaptım” özelliklerinden biri. Tor geliştiricileri seçenek olarak koyduysa bir sebebi vardır herhalde
      Ele geçirilmiş düğümlerin var olduğu bir gerçek; etkili olsun ya da olmasın, en azından kullanıcıya kontrol vermesi ilginç
    • Tamamen kontrol altındaki düğümlerden kaçınmayı garanti etmese bile, ilgili hükümetin kontrol ettiği İSS’leri atlatmaya yardımcı olabilir

  • Tor’un gecikme yapısını düşününce telsiz modeli çok akıllıca bir tasarım
    Gerçek zamanlı iki yönlü seste gidiş-dönüş 150 ms’yi geçince iletişim yapaylaşır, ama Tor her sıçramada buna 50–200 ms ekler
    store-and-forward tarzında tasarlarsanız ağın doğasına karşı savaşmanız gerekmez
    Hangi kodekin kullanıldığını merak ediyorum — gerçek zamanlı değilse Opus’un ödünleşimleri farklı olabilir

    • Opus kullanılıyor ve kalite 6kbps–64kbps arasında ayarlanabiliyor
      6kbps’de bile konuşmanın anlaşılabilirliğinin epey yüksek olmasına şaşırdım
      Termux’ta mikrofon erişimi olmadığı için sesin Termux API uygulaması ve ffmpeg ile dönüştürülmesi gerekiyor
    • Biri bu yorumun yapay zeka tarafından otomatik üretilmiş gibi göründüğü şakasını yapmış
    • Ben de bunu e-posta veya SMS gibi düşünüp konuşmak için zaman tanıyan yaklaşımı seviyorum
      Sadece birkaç saniyelik gecikme bile gereksiz dolgu konuşmaları azaltabilir

  • Bunu grup iletişimi gibi, birden fazla kişinin aynı kanala katıldığı bir yapıya dönüştürmenin mümkün olup olmadığını merak ediyorum

    • Şu anda yalnızca 1:1 iletişim destekleniyor ama grup görüşmesi özelliği de araştırılıyor
    • E2EE yapısı nedeniyle grup iletişimi o kadar da basit değil

  • Eğlenceli göründüğü için koda göz gezdirdim;
    '|| true' 76 kez, 'echo ""' 50 kez, ' [ ' 261 kez, '=$(' 90 kez geçiyor

    • Ben de bash sevdiğim için merak ettim. '[' kullanımının neden önerilmediğini anlıyorum ama,
      '|| true' gibi kalıpların neden sorunlu sayıldığını bilmek istiyorum. Ben bunu set -euo pipefail ile birlikte özel hata işleme için sık kullanıyorum