Off-the-Record beskeder

Den aktuelle version af siden er endnu ikke blevet gennemgået af erfarne bidragydere og kan afvige væsentligt fra den version , der blev gennemgået den 28. maj 2018; checks kræver 7 redigeringer .

Off-the-Record Messaging (OTR) er  en kryptografisk protokol til instant messaging-systemer skabt i 2004 af Nikita Borisov og Ian Goldberg . 

Forfatterne har oprettet et bibliotek distribueret under GNU Lesser GPL-licensen , der bruges til at understøtte OTR-klienter af instant messaging-systemer. Baseret på dette bibliotek oprettede forfatterne også et plugin til Pidgin .

EFF anbefaler brugen af ​​OTR til aflytning [ 1] .

Historie

Den første version af OTR-protokollen og dens implementering blev præsenteret i 2004 af Nikita Borisov og Ian Goldberg [2] [3] . I 2005 blev et angreb på den første version af OTR-protokollen offentliggjort, og en revideret autentificeringsprotokol blev foreslået [4] . Samme år introducerede udviklerne af OTR den anden version af protokollen med rettelse af autentificeringsprotokollen, hvilket også forbedrede den yderligere [5] .

I 2007 udgav Olivier Goffart mod_otr  [6] -modulet til ejabberd -serveren , som tillader automatiske man-in-the-middle- angreb mod OTR-brugere, der ikke verificerer hinandens offentlige nøglefingeraftryk. Udviklerne forbedrede derefter OTR med en Socialist Millionaire- løsning , der giver to brugere mulighed for at autentificere uden at udveksle nøgler eller deres fingeraftryk, forudsat at de kender den delte hemmelighed [7] .  

Grundlæggende egenskaber for protokollen

OTR-protokollen blev udviklet for at sikre privatlivets fred for forhandlinger, svarende til forhandlinger uden brug af telekommunikation [8] [9] . Til dette formål blev følgende krav præsenteret for den udviklede protokol:

Nogle af disse funktioner er implementeret i systemer som PGP og Trillian SecureIM. OTR er anderledes ved, at den implementerer alle disse funktioner i en enkelt protokol [10] .

Nøgleaftale

For at sende beskeder ved hjælp af OTR skal protokoldeltagere etablere en fælles hemmelighed. Til dette bruges  Authenticated Key Exchange-protokollen baseret på Diffie-Hellman-protokollen [11] .

I begyndelsen af ​​protokollen bruger deltagerne Diffie-Hellman-protokollen til at etablere den hemmelige nøgle, der er nødvendig for at sende den første besked. Medlemmerne A og B vælger et primtal og en gruppegenerator . A vælger et tilfældigt tal og sender B resultatet af beregningen . B vælger et tilfældigt tal og sender A resultatet af beregningen . Deltagerne bruger derefter den delte flygtige nøgle , hvor  er den kryptografiske hash-funktion SHA-1 [12] .

Fornyelse af nøgler

For at sikre perfekt videresendelseshemmelighed fornyer brugere konstant nøglen under udvekslingen af ​​meddelelser [13] [14] . Når den første besked er transmitteret, krypterer en af ​​parterne (for eksempel part A) beskeden ved hjælp af krypteringsfunktionen med en nøgle , vælger et tilfældigt tal og sender B et par værdier . Nøglen bruges til at kryptere den næste besked . I fremtiden, med hver besked, ændrer A nummeret , og B ændrer nummeret , og nøglen opdateres.

I praksis når beskeder ikke med det samme, så efter at have sendt en besked fra A til B og opdateret nøglen på siden af ​​A, kan A stadig modtage en besked fra B krypteret med den gamle nøgle [15] . Deltager A kan være sikker på, at B først har opdateret nøglen, når han fra B modtager en besked krypteret med den nye nøgle. Derfor beholder A nok gamle nøgler til at kunne dekryptere alle beskeder, der endnu ikke er ankommet. For at holde nøglerne opdateret ofte nok, sender den side, der ikke har nogen beskeder at sende, tomme beskeder fra tid til anden [16] .

Forfatterne af artiklen "Secure Off-the-Record Messaging" kritiserede nøglefornyelsesordningen, der blev brugt i OTR for ikke at give yderligere sikkerhed [17] . I tilfælde af et kompromittering af den flygtige nøgle , der stadig er i brug , vil den part, der udfører man-in-the-middle- angrebet , være i stand til at ændre alle efterfølgende meddelelser og de flygtige nøgler , der er i brug [18] . Også brugen af ​​Diffie-Hellman-protokollen kan kræve betydelige (for eksempel for batteridrevne enheder) ressourcer [19] . I stedet blev det foreslået at bruge samme skema som for nøglen , eller et mindre beregningskrævende skema baseret på hashing [20] .

Nøglegodkendelse

Autentificering af alle flygtige nøgler undtagen , udføres sammen med meddelelsesgodkendelse og beskrives yderligere [21] . Langtidsnøgler bruges til nøglegodkendelse . Den første version af OTR brugte et usikkert autentificeringsskema, som efterfølgende blev ændret [22] .

Original version af protokollen

I den første version af OTR-protokollen underskriver parterne de relevante Diffie-Hellman-protokolmeddelelser [23] for at autentificere den indledende nøgle . Også i disse meddelelser overfører parterne deres langsigtede offentlige nøgler.

Her , og  er den digitale signatur og og  er de offentlige nøgler for henholdsvis part A og B.

Denne version af protokollen indeholder en kendt sårbarhed [24] [25] . Part E, der udfører et mand-i-midten- angreb , kan autentificere med part A og B på samme tid, mens han foregiver at være en af ​​parterne (f.eks. B) som den anden side (f.eks. A) , som vist nedenfor.

Herefter kan E ikke læse beskederne, da de er krypteret med en nøgle, der kun er kendt af A og B, men B tror, ​​at han taler med E, selvom han faktisk taler med A [26] .

Mere sikre protokoller såsom SKEME blev overvejet, da den første version af OTR-protokollen blev implementeret, men i stedet blev en proprietær protokol implementeret som beskrevet ovenfor [27] .

Anden version af protokollen

Forfatterne af artiklen Secure Off-the-Record Messaging foreslog at ændre nøgleforhandlings- og autentificeringsprotokollen til en af ​​de allerede kendte protokoller såsom SIGMA , SKEME og HMQV [28] . Også i disse meddelelser overfører parterne deres langsigtede offentlige nøgler.

En variant af SIGMA - protokollen , kaldet SIGMA-R, fungerer som følger [29] :

Her er A og B identifikatorer og  er digitale signaturer og  er de offentlige nøgler for henholdsvis part A og B og  er en kryptografisk hashfunktion.

Forfatterne af OTR brugte en modifikation af SIGMA-protokollen i den anden version af OTR [30] . Sammenlignet med den foreslåede SIGMA-protokol har OTR-udviklere beskyttet offentlige nøgler mod passivt angreb (aflytning). For at gøre dette transmitteres offentlige nøgler over en sikker kanal etableret ved hjælp af Diffie-Hellman-protokollen [31] . Ændringen af ​​SIGMA -protokollen, der bruges i OTR, er også kompliceret på grund af begrænsninger af beskedstørrelse i nogle protokoller ( f.eks ]32[)IRC. .

Beskedgodkendelse

I modsætning til systemer som PGP , bruger OTR ikke digitale signaturer til at autentificere meddelelser, da de ikke giver mulighed for benægtelige autentificering [36] . I stedet bruges HMAC [37] .

Til autentificering af meddelelser bruges nøglen K, opnået ved at hashe nøglen, der bruges til at kryptere meddelelsen [38] .

Når part A sender en besked M til en anden part B, sender den den offentlige nøgleværdi HMAC(M, K) [39] sammen med beskeden . Part B kan efter modtagelse af meddelelsen også beregne HMAC(M, K). Hvis det matcher den modtagne værdi, så ved part B, at beskeden blev transmitteret af enten part A eller part B, men da part B ved, at den ikke sendte beskeden, så kan den være sikker på, at beskeden faktisk blev sendt af part A Samtidig giver brugen af ​​HMAC benægtelse: selv ved at afsløre nøglen K kan B ikke bevise over for en tredjepart, at meddelelsen er sendt af part A. Beskeden kan også være forfalsket af part B og enhver part, der ved nøglen K.

Afsløre godkendelsesnøgler

De nøgler, der bruges til kryptering, opdateres konstant som beskrevet ovenfor . Da de nøgler, der bruges til godkendelse, opnås ved at hashe nøglerne, der bruges til kryptering, opdateres de også.

Gamle nøgler, der ikke længere vil blive brugt, kan blive ødelagt. Men autentificeringsnøgler kan også ikke kun ødelægges, men også afsløres. Forfatterne af OTR har tilføjet gammel nøgleafsløring: den gamle autentificeringsnøgle sendes sammen med beskeden, hvis det vides, at den ikke længere vil blive brugt [40] . Denne beslutning forklares af kravene til fornægtelse af OTR-protokollen [41] [42] .

Værket Secure Off-the-Record Messaging påpeger, at offentliggørelsen af ​​autentificeringsnøgler unødigt komplicerer protokollen og kan være negativt usikker, som en ikke-standard metode til kryptografi [43] . Forfatteren af ​​den OTR-baserede TextSecure-protokol, alias Moxie Marlinspike , påpeger også kompleksiteten og ineffektiviteten ved at afsløre autentificeringsnøgler for at sikre benægtelse [44] .

Beskedkryptering

For at kryptere beskeder bruges AES - algoritmen i tællertilstand [45] . Ved at bruge en stream-chiffer konstrueret på denne måde får du formbar kryptering .  Det betyder, at enhver, der opsnapper beskeden, selektivt vil være i stand til at ændre alle bits i beskeden. Især, når meddelelsen er blevet kendt, kan den ændres til enhver anden meddelelse af samme længde [46] .

Kontroversiel kryptering er påkrævet for at sikre, at krypteringen kan nægtes [47] . Med tvivlsom kryptering kan deltagere i OTR-protokollen hævde, at enhver af de transmitterede meddelelser er blevet ændret af en tredjepart.

Multiplayer OTR

OTR-protokollen er designet til kun at blive brugt af to parter. Det kan således ikke bruges i IRC -kanaler, XMPP - konferencer osv.

OTR kan ikke blot udvides til at omfatte flere højttalere på grund af de anvendte kryptografiske primitiver. For eksempel giver meddelelsesgodkendelseskoder ikke meddelelseskildegodkendelse i tilfælde med flere brugere [48] .

Der er udvidelser til protokollen, der tillader flere brugere at bruge protokollen [49] [50] [51] .

En udvidelse af OTR-protokollen kaldet GOTR (Group OTR) er baseret på ideen om at skabe en "virtuel server" [52] . En af deltagerne er udpeget som "virtuel server", udveksler nøgler med andre deltagere, og i fremtiden sendes alle beskeder mellem konferencedeltagere igennem den. Ulempen ved GOTR-protokollen er, at den "virtuelle server" kan ændre indholdet af beskeder, tilføje og slette beskeder, så alle deltagere i konferencen skal stole på den [53] .

Senere foreslog Ian Goldberg og andre forfattere mpOTR -protokollen [51] . I modsætning til GOTR-protokollen fungerer mpOTR-protokollen uden en dedikeret central server [54] .

OTR implementeringer

libotr
Type Bibliotek
Forfatter Ian Goldberg [d] og Nikita Borisov [d]
Udvikler OTR udviklingsteam
Skrevet i C
Hardware platform på tværs af platforme
nyeste version 4.0.2 ( 9. marts 2016 )
Stat Faktiske
Licens GNU Lesser General Public License version 2 [55]
Internet side otr.cypherpunks.ca/index...

Den vigtigste implementering af OTR er libotr-biblioteket skabt af OTR-udviklingsteamet. Baseret på det oprettede de samme udviklere et plugin til Pidgin-klienten , der giver dig mulighed for at bruge OTR med enhver af de protokoller, der understøttes af denne klient. Der er også implementeringer af protokollen i Go , Java , JavaScript , Python , Scheme [56] .

Messenger support

Indbygget support

Følgende klienter har indbygget understøttelse af OTR-protokollen [57] .

Brug af plugin

Proxy

Til klienter, der understøtter AIM / ICQ -protokollen , har OTR-udviklingsteamet udviklet otrproxy-pakken, som er en lokal proxyserver [71] . Det tillod brugen af ​​OTR i klienter, der ikke havde indbygget OTR-understøttelse. I øjeblikket er denne pakke ikke understøttet, udviklerne anbefaler at bruge klienter med OTR-understøttelse.

Noter

  1. ↑ Overvågningsselvforsvar: Instant Messaging (IM) . - "For at beskytte beskeder mod aflytning, når de rejser over netværket, skal du bruge kryptering. Heldigvis er der et fremragende instant messaging-krypteringssystem kaldet OTR (Off The Record).". Hentet 22. oktober 2013. Arkiveret fra originalen 13. oktober 2013.
  2. ↑ borisov2004off, 2004 .
  3. ↑ impauth, 2007 , 2.1 Original OTR Protocol, s. 42: "Den originale OTR-protokol blev præsenteret af Borisov, Goldberg og Brewer i 2004".
  4. ↑ di2005secure, 2005 .
  5. ↑ impauth, 2007 , 2.3 OTR version 2, s. 43: "OTR version 2 blev frigivet i 2005. Den største ændring i version 2 var omarbejdningen af ​​den oprindelige autentificerede nøgleudveksling (AKE).".
  6. ↑ mod_otr . Hentet 20. oktober 2013. Arkiveret fra originalen 29. september 2013.
  7. ↑ impauth, 2007 , 4. Socialist Millionaires' Protocol, s. 44.
  8. ↑ impauth, 2007 , 2.1 Original OTR Protocol, s. 41: "Den originale OTR-protokol blev præsenteret af Borisov, Goldberg og Brewer i 2004. Den var motiveret af ideen om, at to personer, siger Alice og Bob, taler ansigt til ansigt i et privat rum."
  9. ↑ goldberg2009multi, 2009 , 1. Motivation, s. 359: "Selvom dette kan være muligt under visse omstændigheder, afviger det fra det oprindelige OTR-mål, som er at efterligne private samtaler."
  10. ↑ borisov2004off, 2004 , 1. Introduktion, s. 77: "Men ingen af ​​de mekanismer, der i øjeblikket bruges til social kommunikation, har alle disse egenskaber."
  11. ↑ impauth, 2007 , 2.1 Original OTR Protocol, s. 42: "Til at begynde med bruger OTR en Diffie-Hellman (DH) nøgleudveksling til at etablere en fælles hemmelighed mellem Alice og Bob."
  12. ↑ borisov2004off, 2004 , 4.1 Kryptering, s. 80.
  13. ↑ borisov2004off, 2004 , 3.1 Perfekt fremadrettet hemmeligholdelse, s. 78: "Vi omgår dette problem ved at bruge kortvarige krypterings-/dekrypteringsnøgler, der genereres efter behov og kasseres efter brug."
  14. ↑ impauth, 2007 , 2.1 Original OTR Protocol, s. 42: "På dette tidspunkt kan Alice og Bob begynde at sende krypterede beskeder til hinanden. For at begrænse mængden af ​​information, der kompromitteres, hvis en modstander bestemmer den delte nøgle, gentaster Alice og Bob så ofte som muligt. ... Denne procedure giver OTR egenskaben af ​​perfekt fremadrettet hemmeligholdelse (PFS), hvilket sikrer, at fremtidige nøglekompromiser ikke kan afsløre indholdet af gamle meddelelser."
  15. ↑ borisov2004off, 2004 , 4.2 Forgetting Keys, s. 80: "Men da meddelelsesprotokoller typisk er asynkrone, er det muligt, at der stadig er en meddelelse i transit fra Bob, som blev krypteret med den forrige nøgle."
  16. ↑ borisov2004off, 2004 , 4.2 Forgetting Keys, s. 81: "For at løse dette problem skal Bob med jævne mellemrum sende en tom besked, der bekræfter modtagelsen af ​​en ny nøgle fra Alice."
  17. ↑ di2005secure, 2005 , 6.3 On the Key Refreshing, s. 89: "Således er værdien af ​​at udføre en DH-nøgleudveksling med hver besked, hvor autentificering afhænger af den tidligere delte nøgle, af begrænset værdi."
  18. ↑ di2005secure, 2005 , 6.3 On the Key Refreshing, s. 88: "Vi bemærker dog, at hvis modstanderen lærer den nuværende flygtige nøgle, kan fremtidige budskaber blive fuldstændig kompromitteret."
  19. ↑ di2005secure, 2005 , 6.3 On the Key Refreshing, s. 89: "Dette er endnu mere i betragtning af de beregningsmæssige omkostninger ved en DH-udveksling."
  20. ↑ di2005secure, 2005 , Derfor foreslår vi, at OTR vil nyde bedre overordnet sikkerhed ved at køre AKE-protokollen med jævne mellemrum. Hvis en finkornet forfriskende mekanisme ønskes af hensyn til fremadrettet hemmeligholdelse, så kan en lettere, men alligevel kraftfuld mekanisme anvendes, såsom udledning af nye nøgler (eventuelt på per-besked-basis, hvis det ønskes) ved en-vejs hashing den forrige tast., s. 89.
  21. ↑ borisov2004off, 2004 , 4.3 Autentificering, s. 81: "Vi behøver kun at bruge en digital signatur på den indledende nøgleudveksling. I yderligere nøgleudvekslinger bruger vi MAC'er til at autentificere en ny nøgle ved hjælp af en gammel, kendt autentisk delt hemmelighed."
  22. ↑ impauth, 2007 .
  23. ↑ borisov2004off, 2004 , 4.3 Autentificering, s. 81: "Krypteringsnøglen er i sig selv resultatet af en hash af den delte Diffie-Hellman-hemmelighed, som også skal autentificeres på en eller anden måde. Vi opnår dette ved digitalt at underskrive den indledende Diffie-Hellman-børs."
  24. ↑ di2005secure, 2005 , 3.1 En godkendelsesfejl, s. 84.
  25. ↑ impauth, 2007 , 2.2 Attack on OTR version 1, s. 42.
  26. ↑ borisov2004off, 2004 , 2.2 Attack on OTR version 1, s. 42: "Dette angreb gør det muligt for en modstander Eva at forstyrre den indledende nøgleudveksling på en sådan måde, at Alice og Bob stadig når den samme nøgle i slutningen af ​​protokollen, men Alice tror, ​​at hun taler med Bob, mens Bob tror, ​​at han taler til Eva."
  27. ↑ borisov2004off, 2004 , 7. Relateret arbejde, s. 83: "Hvis anonymitet ønskes, kan man bruge enten SKEME eller Abadis private autentificering i stedet for den signerede Diffie-Hellman nøgleudveksling i vores protokol."
  28. ↑ di2005secure, 2005 , 4. Building A Sound AKE For OTR, s. 85.
  29. ↑ di2005secure, 2005 , 4.1 SIGMA, s. 85.
  30. ↑ impauth, 2007 , 2.3 OTR version 2, s. 43: "Den største ændring i version 2 var omarbejdningen af ​​den oprindelige autentificerede nøgleudveksling (AKE). Som svar på angrebet nævnt ovenfor blev AKE ændret til en SIGMA-variant, som foreslået."
  31. ↑ impauth, 2007 , 2.3 OTR version 2, s. 43: "Hvor de offentlige nøgler tidligere blev sendt frit, er de nu krypteret ved hjælp af den delte DH-hemmelighed."
  32. ↑ impauth, 2007 , 2.3 OTR version 2, s. 43: "Formålet med r i ovenstående trin er at tilfredsstille en teknisk begrænsning: mange IM-protokoller håndhæver en maksimal størrelse på meddelelser."
  33. ↑ impauth, 2007 , 2.3 OTR version 2, s. 43.
  34. ↑ OTRv2 .
  35. ↑ OTRv3 .
  36. ↑ borisov2004off, 2004 , 3.2 Digitale signaturer og ikke-afvisning, s. 79: "Af denne grund bruger vi aldrig en digital signatur til at bevise Alices forfatterskab af nogen besked."
  37. ↑ borisov2004off, 2004 , 3.3 MACs and repudiability, s. 79.
  38. ↑ impauth, 2007 , 2.1 Original OTR Protocol, s. 42: "Den anvendte MAC-nøgle er en hash af dekrypteringsnøglen for den besked."
  39. ↑ borisov2004off, 2004 , 3.3 MACs and repudiability, s. 79: "Alice bruger sin kopi af MAC-nøglen til at beregne en MAC af sin besked og sender denne MAC sammen med sin besked i en sikker transmission."
  40. ↑ borisov2004off, 2004 , 4.4 Revealing MAC keys, s. 81.
  41. ↑ borisov2004off, 2004 , 4.4 Revealing MAC keys, s. 81: "Bemærk, hvad dette har opnået: Bob behøver ikke længere stole på denne nøgle, da han allerede har tjekket alle de meddelelser, der er godkendt af denne nøgle. Men nu kan enhver oprette vilkårlige beskeder, der har denne MAC-nøgle, og ingen kan udelukke nogen bestemt person som en potentiel forfatter til beskeden."
  42. ↑ di2005secure, 2005 , 2.3 Kryptering og autentificering af meddelelser, s. 84: "Årsagen bag ovenstående valg (dvs. en formbar kryptering og afsløring af MAC-nøglerne) er benægtelse."
  43. ↑ di2005secure, 2005 , 6.1 Den symmetriske kryptering kan forkastes, s. 88: "For det tredje introducerer afsløring af MAC-nøglerne timing og synkroniseringsproblemer, der er nødvendige for at forhindre en for tidlig afsløring. Selvom dette er muligt, resulterer dette i øget kompleksitet til systemet. Selvom ovenstående betragtninger til en vis grad kan ses som subjektive, illustrerer vi i næste underafsnit faren ved at tilføje ikke-standardiserede sikkerhedsteknikker."
  44. ↑ Forenkling , begrænsninger.
  45. ↑ di2005secure, 2005 , 2.3 Kryptering og autentificering af meddelelser, s. 83: "Meddelelsen krypteres først ved hjælp af AES i tællertilstand, og derefter godkendes den resulterende chiffertekst ved hjælp af HMAC (med hash-funktion SHA-1).".
  46. ↑ borisov2004off, 2004 , 3.4 Formbar kryptering og forfalskning, s. 80: "Denne kryptering er formbar, da en ændring af en hvilken som helst bit i chifferteksten vil svare til en ændring i den tilsvarende bit i klarteksten. Især, hvis Eve kan gætte klarteksten af ​​en besked, kan hun derefter ændre chifferteksten for at dekryptere til enhver anden besked af samme længde uden at kende nøglen."
  47. ↑ di2005secure, 2005 , Årsagen bag ovenstående valg (dvs. en formbar kryptering og afsløring af MAC-nøglerne) er benægtelse., s. 84.
  48. ↑ goldberg2009multi, 2009 : "For eksempel bruger OTR beskedgodkendelseskoder (MAC'er) til at give ægthed. Mens MAC'er for to parter kan give en benægtelig godkendelsesmekanisme, giver MAC'er ikke oprindelsesgodkendelse, når de bruges af mere end to parter."
  49. ↑ bian2007off, 2007 .
  50. ↑ bian2007public, 2007 .
  51. ↑ 1 2 goldberg2009multi, 2009 .
  52. ↑ bian2007off, 2007 , 3.1. Indledende design, s. 81: "Hovedkonceptet for vores implementering er at skabe en virtuel server, som er et chatmedlem, der bogstaveligt talt fungerer som en server."
  53. ↑ goldberg2009multi, 2009 , 1. Motivation, s. 359: "Til sidst må serveren antages at være ærlig, da en uærlig server kan kompromittere både fortroligheden og integriteten af ​​alle beskeder, der sendes under en chatsession."
  54. ↑ goldberg2009multi, 2009 , 5. Konklusion, s. 367: “Vores foreslåede rammer for off-the-record-kommunikation med flere parter afhænger ikke af en central server; i stedet udviklede vi en model, der efterligner et typisk privat møde, hvor hver bruger autentificerer de andre deltagere for sig selv."
  55. ↑ Off-the-Record meddelelser . Hentet 10. november 2013. Arkiveret fra originalen 17. august 2014.
  56. ↑ Biblioteker, der understøtter OTR . Hentet 10. november 2013. Arkiveret fra originalen 10. november 2013.
  57. ↑ https://otr.cypherpunks.ca/software.php Arkiveret 10. november 2013 på Wayback Machine IM-klienter, som understøtter Off-the-Record Messaging "out of the box"
  58. ↑ Få OTR til at arbejde med bitlbee . Hentet 10. november 2013. Arkiveret fra originalen 20. november 2013.
  59. ↑ OTR-plugin . Hentet 6. september 2017. Arkiveret fra originalen 13. juni 2019.
  60. ↑ Psi+ snapshots
  61. ↑ OTR-plugin . Hentet 23. april 2014. Arkiveret fra originalen 11. januar 2016.
  62. ↑ Kort beskrivelse . Hentet 23. april 2014. Arkiveret fra originalen 24. april 2014.
  63. ↑ Kildekode Arkiveret 17. maj 2014.
  64. ↑ Som beskrevet på den officielle hjemmeside Arkiveret 9. april 2022 på Wayback Machine
  65. ↑ Officielt OTR-plugin til Gajim (downlink) . Hentet 6. september 2017. Arkiveret fra originalen 6. september 2017. 
  66. ↑ OTR-plugin på Wiki . Hentet 6. september 2017. Arkiveret fra originalen 6. september 2017.
  67. ↑ Hjem for irssi-otr og xchat-otr . Hentet 10. november 2013. Arkiveret fra originalen 10. november 2013.
  68. ↑ OTR-plugin til Miranda IM Arkiveret 13. maj 2007.
  69. ↑ Yderligere plugins til Vacuum-IM-projektet . Hentet 24. oktober 2010. Arkiveret fra originalen 23. maj 2011.
  70. ↑ Tkabber OTR Plugin Arkiveret 11. marts 2014.
  71. ↑ OTR localhost AIM proxy . Hentet 10. november 2013. Arkiveret fra originalen 12. april 2018.

Litteratur

Links