# Off-the-Record Messaging

Off-the-Record Messaging (OTR) é um protocolo de criptografia que fornece a encriptação de conversas de mensagens instantâneas. O OTR usa uma combinação de algoritmo AES de chave simétrica com chave de 128 bits de comprimento, o grupo Diffie–Hellman de troca de chaves com tamanho de 1536 bits e a função hash SHA-1. Além de autenticação e criptografia, o OTR proporciona sigilo e criptografia maleável.
A motivação principal por trás do protocolo foi fornecer autenticação negável para os participantes de conversação, mantendo conversas confidenciais, como uma conversa privada na vida real, ou desativar o registro em fonte (jornalismo). Isto está em contraste com ferramentas de criptografia que produzem uma saída, que pode ser usada mais tarde como um certificado de registro de evento de comunicação e as identidades dos participantes. Seu slogan inicial era "Comunicação Off-the-Record", ou "Por que Não Usar o PGP".
O protocolo OTR foi projetado pelos criptógrafos Ian Goldberg e Nikita Borisov e lançado em 26 de outubro de 2004. Eles fornecem um biblioteca de cliente para facilitar o suporte para desenvolvedores de cliente de mensagens instantâneas que desejam implementar o protocolo. Existe um plug-in para Pidgin e Kopete, que permite usar o OTR em qualquer protocolo de IM nesses clientes, oferecendo uma autodetecção de função, que inicia a sessão OTR com os amigos que tem ativado, sem interferir com as conversas não criptografada regulares.

## História

O OTR foi apresentado em 2004 por Nikita Borisov, Ian Avrum Goldberg e Eric A. Brewer como uma melhoria sobre o OpenPGP e o sistema S/MIME no "Workshop sobre Privacidade na Sociedade Electrónica" (WPES). A primeira versão 0.8.0 da implementação de referência foi publicada em 21 de novembro de 2004. Em 2005, uma análise foi apresentada por Mario Di Raimondo, Rosario Gennaro e Hugo Krawczyk, que chamou a atenção para diversas vulnerabilidades e propostas de correções apropriadas, nomeadamente, incluindo uma falha na troca de chaves. Como resultado, a versão 2 do protocolo OTR foi publicada em 2005, que implementa uma variação da proposta de modificação, que também esconde as chaves públicas. Além disso, a possibilidade de fragmento de mensagens OTR foi introduzida a fim de lidar com sistemas de chat que têm limitações de tamanho de mensagem; e um método mais simples de verificação contra os ataques man-in-the-middle foi implementado.
Em 2007, Olivier Goffart publicou o mod_otr para ejabberd, tornando-se possível realizar ataques man-in-the-middle em usuários OTR que não verificam a chave de impressões digitais. Os desenvolvedores do OTR anularam este ataque, introduzindo o "protocolo do socialista milionário", implementado em libotr. Em vez de realizar a verificação por comparação de soma de chaves, o conhecimento de um segredo arbitrário compartilhado pode ser utilizado, para o qual uma entropia relativamente baixa pode ser tolerada, usando o "protocolo do socialista milionário".
A versão 3 do protocolo foi publicada em 2012, como uma medida contra o reestabelecimento repetido de uma sessão, no caso de vários clientes de bate-papo concorrentes serem acessados no mesmo endereço do usuário, ao mesmo tempo. A identificação mais precisa de etiquetas para envio e recebimento de instâncias de cliente foi introduzida na versão 3. Além disso, uma chave adicional é negociada, o que pode ser usado para outro canal de dados.
Muitas soluções têm sido propostas para suportar conversações com múltiplos participantes. Um método proposto em 2007 por Jiang Bian, Remzi Seker e Umit Topaloglu usa o sistema de um participante como um "servidor virtual". O método chamado Multi-party Off-the-Record Messaging (mpOTR), que foi publicado em 2009, funciona sem um gerente anfitrião central; e foi introduzido no Cryptocat por Ian Goldberg et al.. Em 2013, o Protocolo Signal foi introduzido, que é baseado no OTR Messaging e no Silent Circle Instant Messaging Protocol (SCIMP). Ele trouxe suporte para comunicação assíncrona ("mensagens offline") como sua maior característica nova, tão boa quanto a melhor resiliência, com mensagens de ordem distorcida e suporte mais simples para conversação com múltiplos participantes. OMEMO introduziu em um cliente XMPP para Android, chamado Conversations, em 2015, integra o algoritmo Double Ratchet, usado no Signal, no protocolo XMPP (Jabber) de mensageiro instantâneo; e também habilita a criptografia de transferência de arquivos. No outono (do hemisfério norte) de 2015, foi submetido à XMPP Standards Foundation para padronização.

## Implementação

Além de prover criptografia e autenticação — características também fornecidas por suítes de chave-pública típicas, tais como PGP, GnuPG, e X.509 (S/MIME) — o OTR também oferece algumas características menos comuns:
* Forward secrecy: Mensagens são criptografadas somente com chaves AES temporárias por mensagem, negociadas usando o protocolo de troca de chaves Diffie-Hellman. O compromisso de qualquer chave de "criptografia de longa vida" não compromete qualquer conversa prévia, mesmo se um atacante tiver posse do texto cifrado.
* Autenticação negável: Mensagens em uma conversa não tem assinaturas digitais; e depois que uma conversa está completa, qualquer um é apto a forjar uma mensagem para parecer ter vindo de um dos participantes da conversa, assegurando que é impossível provar que uma mensagem específica veio de uma pessoa específica. Dentro da conversa, o destinatário pode ter certeza que uma mensagem está vindo da pessoa que eles identificaram.

## Autenticação

Como no OTR 3.1, o protocolo suporta autenticação mútua de usuários, usando um segredo compartilhado pelo "protocolo do socialista milionário". Esta característica torna possível para usuários verificar a identidade da parte remota; e evita um ataque man-in-the-middle, sem o inconveniente de comparar manualmente a public key fingerprints através de um canal externo.

## Limitações

Devido a limitações do protocolo, o OTR não suporta bate-papos em grupos multiusuário a partir de 2009, mas isso pode ser implementado no futuro. A partir da versão 3 da especificação do protocolo, uma chave simétrica extra é derivada durante as trocas de chaves autenticadas que podem ser usadas para comunicação segura (e.g., transferências de arquivos criptografados) sobre um canal diferente. O suporte para áudio ou vídeo criptografado não está nos planos (SRTP com ZRTP existe para esse propósito). Um projeto de produção de um protocolo para mensagens multi-party off-the-record (mpOTR) tem sido organizado pelo Cryptocat, eQualitie, e outros contribuintes, inclusive Ian Goldberg.
Desde o protocolo OTR v3 (libotr 4.0.0) o plug-in suporta múltiplas conversas OTR com o mesmo friend conversations, que está logado em múltiplas localidades.

## Suporte a clientes
### Nativo

Estes clientes suportam mensagens Off-the-Record out of the box.
* Gajim (cross-platform)
* Adium (OS X)
* Blink SIP client (OS X)
* BitlBee (cross-platform), desde 3.0 (opcional na compilação)
* CenterIM (Unix-like), desde 4.22.2
* ChatSecure (iOS)
* Zom Mobile Messenger (Android)
* climm (Unix-like), desde (mICQ) 0.5.4
* Conversations (Android)
* IronChat, baseadi no Xabber (Android)
* Jitsi (cross-platform)
* Kadu (software) (cross-platform), since 1.0
* Kopete (Unix-like)
* LeechCraft (cross-platform)
* MCabber (Unix-like), since 0.9.4
* Profanity, desde 0.4.1
* Psi (cross-platform)
* Psi+ (cross-platform)
* Textual 5 (OS X), desde 5.1.2
* Xabber (Android)

### Via plug-in

Os seguintes clientes requerem um plug-in para usar mensagens Off-the-Record.
* irssi e X-Chat, com um plug-in de terceiros
* Miranda IM (Microsoft Windows), com um plug-in de terceiros
* Pidgin (cross-platform), com um plug-in disponível na homepage do OTR homepage
* Tkabber (cross-platform, desde a versão 1.1), com um plug-in dos desenvolvedores do Tkabber
* WeeChat, com um plug-in de terceiros
* HexChat, para versões *nix, com um plug-in de terceiros

### Não no Google Talk

Embora o Google Talk do Gmail use o termo off the record, as características não têm conexão com o protocolo de mensagens Off-the-Record descrito neste artigo, pois seus bate-papos não são criptografados do modo descrito acima - e poderia ser logado internamente pela Google, mesmo se não estiver acessível pelos usuários finais.