Fórum Root.cz
Hlavní témata => Software => Téma založeno: oss 22. 01. 2024, 08:28:26
-
Ahojte viete mi podarit Instant messaging protokol, alebo softver, ktory dokaze zamaskovat kto si s kym pisal?
Ide o to, ze ked ma niekto globalny prehlad o sieti, tak je jedno, ze protokol je sifrovany, ale ked Alica posle spravu Bobovi tak monitoringom siete to ide zistit, aj to, ze si odpisali a kolko si vymenili sprav.
Jestvuje nejaky protokol, ktory to dokaze zamaskovat?
-
tor a onion routing
-
tor riesi iny problem
-
Z principu instant messagingu to nejde - vzdy mas nekde vstupni pattern zprav v casove ose a nekde vystupni - a kdyz to sparujes tak identifikujes obe strany.
Tenhle princip se pouziva i pro odhaleni uzivatelu vpn, toru a pod, ze strany globalnich hracu / agentur co maj rozpocet na monitoring siti v danem meritku.
-
tor riesi iny problem
tor řeší přesně ten zadaný problém, pokud používáte protokol na bázi peer to peer. Třeba federovaný Jabber, kde mají A, B a C vlastní servery.
Co neřeší a ani nemůže, je Vaše důvěra v server, který zprostředkovává výměnu metadat pro spojení. U Jabberu je to DNS + servery A a B (pro rozlišení lokálních uživatelů).
Nebo i jednodušeji. SMTP. Také federované P2P. Ale na úrovni serveru už toho lokálního uživatele neutajíte, musíte nějak určit do jaké to půjde schránky.
-
bud se ti lidi znaji a chteji si psat bez cumilu, tak si muzou predat vizitky na jejich .onion domeny a v toru se muzou spojit bez ciziho koukani.
nebo muzou byt v toru vyhledavace, kde najdu nekoho kdo mi tajne vymaluje sklep a ani tu osobu nemusim znat a muzu se s ni zkontaktovat.
-
Rozhodně nic s centrálním servem / servery. Ideálu se v tomhle dost blíží P2P sítě jako Tox.
-
A co bitchute.
A nebo podobný princip jako se už používá například u detekce kompromitovaných hesel na háveibenpávnet: někdo chytřejší určitě napíše jak se tomuto principu říká : místo toho aby se klient ptal zde heslo (konrétní co mě zajimá 'AH1944') se zeptá na balík dat [abcd,xyz999,AH1944,blabla,ccc3] a na klientu odpovědi tuto vatu ignoruje
Nebo tušim featura toru "fake pakety" , že do provozu se přidají vymŠlené pakety navíc pro zmatení nepřitele. Odhaduji nevýhoda: zbytečná zátěž
Nevím, zda se to dá aplikovat na IM
-
Mam dojem, ze jsem slysel ze neco takoveho resi zion...
Zpravy jsou zasifrovany a pribaleny jako metadata k mikrotransakcim na blockchainu...
Klient si rozbali a odsifruje ty co potrebuje...
Vic nevim...
Ani jak dobre to funguje... ani jestli to tak porad je...
-
Rozhodně nic s centrálním servem / servery. Ideálu se v tomhle dost blíží P2P sítě jako Tox.
Ak sa bavime o tomto probleme, a neriesime kompromitaciu servera, tak centralny klient nevadi.
A co bitchute.
A nebo podobný princip jako se už používá například u detekce kompromitovaných hesel na háveibenpávnet: někdo chytřejší určitě napíše jak se tomuto principu říká : místo toho aby se klient ptal zde heslo (konrétní co mě zajimá 'AH1944') se zeptá na balík dat [abcd,xyz999,AH1944,blabla,ccc3] a na klientu odpovědi tuto vatu ignoruje
Nebo tušim featura toru "fake pakety" , že do provozu se přidají vymŠlené pakety navíc pro zmatení nepřitele. Odhaduji nevýhoda: zbytečná zátěž
Nevím, zda se to dá aplikovat na IM
Viem co myslite, ale to asi nepomoze, lebo ked na priatu spravu odpoviete, tak odpoviete len na jednu a ta druha strana tiez. Z toho ide dost dobre odhadnut, ze spolu komunikujete aj ked k sebe stahujete hromadu balastu. Podobne to bude s falosnymi spravami, viete ich detekovat, tak, ze primajuca strana na neodpovie.
Pre to by ma zaujimalo, ci tento problem uz niekto neriesil.
-
Pre to by ma zaujimalo, ci tento problem uz niekto neriesil.
Samozřejmě, že řešil. I v offline světě. Přečtěte si nějaký špionážní román.. mrtvé schránky, inzeráty, moderněji třeba internetová fóra, několik postupných spojek atd. Ty principy anonymizace se v online světě až tak neliší.
Pokud věříte serveru, tak nepřítel uvidí jen, že komunikujete se serverem, stejně jako mnoho dalších lidí. Ale zašifrovaný obsah zpráv neuvidí. Tj ani hlavičky. Takže nepozná kdo se baví s kým. Případně ten důvěryhodný server může být jen endpoint pro privátní VPN. Tam už pozná jen, že posíláte nějaký traffic. Ale nepozná komu.
Zobecněním VPN ve VPN (protože nevěříte ani serveru) a více postupných anonymizačních kroků je ten Tor.
Musíte mít nějaký nenápadný "telefonní seznam". Vy pošlete šifrovanou zprávu do sítě a ona po trojím přebalení někde vyplave. Ideálně není jak ze vstupu do Toru poznat kam jste ji poslal a stejně tak není na výstupu poznat kdo ji poslal. Interní metadata jsou šifrovaná a nečitelná.
Implementací může být více, ten zmíněný Tox je jedna z nich: https://tox.chat/
-
Napr Briar umi plne offline mod, tzn posles postovnim holubem zpravu (stick/flash), druha strana vlozi, precte, odpovi, posle zpet.
Tos ale asi nechtel slyset :) imo jestli je tvuj threat model akter s moznosti celosvetove monitorovat sit, tak hodne stesti.
V opacnym pripade jsou veci jako Briar / Simplex / Cwtch a podobny na slusne urovni (!= totalne anonymni, na internetu nic takovyho neexistuje). Toxu bych se vyhnul, je tam asi uz 5 let bezpecnostni problem, kterej nikdo neresi.
-
Ani jak dobre to funguje... ani jestli to tak porad je...
Už před desítkami let se to řešilo celkem triviálně, strany se dohodly na shared secretu, a potom někam veřejně (tehdy alt.binaries.pictures.*) posílali fotky se zasteganovanou zprávou.
Dneska by asi šlo použít něco jako 4chan, možná i klasickou socku, pokud mají oba dostatek sledujících, a socka neořezává/nekonvertuje.
-
Pokud věříte serveru, tak nepřítel uvidí jen, že komunikujete se serverem, stejně jako mnoho dalších lidí. Ale zašifrovaný obsah zpráv neuvidí. Tj ani hlavičky. Takže nepozná kdo se baví s kým. Případně ten důvěryhodný server může být jen endpoint pro privátní VPN. Tam už pozná jen, že posíláte nějaký traffic. Ale nepozná komu.
To nie je pravda, uvidi aj casovu korelaciu posielanych sprav, a to tu cely cas riesim, utocnik nemusi poznat obsah sprav aby vedel kto s kym kedy a ako casto, z coho sa da vytazil vela informacii.
Ani jak dobre to funguje... ani jestli to tak porad je...
Už před desítkami let se to řešilo celkem triviálně, strany se dohodly na shared secretu, a potom někam veřejně (tehdy alt.binaries.pictures.*) posílali fotky se zasteganovanou zprávou.
Dneska by asi šlo použít něco jako 4chan, možná i klasickou socku, pokud mají oba dostatek sledujících, a socka neořezává/nekonvertuje.
Len dnes kvoli komprimovanym formatom je steganografia velmi napadna, plus socialne siete obrazkom znizuju kvalitu, takze to tie data zosrotuje.
-
Tak este raz, casovu korelaciu neuvidi, ak obe strany posielaju na IM server ovela viac sprav, ako je ich realna komunikacia. Vyssie boli naznacene protokoly aj laicke sposoby ako to dosiahnut. Pridam aj ja jeden konkretny - ak maju obe strany napr. XMPP kecalek, kde je chranene samotne spojenie (utocnik nevidi plaintext) tak je mozne do neho kazdych 5-10-20-random sekund posielat random balast, ktory moze ist na neexistujucu adresu alebo nahodne - obcas aj prijemcovi. Tym padom casova korelacia nie je mozna, lebo z toho mnozstva sprav posielanych na server nevies urcit, co z toho ide konkretnemu prijemcovi na druhej strane.
-
To nie je pravda, uvidi aj casovu korelaciu posielanych sprav, a to tu cely cas riesim, utocnik nemusi poznat obsah sprav aby vedel kto s kym kedy a ako casto, z coho sa da vytazil vela informacii.
Neuvidí, protože jediné co uvidí jsou šifrované pakety na store & forward server, který používá mnoho lidí. Takže nikdy nepozná komu ta zpráva byla předána. Server ji klidně může zadržet do doby, než se druhá strana připojí a vyžádá si nové zprávy.
-
Tak este raz, ....
Takze zjevne nechapes zakladni principy.
Mam server, na server je pripojeno N klientu, na velikosti N vubec nezalezi. Sleduju veskerou komunikaci kazdeho jednoho klienta s tim serverem, a je mi uplne jedno, ze je sifrovana. Drive nebo pozdeji budu znat uplnou Ntici komunikacnich protistran = kdy, kdo s kym jak casto.
Balast si muzes poslat jaky chces, to ti prd pomuze. Ja vidim kdo ma na ten server otevrenou konexi a ke komu se zacnou sypat data kdyz je nekdo na server posle.
Nepomuze ti ani to, ze protistrana je offline, protoze kB prisel, kB odesel.
-
Asi by mohlo spňovat, ale nevrtal jsem se v tom PGP + P2P
https://github.com/TriLoi/Chat-PGP-P2P
-
Balast si muzes poslat jaky chces, to ti prd pomuze. Ja vidim kdo ma na ten server otevrenou konexi a ke komu se zacnou sypat data kdyz je nekdo na server posle.
Intenzivny balast to riesi.
Jednoduchy a neefektivny protokol: kazdy nejaky cas (mozno 1/100 sekundy) vygenerujem nahodny text a nahodnych prijimatelov (cca 1/100 siete). Prijimatel bude ignorovat spravy, ktore uspesne nedesifruje.
No a ked budem chciet poslat nieco lepsie, tak poslem namiesto balastu data zasifrovane klucom prijimatela. Vacsina ludi uvidi dalsiu davku balastu, ale s vysokou pravdepodobnostou dostane adresat spravu uz za 1 sekundu.
Neskaluje to, ale zrejme to moze fungovat.
-
Nepomuze ti ani to, ze protistrana je offline, protoze kB prisel, kB odesel.
Takhle to ovšem přesně vypadat nebude. Představte si třeba (šifrované) SMTP + IMAP.
1) Část té komunikace bude příkazová - autentizace, vypiš seznam zpráv, stáhni zprávy atd.
2) Stahované zprávy budou agregované do minimálního množství paketů
3) Šifrování udělá padding na velikost bloku
Takže jediné co uvidíte je sekvence paketů s velikostí dle MTU a pak jeden menší. Naprosto nepoznáte jestli to byla jedna zpráva nebo několik.
A to nemluvím o možnosti mít něco jako HTTP/2 multiplexing, kde se streamy prolínají v rámci jednoho (šifrovaného) přenosu.
-
Co se tyce TOR chat a obecne TORu, tak tor neskryva, kdo si s kym pise. TOR skryva skutecnou polohu (IP adresu) uzivatele, ktery pristupuje na bezny web (napr. seznam.cz) a v pripade serveru na TORu (*.onion) je skryta i identita serveru.
Alice s Bobem si pise krze nejaky IM messenger, nebo email. Oba pouzivaji TOR. Ale na serveru IM nebo emailovem serveru jde stale dohledat obsah komunikace (pokud neni end-to-end sifrovana). A samozrejme je videt, kdo kdy komu posila zpravu (uzivatelska jmena a cas). Neni videt poloha Boba a Alice.
Aby nebylo mozne videt obsah komunikace, tak je potreba zvolit klienta podporujiciho End To End sifrovani. V kombinaci s TORem jiz neni poznat kde se Bob a Alice nachazi, co si pisou. Ale je stale dohledatelne, kdy kdo komu pise plus delka zpravy.
Aby nebylo poznat, kdo si pise s kym, tak jedinou moznosti je klient, ktery posila vsechny zpravy vsem uzivatelum a jen vybrani uzivatele (Alice a Bob) maji ke zpravam klic. Pak neni poznat, ze Bob si pise s Alici, protoze kazdy dostava vsechny zpravy (narocne pri velkem poctu uzivatelu). Zpravy jsou sifrovane, tak neni mozne ani cist obsah zprav. A pokud Bob a Alice pouzivaji TOR, neni ani videt jejich lokace. Emailovych nebo IM klientu, kteri toto pouzivaji, je minimum.
Sam tusim, ze emailovy server na bazi jako bitcoin - bitmessage.ch by toto mel umet (posila vsechny zpravy vsem, jen dotycni maji klic, pristup prez TOR, End To End sifrovani ?) V pripade End To End sifrovani si nejsem jisty, a ani s tim rozesilanim vseho vsem si nejsem jisty. Registrace na bitmessage,ch jde prez TOR browser, ale vyzaduji sekundarni emailovou adresu, kam poslou pristupove udaje k nove vytvorene schrance.
-
Oprava:
https://bitmessage.ch/ jiz neni mozne pouzit. Kvuli velkemu poctu zneuziti a malemu poctu uzivatelu byl provoz ukoncen. Jineho klienta, ktery by umel zamaskovat i kdo s kym si pise neznam, skoda.
-
Mozo nieco ako https://github.com/number571/go-peer
-
Oprava:
https://bitmessage.ch/ jiz neni mozne pouzit. Kvuli velkemu poctu zneuziti a malemu poctu uzivatelu byl provoz ukoncen. Jineho klienta, ktery by umel zamaskovat i kdo s kym si pise neznam, skoda.
to by mohl byt zajimavy reklamni system :-)
takovy system by mel 2 funkce, rozesilani normalnich reklam do schranek a navic rozesilani skrytych zprav.
-
Co Retroshare?
is a Free and Open Source cross-platform, Friend-2-Friend and secure decentralised communication platform.
https://en.wikipedia.org/wiki/Retroshare
-
Existuje I2P, principiálne podobné Toru ale rieši niekoľko ďalších tu spomínaných nedostatkov.
- I2P spája userov/nodov pomocou skokov cez xy iných nodov rovnako ako Tor onion.
- Využíva P2P princíp kde každý user je nod, ktorý zároveň smeruje spojenia ostatných. Čiže okrem vlastných dát preposiela aj dáta iných.
- Na rozdiel od Toru je trasa pre odoslané dáta iná ako trasa pre prijaté dáta (každá trasa využíva onion preposielanie)
- Medzi nodmy vznikajú tzv. tunely na prenos dát (samozrejme šifrované) a umožňuje tieto tunely plniť náhodnými dátami.
- Na rozdiel od Toru nemá exit nody.
I2P je len transportná vrstva, ktorá sa používa rovnako ako na Tore pomocou proxy protokolu. S nejakým P2P messangerom by to malo spĺňať požadované...
-
Existuje I2P, principiálne podobné Toru ale rieši niekoľko ďalších tu spomínaných nedostatkov.
- I2P spája userov/nodov pomocou skokov cez xy iných nodov rovnako ako Tor onion.
- Využíva P2P princíp kde každý user je nod, ktorý zároveň smeruje spojenia ostatných. Čiže okrem vlastných dát preposiela aj dáta iných.
- Na rozdiel od Toru je trasa pre odoslané dáta iná ako trasa pre prijaté dáta (každá trasa využíva onion preposielanie)
- Medzi nodmy vznikajú tzv. tunely na prenos dát (samozrejme šifrované) a umožňuje tieto tunely plniť náhodnými dátami.
- Na rozdiel od Toru nemá exit nody.
I2P je len transportná vrstva, ktorá sa používa rovnako ako na Tore pomocou proxy protokolu. S nejakým P2P messangerom by to malo spĺňať požadované...
a] podle pravidel a na verejnych mistech
b] bez pravidel, pomoci F2F
Ja mam pocit ze to Retroshare muze splnovat podminky OP, ne na 100% protoze to ze
Bob, Carol, Ted a Alice mezi sebou komunikovali je podle mne ve smyslu P2P nemozne,
pokud jak uz nekdo psal nebudou komunikovat pomoci predem urcenych pravidel
a cist/posilat "zakodovane zpravy" na predem urcenych mistech (ta stenografie....nebo navsteva
verejneho fora a v nem umisteneho kodu [html, php, python etc...presne ve 1300 a prvni Patek v mesici
a potom o hodinu a den pozdeji a nebo aby tam byla trocha entropie podle nejakych jinych pravidel .....] )
F2F (Friend 2 Friend) kde Bob, Carol, Ted a Alice komunikuji, ale nikdo nevi kdo presne
z nich s kym umoznuje Retroshare:
While Retroshare's encryption makes it virtually impossible for an ISP or another external observer to know what one is downloading or uploading, this limitation does not apply to members of the user's Retroshare circle of trust; adding untrusted people to it may be a potential risk.
-
A jeste trochu z jineho uhlu puhledu na danou otazku OP je treba
"AI-guided Traffic Analysis (DAITA)"
na blogu krtka o tom nedavno vysel zajimavy clanek
http://o54hon2e2vj6c7m3aqqu6uyece65by3vgoxxhlqlsvkmacw6a7m7kiad.onion/en/blog/introducing-defense-against-ai-guided-traffic-analysis-daita