Nem rekord üzenetküldés

Az oldal jelenlegi verzióját még nem ellenőrizték tapasztalt közreműködők, és jelentősen eltérhet a 2018. május 28-án áttekintett verziótól ; az ellenőrzések 7 szerkesztést igényelnek .

Az Off-the-Record Messaging (OTR) egy  kriptográfiai protokoll azonnali üzenetküldő rendszerek számára , amelyet 2004-ben hoztak létre Nikita Boriszov és Ian Goldberg . 

A szerzők létrehoztak egy, a GNU Lesser GPL licenc alatt terjesztett könyvtárat , amelyet az azonnali üzenetküldő rendszerek OTR klienseinek támogatására használnak. Ezen a könyvtáron alapulva a szerzők létrehoztak egy plugint a Pidgin számára .

Az EHA az OTR használatát javasolja lehallgatáshoz [1] .

Történelem

Az OTR protokoll első változatát és megvalósítását 2004-ben Nikita Boriszov és Ian Goldberg [2] [3] mutatta be . 2005-ben támadást tettek közzé az OTR protokoll első verziója ellen, és javasoltak egy felülvizsgált hitelesítési protokollt [4] . Ugyanebben az évben az OTR fejlesztői bevezették a protokoll második változatát a hitelesítési protokoll javításával, továbbfejlesztve azt is [5] .

2007-ben Olivier Goffart kiadta a mod_otr  [6] modult az ejabberd szerverhez , amely lehetővé teszi az automatikus man-in-the-middle támadásokat az OTR felhasználók ellen, akik nem ellenőrzik egymás nyilvános kulcsú ujjlenyomatait. A fejlesztők ezután továbbfejlesztették az OTR-t egy Socialist Millionaire megoldással , amely lehetővé teszi két felhasználó számára, hogy kulcsok vagy ujjlenyomatok cseréje nélkül hitelesítsenek, feltéve, hogy ismerik a megosztott titkot [7] .  

A protokoll alapvető tulajdonságai

Az OTR protokollt a tárgyalások titkosságának biztosítása érdekében fejlesztették ki , hasonlóan a távközlés nélküli tárgyalásokhoz [8] [9] . Ebből a célból a következő követelményeket támasztották a kidolgozott protokollal szemben:

E szolgáltatások némelyike ​​olyan rendszerekben van megvalósítva, mint a PGP és a Trillian SecureIM. Az OTR abban különbözik, hogy mindezeket a funkciókat egyetlen protokollban valósítja meg [10] .

Kulcsszerződés

Az OTR használatával történő üzenetküldéshez a protokoll résztvevőinek megosztott titkot kell létrehozniuk. Ehhez az Authenticated Key Exchange protokollt használják ,  amely a Diffie-Hellman protokollon alapul [11] .

A protokoll elején a résztvevők a Diffie-Hellman protokollt használják az első üzenet továbbításához szükséges titkos kulcs létrehozásához. Az A és B tagok prímszámot és csoportgenerátort választanak . A kiválaszt egy véletlen számot , és elküldi B-nek a számítás eredményét . B kiválaszt egy véletlen számot , és elküldi A-nak a számítás eredményét . A résztvevők ezután a megosztott efemer kulcsot használják , ahol  az SHA-1 kriptográfiai hash függvény [12] .

Kulcsok megújítása

A tökéletes továbbítási titoktartás érdekében a felhasználók folyamatosan megújítják a kulcsot az üzenetváltás során [13] [14] . Az első üzenet elküldésekor az egyik fél (például A fél) a titkosítási funkció segítségével egy kulccsal titkosítja az üzenetet , kiválaszt egy véletlen számot , és elküld B-nek egy értékpárt . A kulcs a következő üzenet titkosítására szolgál . A jövőben minden üzenetnél A módosítja a számot , B pedig a számot , és a kulcs frissül.

A gyakorlatban az üzenetek nem jutnak el azonnal, így A-ból B-be küldött üzenet és az A oldalán lévő kulcs frissítése után A továbbra is fogadhat B-től a régi kulccsal titkosított üzenetet [15] . A résztvevő csak akkor lehet biztos abban, hogy B frissítette a kulcsot, ha B-től az új kulccsal titkosított üzenetet kap. Ezért A elég régi kulcsot tart meg ahhoz, hogy vissza tudja fejteni az összes még meg nem érkezett üzenetet. Annak érdekében, hogy a kulcsok elég gyakran frissüljenek, az az oldal, amelynek nincs küldendő üzenete, időnként üres üzeneteket küld [16] .

A "Secure Off-the-Record Messaging" című cikk szerzői bírálták az OTR-ben használt kulcsmegújítási sémát, mivel az nem nyújt további biztonságot [17] . Így a még használatban lévő efemer kulcs kompromittálódása esetén a man-in-the-middle támadást végrehajtó fél módosítani tudja az összes későbbi üzenetet és a használatban lévő efemer kulcsokat [18] . Ezenkívül a Diffie-Hellman protokoll használata jelentős erőforrásokat igényelhet (például akkumulátoros eszközök esetében) [19] . Ehelyett ugyanazt a sémát javasolták, mint a kulcsnál , vagy egy kevésbé számításigényes, hashelésen alapuló sémát [20] .

Kulcs hitelesítés

Az összes efemer kulcs hitelesítése, kivéve a , az üzenet hitelesítéssel együtt történik, és további leírása [21] . A kulcshitelesítéshez hosszú távú kulcsokat használnak . Az OTR első verziója nem biztonságos hitelesítési sémát használt, amelyet később megváltoztattak [22] .

A protokoll eredeti verziója

Az OTR protokoll első verziójában a felek aláírják a megfelelő Diffie-Hellman protokoll üzeneteket [23] , hogy hitelesítsék a kezdeti kulcsot . Ezekben az üzenetekben is átadják a felek hosszú távú nyilvános kulcsaikat.

Itt az és  a digitális aláírás és az és  az A és B felek nyilvános kulcsai.

A protokoll ezen verziója ismert biztonsági rést tartalmaz [24] [25] . Az E fél, aki a középső támadást hajtja végre , egyszerre hitelesíthet A és B felet, miközben úgy tesz, mintha az egyik fél (például B), mint a másik fél (például A) , az alábbiak szerint.

Ezek után E nem tudja elolvasni az üzeneteket, mivel azok egy csak A és B által ismert kulccsal vannak titkosítva, de B azt hiszi, hogy E-vel beszél, holott valójában A-val beszél [26] .

Az OTR protokoll első verziójának implementálásakor a biztonságosabb protokollokat, például a SKEME -t vették számításba, ehelyett azonban egy szabadalmaztatott protokollt implementáltak a fent leírtak szerint [27] .

A protokoll második verziója

A Secure Off-the-Record Messaging cikk szerzői a kulcstárgyalási és hitelesítési protokoll módosítását javasolták a már ismert protokollok egyikére, mint például a SIGMA , a SKEME és a HMQV [28] . Ezekben az üzenetekben is átadják a felek hosszú távú nyilvános kulcsaikat.

A SIGMA protokoll egyik változata, a SIGMA-R, a következőképpen működik [29] :

Itt A és B azonosítók és  digitális aláírások, és  az A és B felek nyilvános kulcsai, és  egy kriptográfiai hash függvény.

Az OTR szerzői a SIGMA protokoll egy módosítását használták az OTR második verziójában [30] . A javasolt SIGMA protokollhoz képest az OTR fejlesztői megvédték a nyilvános kulcsokat a passzív támadásoktól (lehallgatás). Ennek érdekében a nyilvános kulcsokat a Diffie-Hellman protokoll segítségével létrehozott biztonságos csatornán továbbítják [31] . Emellett az OTR-ben használt SIGMA protokoll módosítása is bonyolult az egyes protokollok ( korlátozása-üzenetméret)IRCpéldául miatt [32]] .

Üzenet hitelesítés

Ellentétben az olyan rendszerekkel, mint a PGP , az OTR nem használ digitális aláírásokat az üzenetek hitelesítésére, mivel ezek nem biztosítanak megtagadható hitelesítési képességeket [36] . Ehelyett a HMAC [37] használatos .

Az üzenet hitelesítéséhez a K kulcsot használjuk, amelyet az üzenet titkosításához használt kulcs kivonatolásával kapunk [38] .

Amikor A fél egy M üzenetet küld egy másik B félnek, elküldi a HMAC(M, K) [39] nyilvános kulcs értékét az üzenettel együtt . A B fél az üzenet vételekor a HMAC(M, K) számítást is elvégezheti. Ha egyezik a kapott értékkel, akkor B fél tudja, hogy az üzenetet A vagy B fél küldte, de mivel B fél tudja, hogy nem ő küldte az üzenetet, akkor biztos lehet benne, hogy az üzenetet valóban a fél küldte. A A HMAC használata ugyanakkor tagadhatóságot ad: B még a K kulcs felfedésével sem tudja harmadik félnek bizonyítani, hogy az üzenetet A fél küldte. Az üzenetet B fél is hamisíthatja, és bármely fél, aki tudja. a kulcs K.

Hitelesítési kulcsok felfedése

A titkosításhoz használt kulcsok a fent leírtak szerint folyamatosan frissülnek . Mivel a hitelesítéshez használt kulcsokat a titkosításhoz használt kulcsok kivonatolásával kapjuk meg, ezek is frissítésre kerülnek.

A már nem használt régi kulcsok megsemmisíthetők. De a hitelesítési kulcsok nemcsak megsemmisülhetnek, hanem nyilvánosságra is hozhatók. Az OTR szerzői hozzáadták a régi kulcsfeltárást: a régi hitelesítési kulcsot elküldik az üzenettel együtt, ha ismert, hogy a továbbiakban nem használják [40] . Ezt a döntést az OTR protokoll denibilitásának követelményei magyarázzák [41] [42] .

A Secure Off-the-Record Messaging című munka rámutat arra, hogy a hitelesítési kulcsok nyilvánosságra hozatala szükségtelenül bonyolítja a protokollt, és negatívan bizonytalan lehet, mivel a titkosítás nem szabványos módszere [43] . Az OTR-alapú TextSecure protokoll szerzője, alias Moxie Marlinspike is rámutat a hitelesítési kulcsok letagadhatóságot biztosító feltárásának összetettségére és nem hatékony [44] .

Üzenettitkosítás

Az üzenetek titkosításához az AES algoritmust használják számláló módban [45] . Az így megszerkesztett adatfolyam-rejtjel használata alakítható titkosítást biztosít .  Ez azt jelenti, hogy bárki, aki elfogja az üzenetet, szelektíven módosíthatja az üzenet bármely bitjét. Különösen, ha az üzenet ismertté vált, bármely más, azonos hosszúságú üzenetre módosítható [46] .

Ellentmondásos titkosításra van szükség annak biztosítására, hogy a titkosítás megtagadható legyen [47] . Megkérdőjelezhető titkosítás esetén az OTR protokoll résztvevői azt állíthatják, hogy a továbbított üzenetek bármelyikét megváltoztatta egy harmadik fél.

Többjátékos OTR

Az OTR protokollt úgy tervezték, hogy csak két fél használja. Így nem használható IRC csatornákon, XMPP konferenciákon stb.

Az OTR a használt kriptográfiai primitívek miatt nem terjeszthető ki egyszerűen több hangszóró esetére. Például az üzenet hitelesítési kódok nem biztosítanak üzenetforrás hitelesítést többfelhasználós esetben [48] .

A protokollnak vannak olyan kiterjesztései, amelyek lehetővé teszik több felhasználó számára a protokoll használatát [49] [50] [51] .

Az OTR protokoll egyik kiterjesztése, a GOTR (Group OTR) egy "virtuális szerver" létrehozásának ötletén alapul [52] . Az egyik résztvevőt "virtuális szervernek" nevezik ki, kulcsot cserél a többi résztvevővel, és a jövőben ezen keresztül küldik el a konferencia résztvevői közötti összes üzenetet. A GOTR protokoll hátránya, hogy a "virtuális szerver" képes megváltoztatni az üzenetek tartalmát, üzeneteket hozzáadni és törölni, így a konferencia minden résztvevőjének bíznia kell benne [53] .

Később Ian Goldberg és más szerzők javasolták az mpOTR protokollt [51] . A GOTR protokolltól eltérően az mpOTR protokoll dedikált központi szerver nélkül működik [54] .

OTR implementációk

libotr
Típusú Könyvtár
Szerző Ian Goldberg [d] és Nikita Boriszov [d]
Fejlesztő OTR fejlesztőcsapat
Beírva C
Hardver platform platformközi
legújabb verzió 4.0.2 ( 2016. március 9. )
Állapot Tényleges
Engedély GNU Lesser General Public License 2. verzió [55]
Weboldal otr.cypherpunks.ca/index…

Az OTR fő megvalósítása az OTR fejlesztőcsapata által létrehozott libotr könyvtár. Ennek alapján ugyanazok a fejlesztők létrehoztak egy plugint a Pidgin klienshez , amely lehetővé teszi az OTR használatát az adott kliens által támogatott bármely protokollal. A protokollnak vannak Go , Java , JavaScript , Python , Scheme [56] implementációi is .

Messenger támogatás

Beépített támogatás

A következő kliensek natív támogatással rendelkeznek az OTR protokollhoz [57] .

A bővítmény használata

Proxy

Az AIM / ICQ protokollt támogató ügyfelek számára az OTR fejlesztőcsapata kifejlesztette az otrproxy csomagot, amely egy helyi proxyszerver [71] . Lehetővé tette az OTR használatát olyan ügyfeleknél, amelyek nem rendelkeznek natív OTR-támogatással. Jelenleg ez a csomag nem támogatott, a fejlesztők OTR támogatással rendelkező kliensek használatát javasolják.

Jegyzetek

  1. ↑ Felügyeleti önvédelem: azonnali üzenetküldés (IM) . - "A hálózaton áthaladó üzenetek elfogás elleni védelme érdekében titkosítást kell használnia. Szerencsére létezik egy kiváló azonnali üzenetküldő titkosító rendszer, az OTR (Off The Record). Letöltve: 2013. október 22. Az eredetiből archiválva : 2013. október 13..
  2. ↑ borisov2004off, 2004 .
  3. ↑ impauth, 2007 , 2.1 Eredeti OTR-protokoll, p. 42: "Az eredeti OTR protokollt Boriszov, Goldberg és Brewer mutatta be 2004-ben".
  4. ↑ di2005secure, 2005 .
  5. ↑ impauth, 2007 , 2.3 OTR 2. verzió, p. 43: "Az OTR 2-es verzióját 2005-ben adták ki. A 2-es verzió legnagyobb változása a kezdeti hitelesített kulcscsere (AKE) átdolgozása volt."
  6. ↑ mod_otr . Letöltve: 2013. október 20. Az eredetiből archiválva : 2013. szeptember 29..
  7. ↑ impauth, 2007 , 4. Szocialista milliomosok jegyzőkönyve, p. 44.
  8. ↑ impauth, 2007 , 2.1 Eredeti OTR-protokoll, p. 41: "Az eredeti OTR protokollt Boriszov, Goldberg és Brewer mutatta be 2004-ben. Az az ötlet motiválta, hogy két ember, mondjuk Alice és Bob, négyszemközt beszélgettek egy privát szobában."
  9. ↑ goldberg2009multi, 2009 , 1. Motiváció, p. 359: "Bár ez bizonyos körülmények között megvalósítható, eltér az eredeti OTR céltól, amely a magánbeszélgetések utánzása."
  10. ↑ borisov2004off, 2004 , 1. Bevezetés, p. 77: "Azonban a közösségi kommunikációra jelenleg használt mechanizmusok egyike sem rendelkezik mindezen tulajdonságokkal."
  11. ↑ impauth, 2007 , 2.1 Eredeti OTR-protokoll, p. 42: "Először az OTR Diffie-Hellman (DH) kulcscserét használ, hogy megosztott titkot hozzon létre Alice és Bob között."
  12. ↑ borisov2004off, 2004 , 4.1 Titkosítás, p. 80.
  13. ↑ borisov2004off, 2004 , 3.1 Tökéletes továbbítási titok, p. 78: "Ezt a problémát úgy kerüljük meg, hogy rövid élettartamú titkosítási/visszafejtési kulcsokat használunk, amelyeket szükség szerint generálunk, és használat után eldobunk."
  14. ↑ impauth, 2007 , 2.1 Eredeti OTR-protokoll, p. 42: "Ennél a pontnál Alice és Bob elkezdhet titkosított üzeneteket küldeni egymásnak. Annak érdekében, hogy korlátozza a kompromittált információ mennyiségét, ha egy ellenfél meghatározza a megosztott kulcsot, Alice és Bob a lehető leggyakrabban újrakulcsolja. ... Ez az eljárás a tökéletes továbbítási titok (PFS) tulajdonságát biztosítja az OTR-nek, biztosítva, hogy a jövőbeli kulcsfontosságú kompromisszumok ne fedjék fel a régi üzenetek tartalmát."
  15. ↑ borisov2004off, 2004 , 4.2 A kulcsok elfelejtése, p. 80: "Azonban, mivel az üzenetküldési protokollok jellemzően aszinkronok, lehetséges, hogy még mindig van egy üzenet Bobtól, amelyet az előző kulccsal titkosítottak."
  16. ↑ borisov2004off, 2004 , 4.2 A kulcsok elfelejtése, p. 81: "A probléma megoldásához Bobnak időnként üres üzenetet kell küldenie, amelyben nyugtázza, hogy új kulcsot kapott Alice-től."
  17. ↑ di2005secure, 2005 , 6.3 A kulcsfrissítésről, p. 89: "Így korlátozott értékű a DH kulcscsere végrehajtása minden olyan üzenettel, ahol a hitelesítés az előző megosztott kulcstól függ."
  18. ↑ di2005secure, 2005 , 6.3 A kulcsfrissítésről, p. 88: "Megjegyezzük azonban, hogy ha az ellenfél megtanulja az aktuális efemer kulcsot, a jövőbeli üzenetek teljesen veszélybe kerülhetnek."
  19. ↑ di2005secure, 2005 , 6.3 A kulcsfrissítésről, p. 89: "Ez még inkább igaz, ha figyelembe vesszük a DH központ számítási költségét."
  20. ↑ di2005secure, 2005 , Így azt javasoljuk, hogy az OTR jobb általános biztonságot élvezzen az AKE protokoll rendszeres időközönkénti futtatásával. Ha finomabb szemcséjű frissítőmechanizmusra van szükség a továbbítási titoktartás érdekében, akkor egy könnyebb, mégis erőteljes mechanizmus alkalmazható, például új kulcsok származtatása (lehetőleg üzenetenkénti alapon, ha úgy kívánja) egyirányú kivonattal. az előző billentyűt. 89.
  21. ↑ borisov2004off, 2004 , 4.3 Hitelesítés, p. 81: "Csak digitális aláírást kell használnunk a kezdeti kulcscserénél. A további kulcscserék során MAC-okat használunk egy új kulcs hitelesítésére egy régi, ismert-hiteles megosztott titok használatával.
  22. ↑ impauth, 2007 .
  23. ↑ borisov2004off, 2004 , 4.3 Hitelesítés, p. 81: "A titkosítási kulcs maga a Diffie-Hellman megosztott titok kivonatának eredménye, amelyet szintén hitelesíteni kell valamilyen módon. Ezt a kezdeti Diffie-Hellman csere digitális aláírásával érjük el."
  24. ↑ di2005secure, 2005 , 3.1 Hitelesítési hiba, p. 84.
  25. ↑ impauth, 2007 , 2.2 Támadás az OTR 1. verziója ellen, p. 42.
  26. ↑ borisov2004off, 2004 , 2.2 Attack on OTR version 1, p. 42: "Ez a támadás lehetővé teszi az ellenfél számára, hogy Eve beleavatkozzon a kezdeti kulcscserébe oly módon, hogy Alice és Bob a protokoll végén még mindig ugyanazt a kulcsot érje el, de Alice azt hiszi, hogy ő Bobbal beszél, míg Bob azt hiszi, hogy ő beszél. Évának."
  27. ↑ borisov2004off, 2004 , 7. Kapcsolódó munka, p. 83: "Ha anonimitásra van szükség, a protokollunkban az aláírt Diffie-Hellman kulcscsere helyett SKEME vagy Abadi privát hitelesítését használhatjuk."
  28. ↑ di2005secure, 2005 , 4. Sound AKE készítése az OTR-hez, p. 85.
  29. ↑ di2005secure, 2005 , 4.1 SIGMA, p. 85.
  30. ↑ impauth, 2007 , 2.3 OTR 2. verzió, p. 43: "A legnagyobb változás a 2-es verzióban a kezdeti hitelesített kulcscsere (AKE) átdolgozása volt. A fent említett támadásra válaszul az AKE-t SIGMA-változatra változtatták, amint azt javasolták."
  31. ↑ impauth, 2007 , 2.3 OTR 2. verzió, p. 43: "Ahol korábban a nyilvános kulcsokat tiszta formában küldték el, most a DH megosztott titok használatával titkosítják."
  32. ↑ impauth, 2007 , 2.3 OTR 2. verzió, p. 43: "Az r célja a fenti lépésekben egy műszaki korlátozás teljesítése: sok IM-protokoll maximális méretet kényszerít ki az üzenetekre."
  33. ↑ impauth, 2007 , 2.3 OTR 2. verzió, p. 43.
  34. ↑ OTRv2 .
  35. ↑ OTRv3 .
  36. ↑ borisov2004off, 2004 , 3.2 Digitális aláírás és letagadhatatlanság, p. 79: "Ebből az okból kifolyólag soha nem használunk digitális aláírást annak bizonyítására, hogy Alice az üzenet szerzője."
  37. ↑ borisov2004off, 2004 , 3.3 MAC-ok és visszautasíthatóság, p. 79.
  38. ↑ impauth, 2007 , 2.1 Eredeti OTR-protokoll, p. 42: "A használt MAC-kulcs az üzenet visszafejtési kulcsának hash-je."
  39. ↑ borisov2004off, 2004 , 3.3 MAC-ok és visszautasíthatóság, p. 79: "Alice a MAC-kulcs másolatát használja üzenete MAC-számának kiszámításához, és ezt a MAC-ot az üzenetével együtt biztonságos átvitelben küldi el."
  40. ↑ borisov2004off, 2004 , 4.4 MAC-kulcsok felfedése, p. 81.
  41. ↑ borisov2004off, 2004 , 4.4 MAC-kulcsok felfedése, p. 81: "Jegyezze meg, mit ért el ezzel: Bobnak nem kell többé erre a kulcsra hagyatkoznia, mivel már ellenőrizte az összes, ezzel a kulccsal hitelesített üzenetet. Mostantól azonban bárki létrehozhat tetszőleges üzeneteket, amelyek rendelkeznek ezzel a MAC-kulccsal, és senki sem zárhat ki egyetlen személyt sem, mint az üzenet lehetséges szerzőjét."
  42. ↑ di2005secure, 2005 , 2.3 Üzenetek titkosítása és hitelesítése, p. 84: "A fenti választások (azaz egy alakítható titkosítás és a MAC-kulcsok felfedése) mögött a tagadhatóság áll."
  43. ↑ di2005secure, 2005 , 6.1 A szimmetrikus titkosítás visszautasíthatósága, p. 88: "Harmadszor, a MAC-kulcsok felfedése időzítési és szinkronizálási problémákat okoz, amelyek a túl korai közzététel elkerüléséhez szükségesek. Bár ez lehetséges, ez a rendszer bonyolultabbá válik. Míg a fenti megfontolások bizonyos mértékig szubjektívnek tekinthetők, a következő alfejezetben bemutatjuk a nem szabványos biztonsági technikák hozzáadásának veszélyét."
  44. ↑ Egyszerűsíthetőség , korlátok.
  45. ↑ di2005secure, 2005 , 2.3 Üzenetek titkosítása és hitelesítése, p. 83: "Az üzenetet először AES-sel titkosítják számláló módban, majd a kapott titkosított szöveget a HMAC segítségével hitelesítik (SHA-1 hash funkcióval).".
  46. ↑ borisov2004off, 2004 , 3.4 Képlékeny titkosítás és hamisíthatóság, p. 80: "Ez a titkosítás alakítható, mivel a rejtjelezett szöveg bármely bitjének megváltoztatása megfelel a nyílt szöveg megfelelő bitjének változásának. Különösen, ha Eve ki tudja tippelni egy üzenet egyszerű szövegét, akkor megváltoztathatja a rejtjelezett szöveget, hogy visszafejtse bármely más, azonos hosszúságú üzenetre, anélkül, hogy ismerné a kulcsot."
  47. ↑ di2005secure, 2005 , A fenti választások (pl. képlékeny titkosítás és a MAC-kulcsok felfedése) mögött a tagadhatóság áll., p. 84.
  48. ↑ goldberg2009multi, 2009 : "Például az OTR üzenet hitelesítési kódokat (MAC) használ a hitelesség biztosítására. Míg két fél számára a MAC-ok tagadható hitelesítési mechanizmust biztosítanak, a MAC-ok nem biztosítanak eredet hitelesítést, ha kettőnél több fél használja."
  49. ↑ bian2007off, 2007 .
  50. ↑ bian2007public, 2007 .
  51. ↑ 1 2 goldberg2009multi, 2009 .
  52. ↑ bian2007off, 2007 , 3.1. Kezdeti tervezés, p. 81: "Megvalósításunk fő koncepciója egy virtuális szerver létrehozása, amely egy chat tag, amely szó szerint szerverként működik."
  53. ↑ goldberg2009multi, 2009 , 1. Motiváció, p. 359: "Végül a szervert becsületesnek kell tekinteni, mivel egy tisztességtelen szerver veszélyeztetheti a csevegés során küldött összes üzenet bizalmasságát és integritását."
  54. ↑ goldberg2009multi, 2009 , 5. Összegzés, p. 367: „A több fél közötti, nyilvántartáson kívüli kommunikációra javasolt keretünk nem függ központi szervertől; ehelyett egy olyan modellt fejlesztettünk ki, amely egy tipikus privát találkozót utánoz, ahol minden felhasználó saját maga hitelesíti a többi résztvevőt."
  55. ↑ Nem rekord üzenetküldés . Letöltve: 2013. november 10. Az eredetiből archiválva : 2014. augusztus 17..
  56. ↑ OTR-t támogató könyvtárak . Letöltve: 2013. november 10. Az eredetiből archiválva : 2013. november 10..
  57. ↑ https://otr.cypherpunks.ca/software.php Archiválva : 2013. november 10. a Wayback Machine IM klienseknél, amelyek támogatják az Off-the-Record üzenetküldést "kivételben"
  58. ↑ Az OTR működése a bitlbee-vel . Letöltve: 2013. november 10. Az eredetiből archiválva : 2013. november 20..
  59. ↑ OTR bővítmény . Letöltve: 2017. szeptember 6. Az eredetiből archiválva : 2019. június 13.
  60. ↑ Psi+ pillanatképek
  61. ↑ OTR bővítmény . Letöltve: 2014. április 23. Az eredetiből archiválva : 2016. január 11..
  62. ↑ Rövid leírás . Letöltve: 2014. április 23. Az eredetiből archiválva : 2014. április 24..
  63. ↑ Forráskód Archiválva : 2014. május 17.
  64. ↑ A hivatalos webhelyen leírtak szerint archiválva 2022. április 9-én a Wayback Machine -nél
  65. ↑ Hivatalos OTR-bővítmény a Gajim-hez (downlink) . Letöltve: 2017. szeptember 6. Az eredetiből archiválva : 2017. szeptember 6.. 
  66. ↑ OTR bővítmény a Wikin . Letöltve: 2017. szeptember 6. Az eredetiből archiválva : 2017. szeptember 6..
  67. ↑ Az irssi-otr és az xchat-otr otthona . Letöltve: 2013. november 10. Az eredetiből archiválva : 2013. november 10..
  68. ↑ OTR bővítmény a Miranda IM -hez Archiválva : 2007. május 13.
  69. ↑ További bővítmények a Vacuum-IM projekthez . Letöltve: 2010. október 24. Az eredetiből archiválva : 2011. május 23..
  70. ↑ Tkabber OTR Plugin archiválva : 2014. március 11.
  71. ↑ OTR localhost AIM proxy . Letöltve: 2013. november 10. Az eredetiből archiválva : 2018. április 12..

Irodalom

Linkek