Este artigo sobre a cifra de extremo a extremo do MTProto destina-se a utilizadores avançados.Se você quiser saber mais sobre conversas secretas de uma fonte menos intimidante, por favor, veja nossa FAQ geral.

Note que, a partir da versão 4.6, os principais clientes de telegrama estão usando MTProto 2.0.O MTProto v. 1. 0 está desactualizado e está actualmente a ser gradualmente eliminado.

Secret Chats are one-on-one chats wherein messages are encrypted with a key held only by the chat’s participants. Observe que o esquema para estes end-to-end encriptado Segredo bate-Papos é diferente do que é utilizado para a nuvem chats:

Uma nota sobre MTProto 2.0

Este artigo descreve o fim-a-fim camada de criptografia no MTProto protocol versão 2.0.As principais diferenças da versão 1.0 (descrita aqui para referência) são as seguintes:

• SHA-256 é usado em vez de SHA-1;
• os ‘bytes’ de preenchimento estão envolvidos no cálculo do msg_key;
• msg_key depende não só da mensagem a ser cifrada, mas também de uma parte da chave secreta de conversação;
• 12..1024 bytes de enchimento são usados em vez de 0..15 bytes de enchimento no v. 1. 0.

See also: MTProto 2.0: Cloud Chats, server-client encryption

Key Generation

Keys are generated using the Diffie-Hellman protocol.consideremos o seguinte cenário: o utilizador A gostaria de iniciar uma comunicação cifrada extremo-a-extremo com o utilizador B.

enviar um pedido

o utilizador a executa mensagens.getDhConfig to obtain the Diffie-Hellman parameters: a prime p, and a high order element G.

Executing this method before each new key generation procedure is of vital importance. Faz sentido cache os valores dos parâmetros juntamente com a versão, a fim de evitar ter que receber todos os valores de cada vez. Se a versão armazenada no cliente ainda estiver atualizada, o servidor retornará as mensagens do construtor.dhconfignotmodificado.

o Cliente deve verificar se p é um seguro de 2048 bits prime (o que significa que tanto a p e (p-1)/2 são os mais importantes, e que 2^2047 < p < 2^2048), e que g gera um subgrupo cíclico de primeira ordem (p-1)/2, por exemplo, é um resíduo quadrático mod p. Desde que g é sempre igual a 2, 3, 4, 5, 6 ou 7, isso é facilmente feito usando curvas quadráticas de reciprocidade lei, produzindo uma simples condição mod p 4g — ou seja, p mod 8 = 7 para g = 2; p mod 3 = 2 g = 3; nenhum extra condição para g = 4; p mod 5 = 1 ou 4 para g = 5; p mod 24 = 19 ou 23 para g = 6; e p mod 7 = 3, 5 ou 6 para g = 7. Depois que g E p foram verificados pelo cliente, faz sentido cache o resultado, de modo a evitar repetições longas computações no futuro. Este cache pode ser compartilhado com um usado para geração de Chaves de autorização.

Se o cliente tem uma visão inadequada do gerador de número aleatório, faz sentido passar a random_length parâmetro (random_length> 0) de modo que o servidor gera a sua própria sequência aleatória aleatória de tamanho apropriado.Importante: usar a sequência aleatória do servidor na sua forma raw pode não ser Seguro. Deve ser combinado com uma sequência cliente, por exemplo, gerando um número aleatório cliente do mesmo comprimento (client_random) e usando final_random := random XOR client_random.

cliente A calcula um número de 2048 bits a (usando entropia suficiente ou o Aleatório do servidor; veja acima) e executa mensagens.requestEncryption after passing in g_a := pow(g, a) mod dh_prime.

O utilizador B recebe a actualização da actualização para todas as chaves de autorização associadas (todos os dispositivos autorizados) com o construtor de conversação encriptado requisitado. O Usuário deve ser mostrado informação básica sobre o usuário A e deve ser solicitado a aceitar ou rejeitar o pedido.ambos os clientes devem verificar se g, g_a e g_b são maiores que um e menores que p-1. Nós recomendamos verificar que g_a e g_b estão entre 2^{2048-64} e p – 2^{2048-64} também.

aceitando um pedido

após o utilizador B confirmar a criação de uma conversa secreta com A na interface do cliente, o cliente B também recebe parâmetros de configuração actualizados para o método Diffie-Hellman. A partir daí, ele gera um número aleatório de 2048 bits, b, usando regras similares àquelas para A.

tendo recebido g_a da actualização com encriptação solicitada, pode imediatamente gerar a chave final partilhada: key = (pow(g_a, b) mod dh_prime). If key length < 256 bytes, add several leading zero bytes as padding — so that the key is exactly 256 bytes long. Sua impressão digital, key_fingerprint, é igual aos 64 últimos bits de SHA1 (chave). Nota 1: Neste caso particular, SHA1 é usado aqui mesmo para conversas secretas MTProto 2.0. Nota 2: esta impressão digital é usada como uma verificação de sanidade para o procedimento de troca de chaves para detectar bugs ao desenvolver software cliente — não está conectada à visualização de chaves usada nos clientes como meio de autenticação externa em conversas secretas. Visualizações chave nos clientes são geradas usando os primeiros 128 bits de SHA1(chave inicial) seguido pelos primeiros 160 bits de SHA256 (chave usada quando o Chat Secreto foi atualizado para a camada 46).o cliente B executa mensagens.acceptEncryption after passing it g_b := pow(g, b) mod dh_prime and key_fingerprint.

para todos os dispositivos autorizados do cliente B, exceto o atual, atualizações de atualização são enviadas com o construtor encryptedChatDiscarded. Depois disso, o único dispositivo que será capaz de acessar o chat Secreto é o dispositivo B, que fez a chamada para as mensagens.acceptEncryption.o

utilizador a será enviado uma actualização da cifra de actualização com o codificador do construtor, para a chave de autorização que iniciou a conversação.

com g_b a partir da atualização, O Cliente a também pode computar a chave compartilhada key = (pow(g_b, a) mod dh_prime). If key length < 256 bytes, add several leading zero bytes as padding — so that the key is exactly 256 bytes long. Se a impressão digital da chave recebida for idêntica à que foi passada para encryptedChat, as mensagens recebidas podem ser enviadas e processadas. Caso contrário, mensagens.o discardEncryption deve ser executado e o utilizador notificado.

Perfect Forward Secrecy

a fim de manter o passado de comunicação seguro, oficial Telegrama clientes iniciará re-keying uma vez que uma tecla tenha sido usada para descriptografar e criptografar mensagens de mais de 100, ou esteve em uso por mais de uma semana, desde que a chave foi usada para criptografar pelo menos uma mensagem. As teclas antigas são então descartadas de forma segura e não podem ser reconstruídas, mesmo com o acesso às novas teclas actualmente em uso.

o protocolo de re-keying é descrito neste artigo: segredo avançado perfeito em conversas secretas.

por favor, note que o seu cliente deve apoiar o envio de sigilo em conversas secretas para ser compatível com os clientes oficiais de telegrama.

enviar e receber mensagens num Chat secreto

serialização e cifragem das mensagens enviadas

um objecto TL do tipo descodificado é criado e contém a mensagem em texto simples. Para a compatibilidade reversa, o objeto deve ser embrulhado no construtor decriptadomessagelayer com uma indicação da camada suportada (começando com 46).

O TL-Esquema para o conteúdo end-to-end mensagens criptografadas está disponível aqui “

A construção resultante é serializado como uma matriz de bytes usando genérico TL regras. O array resultante é preparado por 4 bytes contendo o comprimento do array não contando esses 4 bytes.

a matriz de bytes é acolchoada com 12 a 1024 bytes de acolchoamento aleatório para tornar o seu comprimento divisível por 16 bytes. (Na antiga criptografia MTProto 1.0, apenas 0 a 15 bytes de enchimento foram usados.)

chave de mensagem, msg_key, é calculada como os 128 bits do meio do SHA256 dos dados obtidos na etapa anterior, pré-adicionados por 32 bytes da chave partilhada. (Para a antiga criptografia MTProto 1.0, msg_key foi computada de forma diferente, como os 128 bits inferiores de SHA1 dos dados obtidos nas etapas anteriores, excluindo os bytes de preenchimento.)

para MTProto 2.0, a chave AES aes_key e o vetor de inicialização aes_iv são computados (chave é a chave partilhada obtida durante a geração de chaves) do seguinte modo:

• msg_key_large = SHA256 (substr (chave, 88+x, 32) + texto simples + random_padding);
• msg_key = substr (msg_key_large, 8, 16);
• sha256_a = SHA256 (msg_key + substr (chave, x, 36));
• sha256_b = SHA256 (substr (de chave, de 40+x, 36) + msg_key);
• aes_key = substr (sha256_a, 0, 8) + substr (sha256_b, 8, 16) + substr (sha256_a, 24, 8);
• aes_iv = substr (sha256_b, 0, 8) + substr (sha256_a, 8, 16) + substr (sha256_b, 24, 8);

Para MTProto 2.0, x=0 para mensagens do originador, do segredo de bate-papo, x=8 para as mensagens na direção oposta.

para o obsoleto MTProto 1.0, msg_key, aes_key, e aes_iv foram computados de forma diferente (veja este documento para referência).

dados são criptografados com uma chave de 256 bits, aes_key, e um vetor de inicialização de 256 bits, aes-iv, usando criptografia AES-256 com extensão garble infinita (IGE). A chave de cifra impressões digitais key_ Fingerprint e a chave de mensagem msg_key são adicionadas no topo da lista de bytes resultante.os dados encriptados estão incorporados em mensagens.sendEncrypted API call and passed to Telegram server for delivery to the other party of The Secret Chat.

modernização para MTProto 2.0 a partir de MTProto 1.0

assim que ambas as partes numa conversa secreta estiverem a usar pelo menos a camada 73, devem usar apenas o MTProto 2.0 para todas as mensagens enviadas. Algumas das primeiras mensagens recebidas podem usar MTProto 1.0, se uma camada inicial suficientemente alta não tiver sido negociada durante a criação do chat secreto. Após a primeira mensagem criptografada com MTProto 2.0 (ou a primeira mensagem com a camada 73 ou superior) é recebida, todas as mensagens com números de sequência mais elevados devem ser criptografadas com MTProto 2.0 também.

desde que a camada actual seja inferior a 73, cada parte deve tentar descodificar as mensagens recebidas com o MTProto 1.0, e se isto não for bem sucedido (o msg_key não corresponde), tente o MTProto 2.0. Uma vez que a primeira mensagem criptografada MTProto 2.0 chega (ou a camada é atualizada para 73), Não há necessidade de tentar a decriptação MTProto 1.0 para qualquer uma das outras mensagens (a menos que o cliente ainda está esperando algumas lacunas para serem fechadas).

descriptografar uma mensagem recebida

os passos acima são realizados em ordem inversa. Quando uma mensagem cifrada é recebida, você deve verificar se o msg_key é, de facto, igual aos 128 bits do meio do hash SHA256 da mensagem descodificada, antecedida por 32 bytes retirados da chave partilhada.Se a camada de mensagem é maior do que a suportada pelo cliente, o Usuário deve ser notificado de que a versão do cliente está fora de data e solicitado a atualizar.

números de sequência

é necessário interpretar todas as mensagens na sua ordem original para proteger contra possíveis manipulações. Chats Secretos suportam um mecanismo especial para lidar com contadores seq_no independentemente do servidor.

a manipulação correcta destes contadores é descrita neste artigo: números de sequência em conversas secretas.

Por Favor, note que o seu cliente deve suportar números de sequência em conversas secretas para ser compatível com clientes oficiais de telegrama.

a enviar ficheiros encriptados

todos os ficheiros enviados para conversas secretas são encriptados com chaves únicas que não estão de modo algum relacionadas com a chave partilhada do chat. Antes de um arquivo criptografado é enviado, assume-se que o endereço do arquivo criptografado será anexado ao exterior de uma mensagem criptografada usando o parâmetro de arquivo das mensagens.sendencryptedfile method and that the key for direct decryption will be sent in the body of the message (the key parameter in the constructors decryptors decryptedMessageMediaPhoto, decryptedMessageMediaVideo and decryptedMessageMediaFile.

Antes de um ficheiro ser enviado para uma conversa secreta, 2 números aleatórios de 256-bit são computados que irão servir como a chave AES e vector de inicialização usados para cifrar o ficheiro. A encriptação AES-256 com extensão garble infinita (IGE) é usada da mesma forma.

a impressão digital da chave é calculada do seguinte modo:

• digest = md5(chave + iv)
• impressão digital = substr(digest, 0, 4) substr XOR(digest, 4, 4)

o conteúdo encriptado de um ficheiro é armazenado no servidor da mesma forma que os de um ficheiro em chats na nuvem: peça a peça, usando as chamadas para enviar.saveFilePart.Uma chamada subsequente para as mensagens.o sendEncryptedFile irá atribuir um identificador ao ficheiro armazenado e enviar o endereço juntamente com a mensagem. O destinatário receberá uma atualização com encryptedMessage, e o parâmetro do arquivo conterá informações de arquivo.

os ficheiros encriptados recebidos e enviados podem ser encaminhados para outros chats secretos usando o ficheiro inputEncryptedFile do construtor para evitar gravar o mesmo conteúdo no servidor duas vezes.

trabalhar com uma caixa de actualização

as conversas secretas estão associadas a dispositivos específicos (ou melhor, com chaves de autorização), não utilizadores. Uma caixa de mensagens convencional, que usa pts para descrever o status do cliente, não é adequada, porque é projetado para armazenamento de mensagens de longo prazo e acesso de mensagens a partir de diferentes dispositivos.

uma fila de mensagens temporária adicional é introduzida como uma solução para este problema. Quando uma atualização sobre uma mensagem de um chat secreto é enviada, um novo valor de qts é enviado, o que ajuda a reconstruir a diferença se houve uma longa interrupção na conexão ou em caso de perda de uma atualização.

à medida que o número de eventos aumenta, o valor de qts Aumenta 1 com cada novo evento. O valor inicial não pode (e não será) ser igual a 0.

o facto de os eventos da fila temporária terem sido recebidos e armazenados pelo cliente é reconhecido explicitamente por uma chamada para as mensagens.receivedQueue method or implicitly by a call to updates.getdiference (o valor de qts passou, não o estado final). Todas as mensagens reconhecidas como entregues pelo cliente, bem como quaisquer mensagens com mais de 7 dias, podem (e serão) ser excluídos do servidor.

Após a desautorização, a fila de eventos do dispositivo correspondente será removida à força, e o valor do qts tornar-se-á irrelevante.

actualizando para novas camadas

o seu cliente deve sempre guardar a camada máxima que é suportada pelo Cliente do outro lado de uma conversa secreta. Quando o chat Secreto é criado pela primeira vez, este valor deve ser inicializado para 46. Este valor da camada remota deve ser sempre atualizado imediatamente após receber qualquer pacote contendo informações de uma camada superior, i.e.:

• qualquer segredo mensagem de bate-papo contendo layer_no no seu decryptedMessageLayer com camada>=46,
• um decryptedMessageActionNotifyLayer mensagem de serviço, embrulhado como se fosse o decryptedMessageService construtor da obsoleto camada 8 (construtor decryptedMessageService#aa48327d).

notificando o cliente remoto sobre a sua camada local

a fim de notificar o cliente remoto da sua camada local, o seu cliente deve enviar uma mensagem do tipodecryptedMessageActionNotifyLayer. Esta notificação deve ser embrulhada num construtor de uma camada adequada.

Existem dois casos em que o seu cliente tem de notificar o cliente remoto sobre a sua camada local:

1. logo que tenha sido criada uma nova conversa secreta, imediatamente após a chave secreta ter sido trocada com sucesso.
2. imediatamente após o cliente local ter sido actualizado para suportar uma nova camada secreta de conversação. Neste caso, as notificações devem ser enviadas a todas as conversas secretas actualmente existentes. Note que isso só é necessário quando a atualização para novas camadas que contêm mudanças na implementação de chats secretos (ex. você não precisa fazer isso quando seu cliente é atualizado da camada 46 para a camada 47).