#TELEGRAM DEFINITION MOD#
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. If the version stored on the client is still up-to-date, the server will return the constructor messages.dhConfigNotModified.Ĭlient is expected to check whether p is a safe 2048-bit prime (meaning that both p and (p-1)/2 are prime, and that 2^2047 0) so the server generates its own random sequence random of the appropriate length. 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 12.1024 padding bytes are used instead of 0.15 padding bytes in v.1.0.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.