Off-the-Record Messaging

Материал из Википедии — свободной энциклопедии
(перенаправлено с «OTR»)
Текущая версия страницы покане проверялась опытными участниками и может значительно отличаться отверсии, проверенной 28 мая 2018 года; проверки требуют11 правок.
Перейти к навигацииПерейти к поиску

Off-the-Record Messaging (OTR) —криптографический протокол длясистем мгновенного обмена сообщениями, созданный в 2004 годуНикитой Борисовым иИаном Голдбергом (англ. Ian Goldberg).

Авторами создана библиотека, распространяемая под лицензиейGNU Lesser GPL, используемая для поддержки OTR-клиентами систем мгновенного обмена сообщениям. Также на основе этой библиотеки авторами создан плагин дляPidgin.

ФондEFF рекомендует использовать OTR для защиты от прослушивания[1].

Содержание

История

[править |править код]

Первая версия протокола OTR и его реализация были представлены в 2004 годуНикитой Борисовым иИаном Голдбергом[2][3]. В 2005 году была опубликована атака на первую версию протокола OTR и предложен исправленный протокол аутентификации[4]. В том же году разработчики OTR представили вторую версию протокола с исправлением протокола аутентификации, также дополнительно улучшив его[5].

В 2007 году Оливер Гоффарт (англ. Olivier Goffart) опубликовал модульmod_otr[6] для сервераejabberd, позволяющий автоматически проводить атаку типа «человек посередине» на пользователей OTR, не проверяющих отпечатки открытых ключей друг друга. После этого разработчики улучшили OTR с использованием решениязадачи «социалиста-миллионера» (англ. Socialist Millionaire), позволяющего двум пользователям провести аутентификацию без обмена ключами или их отпечатками при условии, что они знают общий секрет[7].

Аутентификация с использованием вопроса и секретного ответа вPidgin

Основные свойства протокола

[править |править код]

Протокол OTR разрабатывался для того, чтобы обеспечитьприватность переговоров, аналогичную переговорам без использования средств телекоммуникаций[8][9]. Для этого к разрабатываемому протоколу были предъявлены следующие требования:

  • шифрование сообщений — никто иной не сможет прочитать сообщения;
  • аутентификация собеседников — уверенность в том, кто является собеседником;
  • perfect forward secrecy — если потеряны секретные ключи, прошлая переписка не будет скомпрометирована;
  • возможность отречения — третье лицо не сможет доказать, что сообщения написаны кем-либо другому адресату.

Частично эти свойства реализованы в таких системах, какPGP и Trillian SecureIM. OTR отличается тем, что реализует все эти свойства в одном протоколе[10].

Согласование ключей

[править |править код]

Для передачи сообщений с использованием OTR участники протокола должны установить общий секретный ключ. Для этого используется протокол аутентифицированного распределения ключей (англ. Authenticated Key Exchange), основанный напротоколе Диффи — Хеллмана[11].

В начале протокола участники используют протокол Диффи — Хеллмана для установки секретного ключа, необходимого для передачи первого сообщения. Участники A и B выбирают простое числоp{\displaystyle p} и генераторg{\displaystyle g} группыZp∗{\displaystyle \mathbb {Z} _{p}^{*}}. A выбирает случайное числоa1{\displaystyle a_{1}} и отправляет B результат вычисленияga1modp{\displaystyle g^{a_{1}}{\bmod {p}}}. B выбирает случайное числоb1{\displaystyle b_{1}} и отправляет A результат вычисленияgb1modp{\displaystyle g^{b_{1}}{\bmod {p}}}. Затем участники используют общийэфемерный ключk11=H(ga1b1){\displaystyle k_{11}=H(g^{a_{1}b_{1}})}, гдеH{\displaystyle H} —криптографическая хеш-функцияSHA-1[12].

Обновление ключей

[править |править код]

Для обеспеченияperfect forward secrecy пользователи постоянно обновляют ключ во время обмена сообщениями[13][14]. При передаче первого сообщения одна из сторон (например, сторона A) шифрует сообщение с помощью функции шифрованияE{\displaystyle E} с ключомk11{\displaystyle k_{11}}, выбирает случайное числоa2{\displaystyle a_{2}} и передает B пару значенийga2,Ek11(M){\displaystyle g^{a_{2}},E_{k_{11}}(M)}. Для шифрования следующего сообщения используется ключk21=H(ga2b1){\displaystyle k_{21}=H(g^{a_{2}b_{1}})}. В дальнейшем при передаче каждого сообщения A изменяет числоai{\displaystyle a_{i}}, а B изменяет числоbj{\displaystyle b_{j}}, и ключkij{\displaystyle k_{ij}} обновляется.

На практике сообщения доходят не мгновенно, поэтому после отправки сообщения от A к B и обновления ключа на стороне A, A все ещё может получить сообщение от B, зашифрованное старым ключом[15]. Участник A может быть уверен в том, что B обновил ключ, только тогда, когда получит от B сообщение, зашифрованное новым ключом. Поэтому A хранит достаточное количество старых ключей, чтобы иметь возможность расшифровать все сообщения, которые ещё не дошли. Для того, чтобы ключи все же обновлялись достаточно часто, сторона, у которой нет сообщений для отправки, время от времени передает пустые сообщения[16].

Авторы статьи «Secure Off-the-Record Messaging» критиковали используемую в OTR схему обновления ключей как не предоставляющую дополнительной безопасности[17]. Так, в случаекомпрометации все ещё используемогоэфемерного ключаkij{\displaystyle k_{ij}}, сторона, осуществляющая атаку «человек посередине», сможет модифицировать все последующие сообщения и используемые эфемерные ключи[18]. Также использование протокола Диффи — Хеллмана может требовать значительных (например, для устройств, питающихся от батареи) ресурсов[19]. Вместо этого было предложено использовать ту же схему, что и для ключаk11{\displaystyle k_{11}}, либо требующую меньше вычислительных ресурсов схему, основанную нахешировании[20].

Аутентификация ключей

[править |править код]

Аутентификация всехэфемерных ключей, за исключениемk11{\displaystyle k_{11}}, осуществляется вместе с аутентификацией сообщений и описанадалее[21]. Для аутентификации ключаk11{\displaystyle k_{11}} используются долговременные ключи. В первой версии OTR использовалась небезопасная схема аутентификации, которая была впоследствии изменена[22].

Оригинальная версия протокола

[править |править код]

В первой версии протокола OTR для аутентификации начального ключаk11{\displaystyle k_{11}} стороны подписывают соответствующие сообщения протокола Диффи — Хеллмана[23]. Также в этих сообщениях стороны передают свои долговременные открытые ключи.

A⟶B:SA(ga1),PA{\displaystyle A\longrightarrow B\colon S_{A}(g^{a_{1}}),P_{A}}
B⟶A:SB(gb1),PB{\displaystyle B\longrightarrow A\colon S_{B}(g^{b_{1}}),P_{B}}

ЗдесьSA{\displaystyle S_{A}} иSB{\displaystyle S_{B}} — цифровая подпись,PA{\displaystyle P_{A}} иPB{\displaystyle P_{B}} — открытые ключи сторон A и B соответственно.

Данная версия протокола содержит известную уязвимость[24][25]. Сторона E, проводящая атаку «человек посередине», может выполнить аутентификацию одновременно со сторонами A и B, при этом выдав себя одной из сторон (например, B) за другую сторону (например, A), как показано далее.

A⟶E:SA(ga1),PA{\displaystyle A\longrightarrow E\colon S_{A}(g^{a_{1}}),P_{A}}
E⟶B:SE(ga1),PE{\displaystyle E\longrightarrow B\colon S_{E}(g^{a_{1}}),P_{E}}
B⟶E:SB(gb1),PB{\displaystyle B\longrightarrow E\colon S_{B}(g^{b_{1}}),P_{B}}
E⟶A:SB(gb1),PB{\displaystyle E\longrightarrow A\colon S_{B}(g^{b_{1}}),P_{B}}

После этого E не может читать сообщения, так как они зашифрованы известным только A и B ключом, но B считает, что он разговаривает с E, хотя на самом деле разговаривает с A[26].

Более безопасные протоколы, такие какSKEME, рассматривались при реализации первой версии протокола OTR, но вместо этого был реализован собственный протокол, описанный выше[27].

Вторая версия протокола

[править |править код]

Авторы статьи Secure Off-the-Record Messaging предложили изменить протокол согласования и аутентификации ключей на один из уже известных протоколов, таких какSIGMA,SKEME иHMQV[28]. Также в этих сообщениях стороны передают свои долговременные открытые ключи.

Вариант протоколаSIGMA, называемый SIGMA-R, работает следующим образом[29]:

A⟶B:ga{\displaystyle A\longrightarrow B\colon g^{a}}
B⟶A:gb{\displaystyle B\longrightarrow A\colon g^{b}}
A⟶B:A,SA(gb,ga),MACH(gab)(0,A),PA{\displaystyle A\longrightarrow B\colon {\text{A}},S_{A}(g^{b},g^{a}),MAC_{H(g^{ab})}(0,{\text{A}}),P_{A}}
B⟶A:B,SB(ga,gb),MACH(gab)(1,B),PB{\displaystyle B\longrightarrow A\colon {\text{B}},S_{B}(g^{a},g^{b}),MAC_{H(g^{ab})}(1,{\text{B}}),P_{B}}

Здесь A и B — идентификаторы,SA{\displaystyle S_{A}} иSB{\displaystyle S_{B}} — цифровые подписи,PA{\displaystyle P_{A}} иPB{\displaystyle P_{B}} — открытые ключи сторон A и B соответственно, аH{\displaystyle H} — криптографическая хеш-функция.

Авторы OTR использовали модификацию протокола SIGMA во второй версии OTR[30]. По сравнению с предложенным протоколом SIGMA, разработчики OTR защитили открытые ключи от пассивной атаки (прослушивания). Для этого открытые ключи передаются по защищенному каналу, установленному с помощью протокола Диффи — Хеллмана[31]. Также используемая в OTR модификация протокола SIGMA усложнена из-за ограничений на размер сообщения в некоторых протоколах (например,IRC)[32] Полное техническое описание используемого в OTR варианта SIGMA приведено в статье[33] и спецификациях OTRv2[34] и OTRv3[35].

Аутентификация сообщений

[править |править код]

В отличие от таких систем какPGP, OTR не использует цифровые подписи для аутентификации сообщений, так как они не предоставляют возможности отрицаемой аутентификации[36]. Вместо этого используетсяHMAC[37].

Для аутентификации сообщений используется ключ K, полученныйхешированием ключа, используемого для шифрования сообщения[38].

Когда сторона A передает сообщение M другой стороне B, вместе с сообщением она передает вычисленное с помощью общего ключа значение HMAC(M, K)[39]. Сторона B, получив сообщение, может также вычислить HMAC(M, K). Если оно совпадает с полученным значением, то сторона B знает, что сообщение было передано либо стороной A, либо стороной B, но так как сторона B знает, что она сообщение не посылала, то она может быть уверена, что сообщение действительно было отправлено стороной A. В то же время использованиеHMAC обеспечивает отрицаемость: даже раскрыв ключ K, B не может доказать третьей стороне, что сообщение было отправлено стороной A. Сообщение также могло быть подделано стороной B и любой стороной, которая знает ключ K.

Раскрытие ключей аутентификации

[править |править код]

Ключи, используемые для шифрования, постоянно обновляются,как описано выше. Так как ключи, используемые для аутентификации, получаются хешированием ключей, используемых для шифрования, они также обновляются.

Старые ключи, которые больше не будут использованы, могут быть уничтожены. Но ключи аутентификации также могут быть не только уничножены, но и раскрыты. Авторы OTR добавили раскрытие старых ключей: вместе с сообщением пересылается старый ключ аутентификации, если известно, что он больше не будет использован[40]. Такое решение объясняется требованиями отрицаемости протокола OTR[41][42].

В работе Secure Off-the-Record Messaging указывается, что раскрытие ключей аутентификации излишне усложняет протокол и может негативно быть небезопасно, как нестандартный для криптографии метод[43]. Автор основанного на OTR протокола TextSecure, известный под псевдонимомMoxie Marlinspike[англ.] также указывает на излишнюю сложность и неэффективность раскрытия ключей аутентификации для обеспечения отрицаемости[44].

Шифрование сообщений

[править |править код]

Для шифрования сообщений используется алгоритмAES врежиме счётчика[45]. Использование построенного таким образомпоточного шифра обеспечиваетспорное шифрование (англ. malleable encryption). Это значит, что любой, кто перехватит сообщение, сможет выборочно изменить любые биты в сообщении. В частности, если сообщение стало известно, его можно изменить на любое другое сообщение такой же длины[46].

Спорное шифрование требуется для обеспечения отрицаемости шифрования[47]. Благодаря спорному шифрованию участники протокола OTR могут утверждать, что любое из переданных сообщений было изменено третьей стороной.

Многопользовательский OTR

[править |править код]

Протокол OTR разработан для использования только двумя сторонами. Таким образом, его невозможно использовать в каналахIRC, конференцияхXMPP и т. д.

OTR невозможно просто расширить для случая нескольких собеседников из-за используемых криптографических примитивов. Например,коды аутентификации сообщений не предоставляют аутентификации источника сообщений в многопользовательском случае[48].

Существуют расширения протокола, предоставляющие возможность использования протокола несколькими пользователями[49][50][51].

Одно из расширений протокола OTR, называемое GOTR (Group OTR), основано на идее создания «виртуального сервера»[52]. Один из участников назначается «виртуальным сервером», обменивается ключами с другими участниками и в дальнейшем все сообщения между участниками конференции пересылаются через него. Недостатком протокола GOTR является то, что «виртуальный сервер» может изменять содержание сообщений, добавлять и удалять сообщения, поэтому все участники конференции должны доверять ему[53].

Позже Иан Голдберг с другими авторами предложили протоколmpOTR[51]. В отличие от протокола GOTR, протокол mpOTR работает без выделенного центрального сервера[54].

Реализации OTR

[править |править код]
libotr
ТипБиблиотека
АвторыIan Goldberg[вд] и Nikita Borisov[вд]
РазработчикOTR Development Team
Написана наC
Аппаратная платформакроссплатформенная
Последняя версия4.1.1 (9 марта2016)
СостояниеАктуальный
ЛицензияGNU Lesser General Public License версии 2[55]
Сайтotr.cypherpunks.ca/index…

Основной реализацией OTR является библиотека libotr, созданная командой разработчиков OTR. На её основе теми же разработчиками созданплагин для клиентаPidgin, позволяющий использовать OTR с любым из протоколов, поддерживаемых этим клиентом. Также существуют реализации протокола на языкахGo,Java,JavaScript,Python,Scheme[56].

Поддержка в мессенджерах

[править |править код]

Встроенная поддержка

[править |править код]

Следующие клиенты имеют встроенную поддержку протокола OTR[57].

С использованием плагина

[править |править код]

Прокси

[править |править код]

Для клиентов, поддерживающих протоколAIM/ICQ, командой разработчиков OTR был разработан пакет otrproxy, представляющий собой локальныйпрокси-сервер[71]. Он позволял использовать OTR в клиентах, не имеющих собственной поддержки OTR. В настоящее время данный пакет не поддерживается, разработчики рекомендуют использовать клиенты с поддержкой OTR.

Примечания

[править |править код]
  1. ↑Surveillance Self-Defense: Instant Messaging (IM)  (неопр.). — «To protect messages from interception as they travel over the network, you need to use encryption. Fortunately, there is an excellent instant messaging encryption system called OTR (Off The Record).» Дата обращения: 22 октября 2013. Архивировано 13 октября 2013 года.
  2. ↑borisov2004off, 2004.
  3. ↑impauth, 2007, 2.1 Original OTR Protocol, p. 42: «The original OTR protocol was presented by Borisov, Goldberg, and Brewer in 2004».
  4. ↑di2005secure, 2005.
  5. ↑impauth, 2007, 2.3 OTR version 2, p. 43: «OTR version 2 was released in 2005. The largest change in version 2 was the reworking of the initial authenticated key exchange (AKE).».
  6. ↑mod_otr  (неопр.). Дата обращения: 20 октября 2013. Архивировано 29 сентября 2013 года.
  7. ↑impauth, 2007, 4. Socialist Millionaires’ Protocol, p. 44.
  8. ↑impauth, 2007, 2.1 Original OTR Protocol, p. 41: «The original OTR protocol was presented by Borisov, Goldberg, and Brewer in 2004. It was motivated by the idea of two people, say Alice and Bob, conversing face-to-face in a private room.».
  9. ↑goldberg2009multi, 2009, 1. Motivation, p. 359: «While this may be feasible under certain circumstances, it deviates from the original OTR goal, which is to mimic private conversations.».
  10. ↑borisov2004off, 2004, 1. Introduction, p. 77: «However, none of the mechanisms currently used for social communications have all of these properties.».
  11. ↑impauth, 2007, 2.1 Original OTR Protocol, p. 42: «To begin with, OTR uses a Diffie-Hellman (DH) key exchange to establish a shared secret between Alice and Bob.».
  12. ↑borisov2004off, 2004, 4.1 Encryption, p. 80.
  13. ↑borisov2004off, 2004, 3.1 Perfect forward secrecy, p. 78: «We circumvent this problem by using short-lived encryption/decryption keys that are generated as needed and discarded after use.».
  14. ↑impauth, 2007, 2.1 Original OTR Protocol, p. 42: «At this point Alice and Bob may begin sending each other encrypted messages. In order to limit the amount of information that is compromised if an adversary determines the shared key, Alice and Bob re-key as frequently as possible. ... This procedure gives OTR the property of perfect forward secrecy (PFS), ensuring that future key compromises cannot reveal the contents of old messages.».
  15. ↑borisov2004off, 2004, 4.2 Forgetting Keys, p. 80: «However, since messaging protocols are typically asynchronous, it is possible that there is still a message in transit from Bob that was encrypted using the previous key».
  16. ↑borisov2004off, 2004, 4.2 Forgetting Keys, p. 81: «To address this problem, Bob should periodically send an empty message acknowledging receipt of a new key from Alice.».
  17. ↑di2005secure, 2005, 6.3 On the Key Refreshing, p. 89: «Thus the value of performing a DH key exchange with each message where authentication depends on the previous shared key is of limited value.».
  18. ↑di2005secure, 2005, 6.3 On the Key Refreshing, p. 88: «We note however, that if the adversary learns the current ephemeral key, future messages may be completely compromised».
  19. ↑di2005secure, 2005, 6.3 On the Key Refreshing, p. 89: «This is even more so given the computational cost of a DH exchange.».
  20. ↑di2005secure, 2005, Thus we suggest that OTR will enjoy better overall security by running the AKE protocol at regular intervals. If a finer-grain refreshing mechanism is desired for forward-secrecy purposes, then a lighter, yet powerful, mechanism can be employed, such as deriving new keys (possibly on a per-message basis, if so desired) by one-way hashing the previous key., p. 89.
  21. ↑borisov2004off, 2004, 4.3 Authentication, p. 81: «We only need to use a digital signature on the initial key exchange. In further key exchanges, we use MACs to authenticate a new key using an old, known-authentic shared secret.».
  22. ↑impauth, 2007.
  23. ↑borisov2004off, 2004, 4.3 Authentication, p. 81: «The encryption key is itself the result of a hash of the Diffie-Hellman shared secret, which also needs to be authenticated in some way. We accomplish this by digitally signing the initial Diffie-Hellman exchange».
  24. ↑di2005secure, 2005, 3.1 An authentication failure, 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: «This attack allows an adversary Eve to interfere with the initial key exchange in suchway that Alice and Bob still reach the same key at the end of the protocol, but Alice believes that she is talking to Bob while Bob believes that he is talking to Eve.».
  27. ↑borisov2004off, 2004, 7. Related work, p. 83: «If anonymity is desired, one can use either SKEME or Abadi’s private authentication instead of the signed Diffie-Hellman key exchange inour protocol.».
  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 version 2, p. 43: «The largest change in version 2 was the reworking of the initial authenticated key exchange (AKE). In response to the attack mentioned above, the AKE waschanged to a SIGMA variant, as suggested.».
  31. ↑impauth, 2007, 2.3 OTR version 2, p. 43: «Where the public keys were formerly sent in the clear, they are now encrypted using the DH shared secret.».
  32. ↑impauth, 2007, 2.3 OTR version 2, p. 43: «The purpose of r in the above steps is to satisfy an engineering restriction: many IM protocols enforce a maximum size on messages.».
  33. ↑impauth, 2007, 2.3 OTR version 2, p. 43.
  34. ↑OTRv2.
  35. ↑OTRv3.
  36. ↑borisov2004off, 2004, 3.2 Digital signatures and non-repudiation, p. 79: «For this reason, we never use a digital signature to prove Alice’s authorship of any message.».
  37. ↑borisov2004off, 2004, 3.3 MACs and repudiability, p. 79.
  38. ↑impauth, 2007, 2.1 Original OTR Protocol, p. 42: «The MAC key used is a hash of the decryption key for that message.».
  39. ↑borisov2004off, 2004, 3.3 MACs and repudiability, p. 79: «Alice uses her copy of the MAC key to compute a MAC of her message, and sends this MAC along with her message in a secure transmission».
  40. ↑borisov2004off, 2004, 4.4 Revealing MAC keys, p. 81.
  41. ↑borisov2004off, 2004, 4.4 Revealing MAC keys, p. 81: «Note what this has accomplished: Bob doesn’t need to rely on this key any more, since he’s already checked all of the messages authenticated by that key. However, now anyone can create arbitrary messages that have this MAC key, and no one can rule out any particular person as a potential author of the message.».
  42. ↑di2005secure, 2005, 2.3 Encryption and authentication of messages, p. 84: «The reason behind the above choices (i.e., a malleable encryption and revealing the MAC keys) is deniability.».
  43. ↑di2005secure, 2005, 6.1 Repudiability of the symmetric encryption, p. 88: «Third, revealing the MAC keys does introduce timing and synchronization issues needed to prevent a too-early disclosure. While this is possible this results in added complexity to the system. While the above considerations may be seen as subjective to some extent, in the next subsection we illustrate the danger of adding non-standard security techniques.».
  44. ↑simpldeniability, Limitations.
  45. ↑di2005secure, 2005, 2.3 Encryption and authentication of messages, p. 83: «The message is first encrypted using AES in counter mode and then the resulting ciphertext is authenticated using HMAC (with hash function SHA-1).».
  46. ↑borisov2004off, 2004, 3.4 Malleable encryption and forgeability, p. 80: «This encryption is malleable, as a change to any bit in the ciphertext will correspond to a change in the corresponding bit in the plaintext. In particular, if Eve can guess the plaintext of a message, she can then change the ciphertext to decrypt to any other message of the same length, without knowing the key.».
  47. ↑di2005secure, 2005, The reason behind the above choices (i.e., a malleable encryption and revealing the MAC keys) is deniability., p. 84.
  48. ↑goldberg2009multi, 2009: «For example, OTR uses message authentication codes (MACs) to provide authenticity. While for two parties MACs can provide a deniable authentication mechanism, MACs do not provide origin authentication when used by more than two parties.».
  49. ↑bian2007off, 2007.
  50. ↑bian2007public, 2007.
  51. ↑12goldberg2009multi, 2009.
  52. ↑bian2007off, 2007, 3.1. Initial Design, p. 81: «The main concept of our implementation is to create a virtual server, which is a chat member literally acting as a server.».
  53. ↑goldberg2009multi, 2009, 1. Motivation, p. 359: «Finally, the server has to be assumed honest, as a dishonest server could compromise both the confidentiality and the integrity of all messages sent during a chat session.».
  54. ↑goldberg2009multi, 2009, 5. Conclusion, p. 367: «Our proposed framework for multi-party Off-the-Record communication does not depend on a central server; instead we developed a model that mimics a typical private meeting where each user authenticates the other participants for himself.».
  55. ↑Off-the-Record Messaging  (неопр.). Дата обращения: 10 ноября 2013. Архивировано 17 августа 2014 года.
  56. ↑Libraries that support OTR  (неопр.). Дата обращения: 10 ноября 2013. Архивировано 10 ноября 2013 года.
  57. ↑https://otr.cypherpunks.ca/software.phpАрхивная копия от 10 ноября 2013 наWayback Machine IM clients which support Off-the-Record Messaging «out of the box»
  58. ↑Get OTR to work with bitlbee  (неопр.). Дата обращения: 10 ноября 2013. Архивировано 20 ноября 2013 года.
  59. ↑OTR плагин  (неопр.). Дата обращения: 6 сентября 2017. Архивировано 13 июня 2019 года.
  60. ↑Psi+ snapshots
  61. ↑OTR плагин  (неопр.). Дата обращения: 23 апреля 2014. Архивировано 11 января 2016 года.
  62. ↑Краткое описание  (неопр.). Дата обращения: 23 апреля 2014. Архивировано 24 апреля 2014 года.
  63. ↑Исходный кодАрхивировано 17 мая 2014 года.
  64. ↑Согласно описанию наофициальном сайтеАрхивная копия от 9 апреля 2022 наWayback Machine
  65. ↑Официальный OTR плагин для Gajim  (неопр.). Дата обращения: 6 сентября 2017. Архивировано изоригинала 6 сентября 2017 года.
  66. ↑OTR плагин на Wiki  (неопр.). Дата обращения: 6 сентября 2017. Архивировано 6 сентября 2017 года.
  67. ↑Home of irssi-otr and xchat-otr  (неопр.). Дата обращения: 10 ноября 2013. Архивировано 10 ноября 2013 года.
  68. ↑Плагин OTR дляMiranda IMАрхивировано 13 мая 2007 года.
  69. ↑Additional plugins for Vacuum-IM project  (неопр.). Дата обращения: 24 октября 2010. Архивировано 23 мая 2011 года.
  70. ↑Tkabber OTR PluginАрхивировано 11 марта 2014 года.
  71. ↑OTR localhost AIM proxy  (неопр.). Дата обращения: 10 ноября 2013. Архивировано 12 апреля 2018 года.

Литература

[править |править код]

Ссылки

[править |править код]
Источник —https://ru.wikipedia.org/w/index.php?title=Off-the-Record_Messaging&oldid=139005258
Категории:
Скрытые категории: