User B receives the update updateEncryption for all associated authorization keys (all authorized devices) with the chat constructor encryptedChatRequested. Important: using the server's random sequence in its raw form may be unsafe, it must be combined with a client sequence.Ĭlient A computes a 2048-bit number a (using sufficient entropy or the server's random see above) and executes messages.requestEncryption after passing in g_a := pow(g, a) mod dh_prime. The client is expected to check whether p is a safe 2048-bit prime (meaning that both p and (p-1)/2 are prime, and t 0) so the server generates its own random sequence random of the appropriate length. If the version stored on the client is still up-to-date, the server will return the constructor messages.dhConfigNotModified. It makes sense to cache the values of the parameters together with the version in order to avoid having to receive all of the values every time. User A executes messages.getDhConfig to obtain the Diffie-Hellman parameters: a prime p, and a high-order element g.Įxecuting this method before each new key generation procedure is of vital importance. Let us consider the following scenario: User A would like to initiate end-to-end encrypted communication with User B. Keys are generated using the Diffie-Hellman protocol. See also: MTProto 2.0: Cloud Chats, server-client encryption Key Generation
msg_key depends not only on the message to be encrypted, but on a portion of the secret chat key as well.Padding bytes are involved in the computation of msg_key.The principal differences from version 1.0 ( described here for reference) are as follows: This article describes the end-to-end encryption layer in the MTProto protocol version 2.0.
0 kommentar(er)
