Zasílání zpráv mimo záznam

Aktuální verze stránky ještě nebyla zkontrolována zkušenými přispěvateli a může se výrazně lišit od verze recenzované 28. května 2018; kontroly vyžadují 7 úprav .

Off-the-Record Messaging (OTR) je  kryptografický protokol pro systémy rychlého zasílání zpráv, který v roce 2004 vytvořili Nikita Borisov a Ian Goldberg . 

Autoři vytvořili knihovnu distribuovanou pod licencí GNU Lesser GPL , která se používá k podpoře OTR klientů systémů pro rychlé zasílání zpráv. Také na základě této knihovny autoři vytvořili plugin pro Pidgin .

EFF doporučuje použití OTR pro odposlechy [ 1] .

Historie

První verzi protokolu OTR a jeho implementaci představili v roce 2004 Nikita Borisov a Ian Goldberg [2] [3] . V roce 2005 byl zveřejněn útok na první verzi protokolu OTR a navržen revidovaný autentizační protokol [4] . V témže roce představili vývojáři OTR druhou verzi protokolu s opravou autentizačního protokolu a dále jej vylepšili [5] .

V roce 2007 Olivier Goffart zveřejnil modul mod_otr  [6] pro server ejabberd , který umožňuje automatické útoky typu man-in-the-middle proti uživatelům OTR, kteří si navzájem neověřují otisky veřejného klíče. Vývojáři pak vylepšili OTR pomocí řešení Socialist Millionaire , které umožňuje dvěma uživatelům autentizaci bez výměny klíčů nebo otisků prstů, pokud znají sdílené tajemství [7] .  

Základní vlastnosti protokolu

Protokol OTR byl vyvinut za účelem zajištění soukromí jednání, podobně jako jednání bez použití telekomunikací [8] [9] . Za tímto účelem byly do vyvinutého protokolu předloženy následující požadavky:

Některé z těchto funkcí jsou implementovány v systémech jako PGP a Trillian SecureIM. OTR se liší v tom, že implementuje všechny tyto funkce v jediném protokolu [10] .

Klíčová dohoda

Chcete-li odesílat zprávy pomocí OTR, musí účastníci protokolu vytvořit sdílený tajný klíč. K tomu se používá protokol Authenticated Key Exchange ,  založený na protokolu Diffie-Hellman [11] .

Na začátku protokolu účastníci používají protokol Diffie-Hellman k vytvoření tajného klíče potřebného k přenosu první zprávy. Členové A a B si vyberou prvočíslo a generátor skupin . A vybere náhodné číslo a pošle B výsledek výpočtu . B vybere náhodné číslo a pošle A výsledek výpočtu . Účastníci pak používají sdílený efemérní klíč , kde  je kryptografická hashovací funkce SHA-1 [12] .

Obnovení klíčů

Aby bylo zajištěno dokonalé dopředné utajení , uživatelé během výměny zpráv neustále obnovují klíč [13] [14] . Když je odeslána první zpráva, jedna ze stran (například strana A) zašifruje zprávu pomocí funkce šifrování s klíčem , vybere náhodné číslo a pošle B dvojici hodnot . Klíč se používá k zašifrování další zprávy . V budoucnu s každou zprávou A změní číslo a B změní číslo a klíč se aktualizuje.

V praxi se zprávy nedostanou okamžitě, takže po odeslání zprávy z A do B a aktualizaci klíče na straně A může A stále přijímat zprávu od B zašifrovanou starým klíčem [15] . Účastník A si může být jistý, že B aktualizoval klíč pouze tehdy, když obdrží od B zprávu zašifrovanou novým klíčem. Proto A uchovává dostatek starých klíčů, aby mohl dešifrovat všechny zprávy, které ještě nedorazily. Aby byly klíče aktualizovány dostatečně často, strana, která nemá žádné zprávy k odeslání, čas od času posílá prázdné zprávy [16] .

Autoři článku „Secure Off-the-Record Messaging“ kritizovali schéma obnovy klíče používané v OTR, protože neposkytuje dodatečné zabezpečení [17] . V případě kompromitace dosud používaného efemérního klíče tedy strana provádějící útok typu man-in-the-middle bude moci upravit všechny následující zprávy a používané efemérní klíče [18] . Také použití protokolu Diffie-Hellman může vyžadovat značné zdroje (například pro zařízení napájená bateriemi) [19] . Místo toho bylo navrženo použít stejné schéma jako pro klíč , nebo výpočetně méně náročné schéma založené na hashování [20] .

Autentizace klíče

Autentizace všech dočasných klíčů kromě , se provádí společně s autentizací zprávy a je popsána dále [21] . K autentizaci klíče se používají dlouhodobé klíče . První verze OTR používala nezabezpečené autentizační schéma, které bylo následně změněno [22] .

Původní verze protokolu

V první verzi protokolu OTR strany podepisují příslušné zprávy protokolu Diffie-Hellman [23] k ověření počátečního klíče . Také v těchto zprávách si strany předávají své dlouhodobé veřejné klíče.

Zde jsou  digitální podpisy a a  veřejné klíče stran A a B.

Tato verze protokolu obsahuje známou zranitelnost [24] [25] . Strana E, která provádí útok typu man-in-the-middle , se může autentizovat se stranami A a B současně, přičemž předstírá, že je jednou ze stran (například B) jako druhá strana (například A) , Jak je ukázáno níže.

Poté E nemůže číst zprávy, protože jsou zašifrovány klíčem známým pouze A a B, ale B si myslí, že mluví s E, ačkoli ve skutečnosti mluví s A [26] .

Při implementaci první verze protokolu OTR byly zvažovány bezpečnější protokoly, jako je SKEME , ale místo toho byl implementován proprietární protokol, jak je popsáno výše [27] .

Druhá verze protokolu

Autoři článku Secure Off-the-Record Messaging navrhli změnit protokol pro vyjednávání a ověřování klíčů na některý z již známých protokolů jako SIGMA , SKEME a HMQV [28] . Také v těchto zprávách si strany předávají své dlouhodobé veřejné klíče.

Varianta protokolu SIGMA , nazvaná SIGMA-R, funguje následovně [29] :

Zde A a B jsou identifikátory a  jsou digitální podpisy a  jsou veřejnými klíči stran A a B, v tomto pořadí, a  jsou kryptografickou hashovací funkcí.

Autoři OTR použili modifikaci protokolu SIGMA ve druhé verzi OTR [30] . Ve srovnání s navrhovaným protokolem SIGMA vývojáři OTR ochránili veřejné klíče před pasivním útokem (odposlechem). Za tímto účelem jsou veřejné klíče přenášeny přes zabezpečený kanál vytvořený pomocí protokolu Diffie-Hellman [31] . Také modifikace protokolu SIGMA používaného v OTR je komplikovaná kvůli omezení velikosti zprávy v některých protokolech ( například ]]32[)IRC .

Ověření zprávy

Na rozdíl od systémů, jako je PGP , OTR nepoužívá digitální podpisy k autentizaci zpráv, protože neposkytují možnosti odmítnutí autentizace [36] . Místo toho se používá HMAC [37] .

Pro autentizaci zprávy se používá klíč K, získaný hašováním klíče použitého k zašifrování zprávy [38] .

Když strana A pošle zprávu M jiné straně B, odešle spolu se zprávou hodnotu veřejného klíče HMAC(M, K) [39] . Strana B po přijetí zprávy může také vypočítat HMAC(M, K). Pokud se shoduje s přijatou hodnotou, pak strana B ví, že zprávu odeslala buď strana A nebo strana B, ale protože strana B ví, že zprávu neodeslala, může si být jistá, že zpráva byla skutečně odeslána stranou. A Současně použití HMAC poskytuje popření: ani odhalením klíče K nemůže B prokázat třetí straně, že zpráva byla odeslána stranou A. Zpráva může být také zfalšována stranou B a kteroukoli stranou, která ví klíč K.

Odhalení autentizačních klíčů

Klíče používané pro šifrování jsou neustále aktualizovány , jak je popsáno výše . Protože klíče používané pro autentizaci jsou získávány hašováním klíčů používaných pro šifrování, jsou také aktualizovány.

Staré klíče, které již nebudou používány, mohou být zničeny. Ale autentizační klíče mohou být také nejen zničeny, ale také vyzrazeny. Autoři OTR přidali prozrazení starého klíče: starý autentizační klíč je odeslán spolu se zprávou, pokud je známo, že již nebude používán [40] . Toto rozhodnutí je vysvětleno požadavky na popření protokolu OTR [41] [42] .

Práce Secure Off-the-Record Messaging poukazuje na to, že prozrazení autentizačních klíčů zbytečně komplikuje protokol a může být negativně nezabezpečené jako nestandardní metoda pro kryptografii [43] . Autor protokolu TextSecure založeného na OTR, alias Moxie Marlinspike , také poukazuje na složitost a neefektivnost odhalování autentizačních klíčů pro zajištění popření [44] .

Šifrování zpráv

K šifrování zpráv se používá algoritmus AES v režimu čítače [45] . Použití proudové šifry vytvořené tímto způsobem poskytuje tvárné šifrování .  To znamená, že kdokoli, kdo zachytí zprávu, bude moci selektivně změnit jakékoli bity ve zprávě. Zejména, jakmile se zpráva stane známou, může být změněna na jakoukoli jinou zprávu stejné délky [46] .

Aby bylo zajištěno, že je šifrování popřeno, je vyžadováno kontroverzní šifrování [47] . S pochybným šifrováním mohou účastníci protokolu OTR tvrdit, že některá z přenášených zpráv byla pozměněna třetí stranou.

OTR pro více hráčů

Protokol OTR je navržen pro použití pouze dvěma stranami. Nelze jej tedy použít v kanálech IRC , konferencích XMPP atd.

OTR nelze jednoduše rozšířit na případ více reproduktorů kvůli použitým kryptografickým primitivům. Například ověřovací kódy zpráv neposkytují autentizaci zdroje zpráv v případě více uživatelů [48] .

Existují rozšíření protokolu, která umožňují používat protokol více uživatelům [49] [50] [51] .

Jedno rozšíření protokolu OTR nazvané GOTR (Group OTR) je založeno na myšlence vytvoření „virtuálního serveru“ [52] . Jeden z účastníků je jmenován jako „virtuální server“, vyměňuje si klíče s ostatními účastníky a v budoucnu se přes něj zasílají všechny zprávy mezi účastníky konference. Nevýhodou protokolu GOTR je, že „virtuální server“ může měnit obsah zpráv, přidávat a mazat zprávy, takže mu musí věřit všichni účastníci konference [53] .

Později Ian Goldberg a další autoři navrhli protokol mpOTR [51] . Na rozdíl od protokolu GOTR protokol mpOTR funguje bez vyhrazeného centrálního serveru [54] .

OTR implementace

libotr
Typ Knihovna
Autor Ian Goldberg [d] a Nikita Borisov [d]
Vývojář Vývojový tým OTR
Zapsáno v C
Hardwarová platforma multiplatformní
Nejnovější verze 4.0.2 ( 9. března 2016 )
Stát Aktuální
Licence GNU Lesser General Public License verze 2 [55]
webová stránka otr.cypherpunks.ca/index…

Hlavní implementací OTR je knihovna libotr vytvořená vývojovým týmem OTR. Na jeho základě stejní vývojáři vytvořili plugin pro klienta Pidgin , který umožňuje používat OTR s kterýmkoli z protokolů podporovaných tímto klientem. Existují také implementace protokolu v Go , Java , JavaScript , Python , Scheme [56] .

Podpora Messengeru

Vestavěná podpora

Následující klienti mají nativní podporu protokolu OTR [57] .

Pomocí pluginu

Proxy

Pro klienty, kteří podporují protokol AIM / ICQ , vývojový tým OTR vyvinul balíček otrproxy, což je lokální proxy server [71] . Umožnil použití OTR u klientů, kteří neměli nativní podporu OTR. V současné době tento balíček není podporován, vývojáři doporučují používat klienty s podporou OTR.

Poznámky

  1. ↑ Sebeobrana sledování: Instant Messaging (IM) . - "Abyste ochránili zprávy před zachycením, když cestují po síti, musíte použít šifrování. Naštěstí existuje vynikající systém šifrování okamžitých zpráv zvaný OTR (Off The Record).“. Získáno 22. října 2013. Archivováno z originálu 13. října 2013.
  2. ↑ borisov2004off, 2004 .
  3. ↑ impauth, 2007 , 2.1 Původní protokol OTR, str. 42: „Původní protokol OTR byl předložen Borisovem, Goldbergem a Brewerem v roce 2004“.
  4. ↑ di2005secure, 2005 .
  5. ↑ impauth, 2007 , 2.3 OTR verze 2, str. 43: "OTR verze 2 byla vydána v roce 2005. Největší změnou ve verzi 2 bylo přepracování původní autentizované výměny klíčů (AKE).".
  6. ↑ mod_otr . Získáno 20. října 2013. Archivováno z originálu 29. září 2013.
  7. ↑ impauth, 2007 , 4. Protokol socialistických milionářů, str. 44.
  8. ↑ impauth, 2007 , 2.1 Původní protokol OTR, str. 41: "Původní protokol OTR představili Borisov, Goldberg a Brewer v roce 2004. Byl motivován myšlenkou dvou lidí, říkají Alice a Bob, konverzovat tváří v tvář v soukromé místnosti."
  9. ↑ goldberg2009multi, 2009 , 1. Motivace, str. 359: "I když to může být za určitých okolností proveditelné, odchyluje se to od původního cíle OTR, kterým je napodobování soukromých rozhovorů."
  10. ↑ borisov2004off, 2004 , 1. Úvod, str. 77: "Nicméně žádný z mechanismů v současnosti používaných pro sociální komunikaci nemá všechny tyto vlastnosti."
  11. ↑ impauth, 2007 , 2.1 Původní protokol OTR, str. 42: "Pro začátek používá OTR výměnu klíčů Diffie-Hellman (DH) k vytvoření sdíleného tajemství mezi Alicí a Bobem."
  12. ↑ borisov2004off, 2004 , 4.1 Šifrování, str. 80.
  13. ↑ borisov2004off, 2004 , 3.1 Dokonalé dopředné utajení, str. 78: "Tento problém obcházíme používáním krátkodobých šifrovacích/dešifrovacích klíčů, které jsou generovány podle potřeby a po použití zahozeny."
  14. ↑ impauth, 2007 , 2.1 Původní protokol OTR, str. 42: „V tuto chvíli si Alice a Bob mohou začít posílat šifrované zprávy. Aby se omezilo množství informací, které jsou kompromitovány, pokud sdílený klíč určí protivník, Alice a Bob znovu klíčují tak často, jak je to možné. ... Tento postup dává OTR vlastnost dokonalého dopředného utajení (PFS), která zajišťuje, že budoucí klíčové kompromisy nemohou odhalit obsah starých zpráv.".
  15. ↑ borisov2004off, 2004 , 4.2 Zapomenutí klíčů, str. 80: "Nicméně, protože protokoly zasílání zpráv jsou obvykle asynchronní, je možné, že stále existuje zpráva od Boba, která byla zašifrována pomocí předchozího klíče."
  16. ↑ borisov2004off, 2004 , 4.2 Zapomenutí klíčů, str. 81: "K vyřešení tohoto problému by měl Bob pravidelně posílat prázdnou zprávu potvrzující přijetí nového klíče od Alice."
  17. ↑ di2005secure, 2005 , 6.3 O osvěžení klíče, str. 89: "Hodnota provádění výměny klíčů DH s každou zprávou, kde autentizace závisí na předchozím sdíleném klíči, má tedy omezenou hodnotu.".
  18. ↑ di2005secure, 2005 , 6.3 O osvěžení klíče, str. 88: "Upozorňujeme však, že pokud se protivník naučí aktuální pomíjivý klíč, budoucí zprávy mohou být zcela kompromitovány."
  19. ↑ di2005secure, 2005 , 6.3 O osvěžení klíče, str. 89: "To platí ještě více s ohledem na výpočetní náklady na výměnu DH."
  20. ↑ di2005secure, 2005 , Navrhujeme tedy, že OTR bude mít lepší celkovou bezpečnost, když bude protokol AKE spouštět v pravidelných intervalech. Pokud je požadován jemnější osvěžující mechanismus pro účely dopředného utajení, pak lze použít lehčí, ale výkonný mechanismus, jako je odvození nových klíčů (možná na základě zprávy, pokud je to žádoucí) jednosměrným hašováním. předchozí klíč., str. 89.
  21. ↑ borisov2004off, 2004 , 4.3 Autentizace, str. 81: „Potřebujeme pouze použít digitální podpis na počáteční výměně klíčů. Při dalších výměnách klíčů používáme MACy k ověření nového klíče pomocí starého, známého a autentického sdíleného tajemství.".
  22. ↑ impauth, 2007 .
  23. ↑ borisov2004off, 2004 , 4.3 Autentizace, str. 81: „Šifrovací klíč je sám o sobě výsledkem hashe sdíleného tajemství Diffie-Hellman, které je také třeba nějakým způsobem ověřit. Toho dosáhneme digitálním podpisem počáteční výměny Diffie-Hellman."
  24. ↑ di2005secure, 2005 , 3.1 Selhání ověření, str. 84.
  25. ↑ impauth, 2007 , 2.2 Útok na OTR verze 1, str. 42.
  26. ↑ borisov2004off, 2004 , 2.2 Útok na OTR verze 1, str. 42: "Tento útok umožňuje protivníkovi Evě zasahovat do počáteční výměny klíčů takovým způsobem, že Alice a Bob na konci protokolu stále dosáhnou stejného klíče, ale Alice věří, že mluví s Bobem, zatímco Bob věří, že mluví on." k Evě."
  27. ↑ borisov2004off, 2004 , 7. Související práce, str. 83: "Pokud je požadována anonymita, lze v našem protokolu místo podepsané výměny klíčů Diffie-Hellman použít buď SKEME nebo Abadiho soukromé ověřování."
  28. ↑ di2005secure, 2005 , 4. Building A Sound AKE For OTR, str. 85.
  29. ↑ di2005secure, 2005 , 4.1 SIGMA, str. 85.
  30. ↑ impauth, 2007 , 2.3 OTR verze 2, str. 43: „Největší změnou ve verzi 2 bylo přepracování původní výměny ověřených klíčů (AKE). V reakci na výše uvedený útok byl AKE změněn na variantu SIGMA, jak bylo navrženo.".
  31. ↑ impauth, 2007 , 2.3 OTR verze 2, str. 43: "Tam, kde byly dříve veřejné klíče zasílány jako čisté, jsou nyní šifrovány pomocí sdíleného tajemství DH."
  32. ↑ impauth, 2007 , 2.3 OTR verze 2, str. 43: "Účelem r ve výše uvedených krocích je splnit technické omezení: mnoho IM protokolů vynucuje maximální velikost zpráv.".
  33. ↑ impauth, 2007 , 2.3 OTR verze 2, str. 43.
  34. ↑ OTRv2 .
  35. ↑ OTRv3 .
  36. ↑ borisov2004off, 2004 , 3.2 Digitální podpisy a nepopiratelnost, str. 79: "Z tohoto důvodu nikdy nepoužíváme digitální podpis k prokázání Alicina autorství jakékoli zprávy."
  37. ↑ borisov2004off, 2004 , 3.3 MAC a nepopiratelnost, str. 79.
  38. ↑ impauth, 2007 , 2.1 Původní protokol OTR, str. 42: "Použitý MAC klíč je hash dešifrovacího klíče pro tuto zprávu."
  39. ↑ borisov2004off, 2004 , 3.3 MAC a nepopiratelnost, str. 79: "Alice používá svou kopii MAC klíče k výpočtu MAC své zprávy a posílá tuto MAC spolu se svou zprávou v zabezpečeném přenosu."
  40. ↑ borisov2004off, 2004 , 4.4 Odhalení MAC klíčů, str. 81.
  41. ↑ borisov2004off, 2004 , 4.4 Odhalení MAC klíčů, str. 81: "Všimněte si, čeho se tím dosáhlo: Bob se již nemusí spoléhat na tento klíč, protože již zkontroloval všechny zprávy ověřené tímto klíčem. Nyní však může kdokoli vytvářet libovolné zprávy, které mají tento MAC klíč, a nikdo nemůže vyloučit žádnou konkrétní osobu jako potenciálního autora zprávy.".
  42. ↑ di2005secure, 2005 , 2.3 Šifrování a ověřování zpráv, str. 84: "Důvodem výše uvedených možností (tj. tvárné šifrování a odhalení MAC klíčů) je popření."
  43. ↑ di2005secure, 2005 , 6.1 Odmítatelnost symetrického šifrování, str. 88: „Za třetí, odhalení MAC klíčů přináší problémy s načasováním a synchronizací, které jsou potřeba k zabránění předčasnému odhalení. I když je to možné, vede to k větší složitosti systému. Zatímco výše uvedené úvahy mohou být do určité míry vnímány jako subjektivní, v další podkapitole ilustrujeme nebezpečí přidání nestandardních bezpečnostních technik.".
  44. ↑ Jednoduchost , omezení.
  45. ↑ di2005secure, 2005 , 2.3 Šifrování a ověřování zpráv, str. 83: "Zpráva je nejprve zašifrována pomocí AES v režimu čítače a poté je výsledný šifrovaný text autentizován pomocí HMAC (s hashovací funkcí SHA-1).".
  46. ↑ borisov2004off, 2004 , 3.4 Tvárné šifrování a falšovatelnost, str. 80: "Toto šifrování je tvárné, protože změna kteréhokoli bitu v šifrovém textu bude odpovídat změně odpovídajícího bitu v otevřeném textu. Konkrétně, pokud Eva dokáže uhodnout čistý text zprávy, může pak změnit šifrovaný text tak, aby se dešifroval na jakoukoli jinou zprávu stejné délky, aniž by znala klíč.".
  47. ↑ di2005secure, 2005 , Důvodem výše uvedených voleb (tj. tvárné šifrování a odhalení MAC klíčů) je popření. 84.
  48. ↑ goldberg2009multi, 2009 : „Například OTR používá k zajištění autenticity kódy pro ověřování zpráv (MAC). Zatímco pro dvě strany mohou MAC poskytovat mechanismus odmítnutí autentizace, MAC neposkytují autentizaci původu, pokud jsou používány více než dvěma stranami.".
  49. ↑ bian2007off, 2007 .
  50. ↑ bian2007public, 2007 .
  51. ↑ 1 2 goldberg2009multi, 2009 .
  52. ↑ bian2007off, 2007 , 3.1. Počáteční design, str. 81: "Hlavním konceptem naší implementace je vytvořit virtuální server, což je člen chatu doslova fungující jako server."
  53. ↑ goldberg2009multi, 2009 , 1. Motivace, str. 359: "Konečně, server musí být považován za čestný, protože nepoctivý server by mohl ohrozit důvěrnost a integritu všech zpráv odeslaných během chatu."
  54. ↑ goldberg2009multi, 2009 , 5. Závěr, str. 367: „Náš navrhovaný rámec pro komunikaci Off-the-Record s více stranami nezávisí na centrálním serveru; místo toho jsme vyvinuli model, který napodobuje typickou soukromou schůzku, kde si každý uživatel ověřuje ostatní účastníky sám za sebe."
  55. ↑ Zasílání zpráv mimo záznam . Získáno 10. listopadu 2013. Archivováno z originálu 17. srpna 2014.
  56. ↑ Knihovny, které podporují OTR . Získáno 10. listopadu 2013. Archivováno z originálu 10. listopadu 2013.
  57. ↑ https://otr.cypherpunks.ca/software.php Archivováno 10. listopadu 2013 v klientech Wayback Machine IM, kteří podporují zprávy Off-the-Record „out of the box“
  58. ↑ Získejte OTR pro práci s bitlbee . Získáno 10. listopadu 2013. Archivováno z originálu 20. listopadu 2013.
  59. ↑ OTR plugin . Získáno 6. září 2017. Archivováno z originálu 13. června 2019.
  60. ↑ Snímky Psi+
  61. ↑ OTR plugin . Získáno 23. dubna 2014. Archivováno z originálu 11. ledna 2016.
  62. ↑ Stručný popis . Získáno 23. dubna 2014. Archivováno z originálu 24. dubna 2014.
  63. ↑ Zdrojový kód Archivováno 17. května 2014.
  64. ↑ Jak je popsáno na oficiálních stránkách Archivováno 9. dubna 2022 na Wayback Machine
  65. ↑ Oficiální OTR plugin pro Gajim (downlink) . Získáno 6. září 2017. Archivováno z originálu 6. září 2017. 
  66. ↑ OTR plugin na Wiki . Získáno 6. září 2017. Archivováno z originálu 6. září 2017.
  67. ↑ Domovská stránka irssi-otr a xchat-otr . Získáno 10. listopadu 2013. Archivováno z originálu 10. listopadu 2013.
  68. ↑ OTR plugin pro Miranda IM Archivováno 13. května 2007.
  69. ↑ Další pluginy pro projekt Vacuum-IM . Získáno 24. října 2010. Archivováno z originálu dne 23. května 2011.
  70. ↑ Plugin Tkabber OTR archivován 11. března 2014.
  71. ↑ OTR localhost AIM proxy . Získáno 10. listopadu 2013. Archivováno z originálu 12. dubna 2018.

Literatura

Odkazy