Mesaje off-the-record

Versiunea actuală a paginii nu a fost încă revizuită de colaboratori experimentați și poate diferi semnificativ de versiunea revizuită pe 28 mai 2018; verificările necesită 7 modificări .

Off-the-Record Messaging (OTR) este  un protocol criptografic pentru sistemele de mesagerie instant creat în 2004 de Nikita Borisov și Ian Goldberg . 

Autorii au creat o bibliotecă distribuită sub licența GNU Lesser GPL , folosită pentru a sprijini clienții OTR ai sistemelor de mesagerie instantanee. De asemenea, pe baza acestei biblioteci, autorii au creat un plugin pentru Pidgin .

EFF recomandă utilizarea OTR pentru interceptări [1] .

Istorie

Prima versiune a protocolului OTR și implementarea acestuia au fost prezentate în 2004 de Nikita Borisov și Ian Goldberg [2] [3] . În 2005, a fost publicat un atac asupra primei versiuni a protocolului OTR și a fost propus un protocol de autentificare revizuit [4] . În același an, dezvoltatorii OTR au introdus a doua versiune a protocolului cu corectarea protocolului de autentificare, îmbunătățindu-l și mai mult [5] .

În 2007, Olivier Goffart a publicat modulul mod_otr  [6] pentru serverul ejabberd , care permite atacuri automate de tip man-in-the-middle împotriva utilizatorilor OTR care nu își verifică reciproc amprentele cheii publice. Dezvoltatorii au îmbunătățit apoi OTR cu o soluție Socialist Millionaire care permite a doi utilizatori să se autentifice fără a schimba cheile sau amprentele lor, cu condiția să cunoască secretul partajat [7] .  

Proprietățile de bază ale protocolului

Protocolul OTR a fost dezvoltat pentru a asigura confidențialitatea negocierilor, similar negocierilor fără utilizarea telecomunicațiilor [8] [9] . În acest scop, protocolului elaborat au fost prezentate următoarele cerințe:

Unele dintre aceste caracteristici sunt implementate în sisteme precum PGP și Trillian SecureIM. OTR este diferit prin faptul că implementează toate aceste caracteristici într-un singur protocol [10] .

Acord cheie

Pentru a trimite mesaje folosind OTR, participanții la protocol trebuie să stabilească un secret partajat. Pentru aceasta se folosește protocolul Authenticated Key Exchange ,  bazat pe protocolul Diffie-Hellman [11] .

La începutul protocolului, participanții folosesc protocolul Diffie-Hellman pentru a stabili cheia secretă necesară transmiterii primului mesaj. Membrii A și B aleg un număr prim și un generator de grupe . A alege un număr aleator și trimite lui B rezultatul calculului . B alege un număr aleator și trimite lui A rezultatul calculului . Participanții folosesc apoi cheia efemeră partajată , unde  este funcția hash criptografică SHA-1 [12] .

Reînnoirea cheilor

Pentru a asigura secretul perfect , utilizatorii reînnoiesc constant cheia în timpul schimbului de mesaje [13] [14] . Când primul mesaj este transmis, una dintre părți (de exemplu, partea A) criptează mesajul folosind funcția de criptare cu o cheie , alege un număr aleator și îi trimite lui B o pereche de valori . Cheia este folosită pentru a cripta următorul mesaj . În viitor, cu fiecare mesaj, A schimbă numărul , iar B schimbă numărul , iar cheia este actualizată.

În practică, mesajele nu ajung instantaneu, așa că după ce a trimis un mesaj de la A la B și a actualizat cheia de pe partea lui A, A mai poate primi un mesaj de la B criptat cu vechea cheie [15] . Participantul A poate fi sigur că B a actualizat cheia doar atunci când primește de la B un mesaj criptat cu noua cheie. Prin urmare, A păstrează suficiente chei vechi pentru a putea decripta toate mesajele care nu au ajuns încă. Pentru a menține cheile suficient de des actualizate, partea care nu are mesaje de trimis trimite din când în când mesaje goale [16] .

Autorii articolului „Secure Off-the-Record Messaging” au criticat schema de reînnoire a cheilor utilizată în OTR, deoarece nu oferă securitate suplimentară [17] . Astfel, în cazul unui compromis al cheii efemere încă în uz , partea care efectuează atacul man-in-the-middle va putea modifica toate mesajele ulterioare și cheile efemere aflate în uz [18] . De asemenea, utilizarea protocolului Diffie-Hellman poate necesita resurse semnificative (de exemplu, pentru dispozitivele alimentate cu baterie) [19] . În schimb, s-a propus să se folosească aceeași schemă ca și pentru cheie , sau o schemă mai puțin solicitantă din punct de vedere computațional bazată pe hashing [20] .

Autentificare cheie

Autentificarea tuturor cheilor efemere , cu excepția , este efectuată împreună cu autentificarea mesajelor și este descrisă în continuare [21] . Cheile pe termen lung sunt folosite pentru autentificarea cheilor . Prima versiune a OTR a folosit o schemă de autentificare nesigură, care a fost ulterior modificată [22] .

Versiunea originală a protocolului

În prima versiune a protocolului OTR, părțile semnează mesajele corespunzătoare ale protocolului Diffie-Hellman [23] pentru a autentifica cheia inițială . Tot în aceste mesaje, părțile își transferă cheile publice pe termen lung.

Aici , și  sunt semnătura digitală și și  sunt cheile publice ale părților A și, respectiv, B.

Această versiune a protocolului conține o vulnerabilitate cunoscută [24] [25] . Partea E, care efectuează un atac de tip man-in-the-middle , se poate autentifica cu părțile A și B în același timp, pretinzând că este una dintre părți (de exemplu, B) ca cealaltă parte (de exemplu, A). , așa cum se arată mai jos.

După aceea, E nu poate citi mesajele, deoarece acestea sunt criptate cu o cheie cunoscută doar de A și B, dar B crede că vorbește cu E, deși de fapt vorbește cu A [26] .

Protocoale mai sigure precum SKEME au fost luate în considerare atunci când a fost implementată prima versiune a protocolului OTR, dar în schimb a fost implementat un protocol proprietar așa cum este descris mai sus [27] .

A doua versiune a protocolului

Autorii articolului Secure Off-the-Record Messaging au sugerat schimbarea protocolului de negociere și autentificare a cheilor la unul dintre protocoalele deja cunoscute precum SIGMA , SKEME și HMQV [28] . Tot în aceste mesaje, părțile își transferă cheile publice pe termen lung.

O variantă a protocolului SIGMA , numită SIGMA-R, funcționează după cum urmează [29] :

Aici A și B sunt identificatori și  sunt semnături digitale și  sunt cheile publice ale părților A și B, respectiv, și  este o funcție hash criptografică.

Autorii OTR au folosit o modificare a protocolului SIGMA în cea de-a doua versiune a OTR [30] . În comparație cu protocolul SIGMA propus, dezvoltatorii OTR au protejat cheile publice împotriva atacurilor pasive (interceptări). Pentru a face acest lucru, cheile publice sunt transmise pe un canal securizat stabilit folosind protocolul Diffie-Hellman [31] . De asemenea, modificarea protocolului SIGMA utilizat în OTR este complicată din cauza restricțiilor de dimensiune a mesajelor din unele protocoale ( de ]32[)IRC,exemplu .

Autentificare mesaj

Spre deosebire de sisteme precum PGP , OTR nu folosește semnături digitale pentru a autentifica mesajele, deoarece acestea nu oferă capabilități de autentificare refuzate [36] . În schimb, se folosește HMAC [37] .

Pentru autentificarea mesajelor se folosește cheia K, obținută prin hashing cheia folosită pentru criptarea mesajului [38] .

Când partea A trimite un mesaj M către o altă parte B, aceasta trimite valoarea cheii publice HMAC(M, K) [39] împreună cu mesajul . Partea B, la primirea mesajului, poate calcula, de asemenea, HMAC(M, K). Dacă se potrivește cu valoarea primită, atunci partea B știe că mesajul a fost transmis fie de partea A, fie de partea B, dar din moment ce partea B știe că nu a trimis mesajul, atunci poate fi sigur că mesajul a fost de fapt trimis de către parte. A În același timp, utilizarea HMAC oferă negație: chiar și prin dezvăluirea cheii K, B nu poate dovedi unei terțe părți că mesajul a fost trimis de partea A. Mesajul ar putea fi falsificat și de partea B și de orice parte care știe cheia K.

Dezvăluirea cheilor de autentificare

Cheile utilizate pentru criptare sunt actualizate în mod constant așa cum este descris mai sus . Deoarece cheile utilizate pentru autentificare sunt obținute prin hashing cheile utilizate pentru criptare, acestea sunt de asemenea actualizate.

Cheile vechi care nu vor mai fi folosite pot fi distruse. Dar cheile de autentificare pot fi, de asemenea, nu numai distruse, ci și dezvăluite. Autorii OTR au adăugat dezvăluirea cheii vechi: vechea cheie de autentificare este trimisă împreună cu mesajul dacă se știe că nu va mai fi folosită [40] . Această decizie se explică prin cerințele negării protocolului OTR [41] [42] .

Lucrarea Secure Off-the-Record Messaging subliniază că dezvăluirea cheilor de autentificare complică în mod inutil protocolul și poate fi negativ nesigură, ca metodă non-standard pentru criptografie [43] . Autorul protocolului TextSecure bazat pe OTR, alias Moxie Marlinspike , subliniază și complexitatea și ineficiența expunerii cheilor de autentificare pentru a asigura negarea [44] .

Criptarea mesajelor

Pentru a cripta mesajele, algoritmul AES este utilizat în modul contor [45] . Utilizarea unui cifr de flux construit în acest mod oferă o criptare maleabilă .  Aceasta înseamnă că oricine interceptează mesajul va putea schimba în mod selectiv orice biți din mesaj. În special, odată ce mesajul a devenit cunoscut, acesta poate fi schimbat cu orice alt mesaj de aceeași lungime [46] .

Criptarea controversată este necesară pentru a se asigura că criptarea este refuzată [47] . Cu o criptare discutabilă, participanții la protocolul OTR pot pretinde că oricare dintre mesajele transmise a fost alterat de o terță parte.

Multiplayer OTR

Protocolul OTR este conceput pentru a fi utilizat numai de două părți. Astfel, nu poate fi utilizat în canale IRC , conferințe XMPP etc.

OTR nu poate fi extins pur și simplu la cazul mai multor difuzoare datorită primitivelor criptografice utilizate. De exemplu, codurile de autentificare a mesajelor nu oferă autentificarea sursei de mesaje în cazul multi-utilizator [48] .

Există extensii ale protocolului care permit utilizatorilor multipli să utilizeze protocolul [49] [50] [51] .

O extensie a protocolului OTR numită GOTR (Group OTR) se bazează pe ideea creării unui „server virtual” [52] . Unul dintre participanți este desemnat ca „server virtual”, schimbă cheile cu alți participanți, iar în viitor, toate mesajele dintre participanții la conferință sunt trimise prin intermediul acestuia. Dezavantajul protocolului GOTR este că „serverul virtual” poate modifica conținutul mesajelor, poate adăuga și șterge mesaje, astfel încât toți participanții la conferință trebuie să aibă încredere în el [53] .

Mai târziu, Ian Goldberg și alți autori au propus protocolul mpOTR [51] . Spre deosebire de protocolul GOTR, protocolul mpOTR operează fără un server central dedicat [54] .

Implementări OTR

libotr
Tip de Bibliotecă
Autor Ian Goldberg [d] și Nikita Borisov [d]
Dezvoltator Echipa de dezvoltare OTR
Scris in C
Platformă hardware multiplatformă
ultima versiune 4.0.2 ( 9 martie 2016 )
Stat Real
Licență GNU Lesser General Public License versiunea 2 [55]
Site-ul web otr.cypherpunks.ca/index…

Principala implementare a OTR este biblioteca libotr creată de echipa de dezvoltare OTR. Pe baza acestuia, aceiași dezvoltatori au creat un plugin pentru clientul Pidgin care vă permite să utilizați OTR cu oricare dintre protocoalele acceptate de acest client. Există și implementări ale protocolului în Go , Java , JavaScript , Python , Scheme [56] .

Asistență Messenger

Suport încorporat

Următorii clienți au suport nativ pentru protocolul OTR [57] .

Folosind pluginul

Proxy

Pentru clienții care acceptă protocolul AIM / ICQ , echipa de dezvoltare OTR a dezvoltat pachetul otrproxy, care este un server proxy local [71] . A permis utilizarea OTR la clienții care nu aveau suport nativ OTR. Momentan acest pachet nu este acceptat, dezvoltatorii recomandă utilizarea clienților cu suport OTR.

Note

  1. Supraveghere Auto-apărare: Mesagerie instantanee (IM) . - „Pentru a proteja mesajele de interceptare în timp ce călătoresc prin rețea, trebuie să utilizați criptarea. Din fericire, există un excelent sistem de criptare a mesageriei instantanee numit OTR (Off The Record).”. Consultat la 22 octombrie 2013. Arhivat din original pe 13 octombrie 2013.
  2. borisov2004off, 2004 .
  3. impauth, 2007 , 2.1 Original OTR Protocol, p. 42: „Protocolul original OTR a fost prezentat de Borisov, Goldberg și Brewer în 2004”.
  4. di2005secure, 2005 .
  5. impauth, 2007 , 2.3 OTR versiunea 2, p. 43: „Versiunea 2 OTR a fost lansată în 2005. Cea mai mare schimbare în versiunea 2 a fost reelaborarea schimbului inițial de chei autentificate (AKE).”.
  6. mod_otr . Consultat la 20 octombrie 2013. Arhivat din original pe 29 septembrie 2013.
  7. impauth, 2007 , 4. Protocolul milionarilor socialişti, p. 44.
  8. impauth, 2007 , 2.1 Original OTR Protocol, p. 41: „Protocolul original OTR a fost prezentat de Borisov, Goldberg și Brewer în 2004. A fost motivat de ideea ca două persoane, spun Alice și Bob, să converseze față în față într-o cameră privată”.
  9. goldberg2009multi, 2009 , 1. Motivație, p. 359: „Deși acest lucru poate fi fezabil în anumite circumstanțe, se abate de la obiectivul original OTR, care este de a imita conversațiile private”.
  10. borisov2004off, 2004 , 1. Introducere, p. 77: „Totuși, niciunul dintre mecanismele utilizate în prezent pentru comunicațiile sociale nu are toate aceste proprietăți.”
  11. impauth, 2007 , 2.1 Original OTR Protocol, p. 42: „În primul rând, OTR folosește un schimb de chei Diffie-Hellman (DH) pentru a stabili un secret comun între Alice și Bob”.
  12. borisov2004off, 2004 , 4.1 Criptare, p. 80.
  13. borisov2004off, 2004 , 3.1 Secret forward perfect, p. 78: „Eludăm această problemă utilizând chei de criptare/decriptare de scurtă durată care sunt generate după cum este necesar și eliminate după utilizare.”
  14. impauth, 2007 , 2.1 Original OTR Protocol, p. 42: „În acest moment, Alice și Bob pot începe să-și trimită reciproc mesaje criptate. Pentru a limita cantitatea de informații care este compromisă dacă un adversar determină cheia partajată, Alice și Bob reintroduc cheia cât mai des posibil. ... Această procedură conferă OTR proprietatea de secret forward perfect (PFS), asigurând că viitoarele compromisuri cheie nu pot dezvălui conținutul mesajelor vechi.”.
  15. borisov2004off, 2004 , 4.2 Uitarea cheilor, p. 80: „Cu toate acestea, deoarece protocoalele de mesagerie sunt de obicei asincrone, este posibil să existe încă un mesaj în tranzit de la Bob care a fost criptat folosind cheia anterioară.”
  16. borisov2004off, 2004 , 4.2 Uitarea cheilor, p. 81: „Pentru a rezolva această problemă, Bob ar trebui să trimită periodic un mesaj gol care confirmă primirea unei noi chei de la Alice.”
  17. di2005secure, 2005 , 6.3 Despre reîmprospătarea cheii, p. 89: „Astfel, valoarea efectuării unui schimb de chei DH cu fiecare mesaj în care autentificarea depinde de cheia partajată anterioară este de valoare limitată.”.
  18. di2005secure, 2005 , 6.3 Despre reîmprospătarea cheii, p. 88: „Notăm totuși că, dacă adversarul învață cheia efemeră actuală, mesajele viitoare pot fi complet compromise”.
  19. di2005secure, 2005 , 6.3 Despre reîmprospătarea cheii, p. 89: „Acest lucru este cu atât mai mult având în vedere costul de calcul al unui schimb DH”.
  20. di2005secure, 2005 , Astfel, sugerăm că OTR se va bucura de o securitate generală mai bună prin rularea protocolului AKE la intervale regulate. Dacă se dorește un mecanism de reîmprospătare cu granulație mai fină în scopuri de secretizare, atunci poate fi folosit un mecanism mai ușor, dar puternic, cum ar fi derivarea de noi chei (posibil pe bază de mesaj, dacă se dorește) prin hashing unidirecțional cheia anterioară., p. 89.
  21. borisov2004off, 2004 , 4.3 Autentificare, p. 81: „Trebuie să folosim doar o semnătură digitală la schimbul inițial de chei. În schimburile ulterioare de chei, folosim MAC-urile pentru a autentifica o cheie nouă folosind un secret partajat vechi, cunoscut și autentic.”.
  22. impauth, 2007 .
  23. borisov2004off, 2004 , 4.3 Autentificare, p. 81: „Cheia de criptare este ea însăși rezultatul unui hash al secretului partajat Diffie-Hellman, care trebuie, de asemenea, să fie autentificat într-un fel. Reușim acest lucru prin semnarea digitală a schimbului inițial Diffie-Hellman.”
  24. di2005secure, 2005 , 3.1 Un eșec de autentificare, p. 84.
  25. impauth, 2007 , 2.2 Attack on OTR version 1, p. 42.
  26. borisov2004off, 2004 , 2.2 Attack on OTR version 1, p. 42: „Acest atac îi permite unui adversar Eve să interfereze cu schimbul inițial de cheie, astfel încât Alice și Bob încă ajung la aceeași cheie la sfârșitul protocolului, dar Alice crede că ea vorbește cu Bob, în ​​timp ce Bob crede că el vorbește. către Eva”.
  27. borisov2004off, 2004 , 7. Lucrări conexe, p. 83: „Dacă se dorește anonimatul, se poate folosi fie SKEME, fie autentificarea privată a lui Abadi în loc de schimbul de chei Diffie-Hellman semnat în protocolul nostru.”
  28. di2005secure, 2005 , 4. Building A Sound AKE For OTR, p. 85.
  29. di2005secure, 2005 , 4.1 SIGMA, p. 85.
  30. impauth, 2007 , 2.3 OTR versiunea 2, p. 43: „Cea mai mare schimbare în versiunea 2 a fost reelaborarea schimbului inițial de chei autentificate (AKE). Ca răspuns la atacul menționat mai sus, AKE a fost schimbat într-o variantă SIGMA, așa cum sa sugerat.”
  31. impauth, 2007 , 2.3 OTR versiunea 2, p. 43: „Acolo unde cheile publice erau trimise anterior în clar, acum sunt criptate folosind secretul partajat DH”.
  32. impauth, 2007 , 2.3 OTR versiunea 2, p. 43: „Scopul lui r în pașii de mai sus este de a satisface o restricție de inginerie: multe protocoale IM impun o dimensiune maximă a mesajelor.”.
  33. impauth, 2007 , 2.3 OTR versiunea 2, p. 43.
  34. OTRv2 .
  35. OTRv3 .
  36. borisov2004off, 2004 , 3.2 Semnături digitale și nerepudierea, p. 79: „Din acest motiv, nu folosim niciodată o semnătură digitală pentru a dovedi că Alice este autorul vreunui mesaj”.
  37. borisov2004off, 2004 , 3.3 MAC-urile și repudiabilitatea, p. 79.
  38. impauth, 2007 , 2.1 Original OTR Protocol, p. 42: „Cheia MAC folosită este un hash al cheii de decriptare pentru mesajul respectiv”.
  39. borisov2004off, 2004 , 3.3 MAC-urile și repudiabilitatea, p. 79: „Alice folosește copia ei a cheii MAC pentru a calcula un MAC al mesajului ei și trimite acest MAC împreună cu mesajul ei într-o transmisie securizată.”
  40. borisov2004off, 2004 , 4.4 Dezvăluirea cheilor MAC, p. 81.
  41. borisov2004off, 2004 , 4.4 Dezvăluirea cheilor MAC, p. 81: „Rețineți ce a realizat acest lucru: Bob nu mai trebuie să se bazeze pe această cheie, deoarece a verificat deja toate mesajele autentificate de acea cheie. Cu toate acestea, acum oricine poate crea mesaje arbitrare care au această cheie MAC și nimeni nu poate exclude o anumită persoană ca un potențial autor al mesajului.”
  42. di2005secure, 2005 , 2.3 Criptarea și autentificarea mesajelor, p. 84: „Motivul din spatele alegerilor de mai sus (adică, o criptare maleabilă și dezvăluirea cheilor MAC) este negarea.”
  43. di2005secure, 2005 , 6.1 Repudiabilitatea criptării simetrice, p. 88: „În al treilea rând, dezvăluirea cheilor MAC introduce probleme de sincronizare și sincronizare necesare pentru a preveni o dezvăluire prea devreme. Deși acest lucru este posibil, acest lucru are ca rezultat o complexitate suplimentară a sistemului. În timp ce considerațiile de mai sus pot fi văzute ca subiective într-o oarecare măsură, în următoarea subsecțiune ilustrăm pericolul adăugării unor tehnici de securitate non-standard.”.
  44. Simpldeniability , Limitări.
  45. di2005secure, 2005 , 2.3 Criptarea și autentificarea mesajelor, p. 83: „Mesajul este mai întâi criptat utilizând AES în modul contor și apoi textul cifrat rezultat este autentificat folosind HMAC (cu funcție hash SHA-1).”.
  46. borisov2004off, 2004 , 3.4 Criptare maleabilă și falsificare, p. 80: „Această criptare este maleabilă, deoarece o modificare a oricărui bit din textul cifrat va corespunde unei modificări a bitului corespunzător din textul simplu. În special, dacă Eve poate ghici textul simplu al unui mesaj, ea poate schimba textul cifrat pentru a decripta în orice alt mesaj de aceeași lungime, fără a cunoaște cheia.”
  47. di2005secure, 2005 , Motivul din spatele alegerilor de mai sus (adică, o criptare maleabilă și dezvăluirea cheilor MAC) este negarea., p. 84.
  48. goldberg2009multi, 2009 : „De exemplu, OTR utilizează coduri de autentificare a mesajelor (MAC) pentru a oferi autenticitate. În timp ce pentru două părți MAC-urile pot oferi un mecanism de autentificare refuzat, MAC-urile nu oferă autentificarea originii atunci când sunt utilizate de mai mult de două părți.”.
  49. bian2007off, 2007 .
  50. bian2007public, 2007 .
  51. 1 2 goldberg2009multi, 2009 .
  52. bian2007off, 2007 , 3.1. Proiectare inițială, p. 81: „Conceptul principal al implementării noastre este de a crea un server virtual, care este un membru de chat care acționează literalmente ca un server.”
  53. goldberg2009multi, 2009 , 1. Motivație, p. 359: „În sfârșit, serverul trebuie să fie considerat sincer, deoarece un server necinstit ar putea compromite atât confidențialitatea, cât și integritatea tuturor mesajelor trimise în timpul unei sesiuni de chat.”
  54. goldberg2009multi, 2009 , 5. Concluzie, p. 367: „Cadrul nostru propus pentru comunicarea Off-the-Record cu mai multe părți nu depinde de un server central; în schimb, am dezvoltat un model care imită o întâlnire privată tipică în care fiecare utilizator îi autentifică pe ceilalți participanți pentru el însuși”.
  55. Mesaje off-the-Record . Consultat la 10 noiembrie 2013. Arhivat din original la 17 august 2014.
  56. Biblioteci care acceptă OTR . Consultat la 10 noiembrie 2013. Arhivat din original pe 10 noiembrie 2013.
  57. https://otr.cypherpunks.ca/software.php Arhivat 10 noiembrie 2013 la clienții Wayback Machine IM care acceptă mesaje off-the-record „din cutie”
  58. Faceți ca OTR să lucreze cu bitlbee . Consultat la 10 noiembrie 2013. Arhivat din original pe 20 noiembrie 2013.
  59. Plugin OTR . Preluat la 6 septembrie 2017. Arhivat din original la 13 iunie 2019.
  60. Psi+ instantanee
  61. Plugin OTR . Consultat la 23 aprilie 2014. Arhivat din original pe 11 ianuarie 2016.
  62. Scurtă descriere . Consultat la 23 aprilie 2014. Arhivat din original pe 24 aprilie 2014.
  63. Cod sursă Arhivat 17 mai 2014.
  64. După cum este descris pe site-ul oficial Arhivat 9 aprilie 2022 la Wayback Machine
  65. Plugin oficial OTR pentru Gajim (downlink) . Preluat la 6 septembrie 2017. Arhivat din original la 6 septembrie 2017. 
  66. Plugin OTR pe Wiki . Preluat la 6 septembrie 2017. Arhivat din original la 6 septembrie 2017.
  67. Acasă pentru irssi-otr și xchat-otr . Consultat la 10 noiembrie 2013. Arhivat din original pe 10 noiembrie 2013.
  68. Plugin OTR pentru Miranda IM Arhivat 13 mai 2007.
  69. Pluginuri suplimentare pentru proiectul Vacuum-IM . Consultat la 24 octombrie 2010. Arhivat din original la 23 mai 2011.
  70. Tkabber OTR Plugin Arhivat 11 martie 2014.
  71. OTR localhost AIM proxy . Consultat la 10 noiembrie 2013. Arhivat din original la 12 aprilie 2018.

Literatură

Link -uri