No me zaujalo, ze u toho otr je prave podepisovani povazovano za bezpecnostni riziko – v pripade, ze by byly pozdeji kompromitovany klice, tak lze cloveku prokazat predchozi ‚nekale rozhovory‘.
Tudiz to nejak resej a prijde mi to jako celkem zasadni myslenka.
Ale koukal jsem na to jen zbezne…nekdo by proste mohl udelat pekne obrazky a clanek ;)
Já myslím, že OTR staví na tom, že moje přání není ověřit moji identitu tak, abych prokazoval, že to píšu skutečně já. Pouze anonymně komunikovat. Oproti jiných řešením je to opravdu rozdíl v přístupu.
Podle mě ovšem, právě proto, to nelze brát jako seriózní zabezpečení. Protistrana se nijak neprokazuje a kryptograficky nepotvrzuje, kdo vlastně je (by design). Prostě pokud najednou začnete komunikovat a nepotřebujete ani klíče, ani certifikáty. Asymetrická kryptografie ale certifikáty v nějaké formě existuje, aby na ni nefungoval man-in-the-middle. Tohle myslím OTR neošetřuje úplně dokonale (a proto je tak oblíbený :)
TOHLE JE DOCELA DULEZITE. Hodne lidi si to neuvedomuje, ale je to fakt dulezite. V podstate se da rict, ze OTR nechrani proti odposlouchavani na uzlech kudy zprava prochazi. Dokonce Vas muzou v klidu odposlouchavat vsechny servery po ceste. Takze jeho uroven zabezpeceni neni o moc vetsi, nez bezne zabezpeceni Jabberu. Ma to jenom vyhodu u siti, kde jde text v nezasifrovane podobe.
„odepisovani povazovano za bezpecnostni riziko – v pripade, ze by byly pozdeji kompromitovany klice, tak lze cloveku prokazat predchozi ‚nekale rozhovory‘“
Nechápu, co tím myslíte. Elektronický podpis zastává bezpečnostní funkci nepopiratelnosti, takže už z principu jeho existence nemůže uživatel popřít zprávy, které podepsal svojim klíčem.
Nebo pokud to myslíte tak, že útočník získá můj keypair, napíše nějaký blackmail, podepíše ho mojim ukradeným klíčem a ušije tak na mě boudu, tak to se řeší revokací klíčů (pokud tedy zjistím, že mi je někdo ukradl). Ale proti tomu je jediná ochrana – dávat si majzla.
Pokud to chápu v obou případech špatně, tak to prosím rozveďte.
Cele PKI mi pride trochu odveci. Hlavne samotny proces podpisovania pretoze je ciastocne zalozeny na SW. Dokonca neverim ani HW podpisovackam. Pretoze hash pocita SW alebo ho posiela do HW. To ale neviem skontrolovat. Ak poslem nieco na podpis a tento SW tam posle podhodeny subor nemam to ako zistit. Neviem sa s tym psychicky vysporiadat.
Pokial toto niekto nevyriesi (napr. zobrazenim hashe na display podpisovacky, …) nebudem nikdy nic podpisovat elektronicky.
Zkuste mrknout, co o tom píšou na http://www.cypherpunks.ca/otr/
Oni si opravdu zakládají na tom, že zpětně můžu popřít všechno, co jsem napsal. Elektronicky podepsaná ta komunikace není záměrně. K čemu přesně je potřeba taková vlastnost nevím, ale OTR to prostě řeší takto. Jestli to je slabina nebo ne, záleží asi dost na způsobu použití.
Nebo jsem to nepochopil já, to je také možné, si to nastudujte v originále, mají tam popsaný i algoritmus.
No, to že má nějaký XEP Type: Historical neznamená nic. Položka Status je zajímavější pokud obsahuje takové hodnoty jako „Active“,„Experimental“,„Draft“. No a jak to tak vypadá tak XTLS nemá status ani „Experimental“ tudíž ho nemá kdo implementovat. A co se týče XEP-0027, tak ten je funkční a snad i implementovaný většinou klientů.
Pouzivam Gajim, ale nepouzivam GPG, no napriek tomu pri pisani mi ukazuje
Táto relácia je šifrovaná a BUDE zaznamenaná.
A ked sa kontakt odhlasi mam tam : E2E šifrovanie zakázané
Ked si dam detaily tak vidim: your chat session with … is encrypted.
This session's Authentication String is : …
Potrebujem este GPG ci nie ?
Tohle není úplně pravda. Gajim jako jediný (mě známý) klient má implementováno rozšíření http://xmpp.org/extensions/xep-0116.html, které ve výchozí konfiguraci taky používá. Pokud se ptá na autentizační řetězec (běžně je tohle zapnuté, pokud se baví gajim s gajimem), je to právě tohle rozšíření. Rozšíření nebylo zrovna triviální, a později se od něj ustoupilo. Jiný klient jej bude implementovat docela těžko.
S GPG tohle samotné nemá mnoho společného, rozhodně to nepoužívá PGP klíče. To Gajim umí taky, jak je popisované v článku i pro komunikaci se Psi. Nicméně jako výchozí mezi sebou používá encrypted sessions, protože to nevyžaduje explicitní přiřazení klíčů.
S bezpečnou komunikací end-to-end je to trochu blbé, protože i přímé spojení nakonec odpískali. Ono asi nakonec zůstane u toho, že nejjednodušší zabezpečení je mít vlastní server a komunikovat pouze na něm, potom nepotřebuju takové vychytávky, jako uvnitř šifrované komunikace šifrovat ještě jednu komunikaci. Nebo jsou lidi nedostatečně paranoidní. Nebo nám to válcuje OTR, které sice není kdovíjak geniální, ale je v existující knihovně, stačí jej stáhnout a naháčkovat na klienta. Těch, co by chtěli vymýšlet, psát a ladit celé nové řešení, není mnoho :-(