IM protokol maskující, kdo s kým píše

[Martin Sivák]

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.

[Reklama]

[jjrsk]

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.

[Hafraan]

Asi by mohlo spňovat, ale nevrtal jsem se v tom PGP + P2P

https://github.com/TriLoi/Chat-PGP-P2P

[branchman]

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.

[Martin Sivák]

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.

[Reklama]

[Gtor]

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.

[Gtor]

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.

[petersveter]

Mozo nieco ako https://github.com/number571/go-peer

[ogdru6jahad]

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.

[Jigdo]

Co Retroshare?

is a Free and Open Source cross-platform, Friend-2-Friend and secure decentralised communication platform.
https://en.wikipedia.org/wiki/Retroshare

[Daevid]

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é...

[Jigdo]

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.

[Jigdo]

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