Off-the-Record Messaging

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

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$ и генератор $g$ группы $\mathbb {Z} _{p}^{*}$ . A выбирает случайное число $a_{1}$ и отправляет B результат вычисления $g^{a_{1}}{\bmod {p}}$ . B выбирает случайное число $b_{1}$ и отправляет A результат вычисления $g^{b_{1}}{\bmod {p}}$ . Затем участники используют общий эфемерный ключ $k_{11}=H(g^{a_{1}b_{1}})$ , где $H$ — криптографическая хеш-функция SHA-1^[12].

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

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

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

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

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

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

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

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

A\longrightarrow B\colon S_{A}(g^{a_{1}}),P_{A}

B\longrightarrow A\colon S_{B}(g^{b_{1}}),P_{B}

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

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

A\longrightarrow E\colon S_{A}(g^{a_{1}}),P_{A}

E\longrightarrow B\colon S_{E}(g^{a_{1}}),P_{E}

B\longrightarrow E\colon S_{B}(g^{b_{1}}),P_{B}

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\longrightarrow B\colon g^{a}

B\longrightarrow A\colon g^{b}

A\longrightarrow B\colon {\text{A}},S_{A}(g^{b},g^{a}),MAC_{H(g^{ab})}(0,{\text{A}}),P_{A}

B\longrightarrow A\colon {\text{B}},S_{B}(g^{a},g^{b}),MAC_{H(g^{ab})}(1,{\text{B}}),P_{B}

Здесь A и B — идентификаторы, $S_{A}$ и $S_{B}$ — цифровые подписи, $P_{A}$ и $P_{B}$ — открытые ключи сторон A и B соответственно, а $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

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

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

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

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

Adium
BitlBee^[58]
climm
ChatSecure
Conversations Legacy
IM+
Jitsi
Xabber
Psi и Psi+ (плагин)^[59]^[60]
LeechCraft^[61]^[62]
MCabber^[63]
Profanity^[64]
Gajim^[65]^[66]

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

irssi^[67]
Miranda IM^[68]
Pidgin
Vacuum-IM (плагин)^[69]
Kopete
Tkabber (плагин)^[70]

Прокси

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

Примечания

↑ 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 года.
↑ borisov2004off, 2004.
↑ impauth, 2007, 2.1 Original OTR Protocol, p. 42: «The original OTR protocol was presented by Borisov, Goldberg, and Brewer in 2004».
↑ di2005secure, 2005.
↑ 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).».
↑ mod_otr (неопр.). Дата обращения: 20 октября 2013. Архивировано 29 сентября 2013 года.
↑ impauth, 2007, 4. Socialist Millionaires’ Protocol, p. 44.
↑ 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.».
↑ 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.».
↑ borisov2004off, 2004, 1. Introduction, p. 77: «However, none of the mechanisms currently used for social communications have all of these properties.».
↑ 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.».
↑ borisov2004off, 2004, 4.1 Encryption, p. 80.
↑ 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.».
↑ 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.».
↑ 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».
↑ 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.».
↑ 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.».
↑ 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».
↑ di2005secure, 2005, 6.3 On the Key Refreshing, p. 89: «This is even more so given the computational cost of a DH exchange.».
↑ 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.
↑ 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.».
↑ impauth, 2007.
↑ 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».
↑ di2005secure, 2005, 3.1 An authentication failure, p. 84.
↑ impauth, 2007, 2.2 Attack on OTR version 1, p. 42.
↑ 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.».
↑ 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 in our protocol.».
↑ di2005secure, 2005, 4. Building A Sound AKE For OTR, p. 85.
↑ di2005secure, 2005, 4.1 SIGMA, p. 85.
↑ 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 was changed to a SIGMA variant, as suggested.».
↑ 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.».
↑ 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.».
↑ impauth, 2007, 2.3 OTR version 2, p. 43.
↑ OTRv2.
↑ OTRv3.
↑ 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.».
↑ borisov2004off, 2004, 3.3 MACs and repudiability, p. 79.
↑ impauth, 2007, 2.1 Original OTR Protocol, p. 42: «The MAC key used is a hash of the decryption key for that message.».
↑ 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».
↑ borisov2004off, 2004, 4.4 Revealing MAC keys, p. 81.
↑ 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.».
↑ 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.».
↑ 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.».
↑ simpldeniability, Limitations.
↑ 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).».
↑ 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.».
↑ di2005secure, 2005, The reason behind the above choices (i.e., a malleable encryption and revealing the MAC keys) is deniability., p. 84.
↑ 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.».
↑ bian2007off, 2007.
↑ bian2007public, 2007.
↑ ¹ ² goldberg2009multi, 2009.
↑ 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.».
↑ 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.».
↑ 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.».
↑ Off-the-Record Messaging (неопр.). Дата обращения: 10 ноября 2013. Архивировано 17 августа 2014 года.
↑ Libraries that support OTR (неопр.). Дата обращения: 10 ноября 2013. Архивировано 10 ноября 2013 года.
↑ https://otr.cypherpunks.ca/software.php Архивная копия от 10 ноября 2013 на Wayback Machine IM clients which support Off-the-Record Messaging «out of the box»
↑ Get OTR to work with bitlbee (неопр.). Дата обращения: 10 ноября 2013. Архивировано 20 ноября 2013 года.
↑ OTR плагин (неопр.). Дата обращения: 6 сентября 2017. Архивировано 13 июня 2019 года.
↑ Psi+ snapshots
↑ OTR плагин (неопр.). Дата обращения: 23 апреля 2014. Архивировано 11 января 2016 года.
↑ Краткое описание (неопр.). Дата обращения: 23 апреля 2014. Архивировано 24 апреля 2014 года.
↑ Исходный код Архивировано 17 мая 2014 года.
↑ Согласно описанию на официальном сайте Архивная копия от 9 апреля 2022 на Wayback Machine
↑ Официальный OTR плагин для Gajim (неопр.). Дата обращения: 6 сентября 2017. Архивировано из оригинала 6 сентября 2017 года.
↑ OTR плагин на Wiki (неопр.). Дата обращения: 6 сентября 2017. Архивировано 6 сентября 2017 года.
↑ Home of irssi-otr and xchat-otr (неопр.). Дата обращения: 10 ноября 2013. Архивировано 10 ноября 2013 года.
↑ Плагин OTR для Miranda IM Архивировано 13 мая 2007 года.
↑ Additional plugins for Vacuum-IM project (неопр.). Дата обращения: 24 октября 2010. Архивировано 23 мая 2011 года.
↑ Tkabber OTR Plugin Архивировано 11 марта 2014 года.
↑ OTR localhost AIM proxy (неопр.). Дата обращения: 10 ноября 2013. Архивировано 12 апреля 2018 года.

Литература

Borisov N., Goldberg I., Brewer E. Off-the-record communication, or, why not to use PGP (англ.) // Proceedings of the 2004 ACM workshop on Privacy in the electronic society. — 2004. — P. 77—84. — ISBN 1-58113-968-3. — doi:10.1145/1029179.1029200.
Di Raimondo, Mario and Gennaro, Rosario and Krawczyk, Hugo. Secure off-the-record messaging (англ.) // Proceedings of the 2005 ACM workshop on Privacy in the electronic society. — 2005. — P. 81—89. — ISBN 1-59593-228-3. — doi:10.1145/1102199.1102216.
Alexander, Chris and Goldberg, Ian. Improved user authentication in off-the-record messaging (англ.) // Proceedings of the 2007 ACM workshop on Privacy in electronic society. — 2007. — P. 41—47. — ISBN 1-58113-968-3. — doi:10.1145/1029179.1029200.
Stedman, Ryan and Yoshida, Kayo and Goldberg, Ian. A user study of off-the-record messaging (англ.) // Proceedings of the 4th symposium on Usable privacy and security. — 2008. — P. 95—104. — ISBN 978-1-60558-276-4. — doi:10.1145/1408664.1408678.
Bian, Jiang and Seker, Remzi and Topaloglu, Umit. Off-the-Record Instant Messaging for Group Conversation (англ.) // Information Reuse and Integration, 2007. IRI 2007. IEEE International Conference on. — 2007. — P. 79—84. — ISBN 1-4244-1500-4. — doi:10.1109/IRI.2007.4296601. Архивировано 22 октября 2013 года.

Bian, Jiang and Seker, Remzi. Off-the-Record Secure Chat Room via Public IM Services (англ.) // Masters Abstracts International. — 2007. — P. 46. (недоступная ссылка)
Goldberg, Ian and Ustaoğlu, Berkant and Van Gundy, Matthew D and Chen, Hao. Multi-party off-the-record messaging (англ.) // Proceedings of the 16th ACM conference on Computer and communications security. — 2009. — P. 358—368. — ISBN 978-1-60558-894-0. — doi:10.1145/1653662.1653705.
Joseph Bonneau, Andrew Morrison. Finite-State Security Analysis of OTR Version 2 (англ.). — 2006. — doi:10.1.1.165.7945.

Ссылки

Официальная страница OTR
Off-the-Record Messaging Protocol version 2 (англ.). Дата обращения: 10 ноября 2013.
Off-the-Record Messaging Protocol version 3 (англ.). Дата обращения: 10 ноября 2013.
Simplifying OTR deniability (англ.). Дата обращения: 28 ноября 2013.
Слайды презентации OTR на CodeCon в 2006 году
Слайды презентации OTR на WPES в 2004 году
Off-The-Record messaging на www.cypherpunks.ru

[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 года.

[_00c8507caffb2cd2-2] risov2004off, 2004.

[_13434a1f2b9750a7-3] uth, 2007, 2.1 Original OTR Protocol, p. 42: «The original OTR protocol was presented by Borisov, Goldberg, and Brewer in 2004».

[_7622dd8f7b99a6a1-4] 2005secure, 2005.

[_0b58199b7aff49b9-5] uth, 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] _otr (неопр.). Дата обращения: 20 октября 2013. Архивировано 29 сентября 2013 года.

[_ce6e61e6b4289180-7] uth, 2007, 4. Socialist Millionaires’ Protocol, p. 44.

[_81103606b99a2ae6-8] uth, 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.».

[_62ba63a5644e020a-9] rg2009multi, 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.».

[_ee7d665b41fc4b41-10] risov2004off, 2004, 1. Introduction, p. 77: «However, none of the mechanisms currently used for social communications have all of these properties.».

[_fc91a8432b9d94a7-11] uth, 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.».

[_5d9f116e90642f90-12] risov2004off, 2004, 4.1 Encryption, p. 80.

[_ffe1fd6fd2c10775-13] risov2004off, 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.».

[_e67bacd9a7de3df9-14] uth, 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.».

[_d5d2ad2b92f88004-15] risov2004off, 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».

[_9ebe29ebe9e08286-16] risov2004off, 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.».

[_29756cabc92368b1-17] 2005secure, 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.».

[_fcc6d1bc0975a33c-18] 2005secure, 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».

[_a6cd6a0823a52a30-19] 2005secure, 2005, 6.3 On the Key Refreshing, p. 89: «This is even more so given the computational cost of a DH exchange.».

[_5019c762d9cc35b0-20] 2005secure, 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.

[_eaaa24df42fedbfe-21] risov2004off, 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.».

[_0d264795aae1a806-22] uth, 2007.

[_982db10815de5d25-23] risov2004off, 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».

[_cb0d173dfa32e258-24] 2005secure, 2005, 3.1 An authentication failure, p. 84.

[_45ec19c3ab6ba34f-25] uth, 2007, 2.2 Attack on OTR version 1, p. 42.

[_f9c64800261d45ce-26] risov2004off, 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.».

[_76add02f13bc92f7-27] risov2004off, 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 in our protocol.».

[_0e1f0138a38c98f7-28] 2005secure, 2005, 4. Building A Sound AKE For OTR, p. 85.

[_3b1ab32ce194f824-29] 2005secure, 2005, 4.1 SIGMA, p. 85.

[_723196fcd2e43420-30] uth, 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 was changed to a SIGMA variant, as suggested.».

[_e88055697096b2a8-31] uth, 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.».

[_899a364edd68cb22-32] uth, 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.».

[_fd05fc5f9bb35b49-33] uth, 2007, 2.3 OTR version 2, p. 43.

[_debca607a2c07958-34] OTRv2.

[_28b2baa8ba00fd23-35] OTRv3.

[_2246ecc1bbca9004-36] risov2004off, 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.».

[_e8adfc926f5f600c-37] risov2004off, 2004, 3.3 MACs and repudiability, p. 79.

[_8f258b8e0410a061-38] uth, 2007, 2.1 Original OTR Protocol, p. 42: «The MAC key used is a hash of the decryption key for that message.».

[_c978bb314a45392c-39] risov2004off, 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».

[_11cf1206965f2bd5-40] risov2004off, 2004, 4.4 Revealing MAC keys, p. 81.

[_ba83c2568a0c78f5-41] risov2004off, 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.».

[_54249d49851957e4-42] 2005secure, 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.».

[_326b442efc0dc23f-43] 2005secure, 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.».

[_dd0ae295bcfc119d-44] simpldeniability, Limitations.

[_26c8b09af7a2f3fc-45] 2005secure, 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).».

[_fa5e86f547a1bd54-46] risov2004off, 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.».

[_bdb1bb3a0a8d155a-47] 2005secure, 2005, The reason behind the above choices (i.e., a malleable encryption and revealing the MAC keys) is deniability., p. 84.

[_b15e102a11729513-48] rg2009multi, 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.».

[_76edfd8703c727b4-49] 2007off, 2007.

[_8b79c502f8d02060-50] 2007public, 2007.

[_0e979b0ca60a3dde-51] ¹ ² goldberg2009multi, 2009.

[_f507d1f4d8df36c2-52] 2007off, 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.».

[_fd10da6b6d000d2f-53] rg2009multi, 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.».

[_c8c6551399ec9f3a-54] rg2009multi, 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] ttps://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 года.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]

[25]

[26]

[27]

[28]

[29]

[30]

[31]

[32]

[33]

[34]

[35]

[36]

[37]

[38]

[39]

[40]

[41]

[42]

[43]

[44]

[45]

[46]

[47]

[48]

[49]

[50]

[51]

[52]

[53]

[54]

[55]

[56]

[57]

[58]

[59]

[60]

[61]

[62]

[63]

[64]

[65]

[66]

[67]

[68]

[69]

[70]

[71]