From 83f5a2b4c8678e3528aa1c984b8808d97ffcc505 Mon Sep 17 00:00:00 2001 From: GitHub Action Date: Fri, 19 May 2023 20:22:49 +0000 Subject: [PATCH] Update content of files --- .../corefork.telegram.org/api/end-to-end.html | 71 ++++++------ data/web/corefork.telegram.org/api/pfs.html | 5 +- .../mtproto/description.html | 102 +++++++++--------- 3 files changed, 88 insertions(+), 90 deletions(-) diff --git a/data/web/corefork.telegram.org/api/end-to-end.html b/data/web/corefork.telegram.org/api/end-to-end.html index a98d127179..15dba40889 100644 --- a/data/web/corefork.telegram.org/api/end-to-end.html +++ b/data/web/corefork.telegram.org/api/end-to-end.html @@ -45,15 +45,11 @@
-

This article on MTProto's End-to-End encryption is meant for advanced users. -If you want to learn more about Secret Chats from a less intimidating source, kindly see our general FAQ.

-
-
-

Note that as of version 4.6, major Telegram clients are using MTProto 2.0. -MTProto v.1.0 is deprecated and is currently being phased out.

+

This article on MTProto's End-to-End encryption is meant for advanced users.
If you want to learn more about Secret Chats from a less intimidating source, kindly see our general FAQ.

+

Note that as of version 4.6, major Telegram clients are using MTProto 2.0.
MTProto v.1.0 is deprecated and is currently being phased out.

-
Related articles
+
Related articles

-

Secret Chats are one-on-one chats wherein messages are encrypted with a key held only by the chat's participants. Note that the schema for these end-to-end encrypted Secret Chats is different from what is used for cloud chats:

+

Secret Chats are one-on-one chats wherein messages are encrypted with a key held only by the chat's participants. Note that the schema for these end-to-end encrypted Secret Chats is different from what is used for cloud chats:

- +
-

A note on MTProto 2.0

-

This article describes the end-to-end encryption layer in the MTProto protocol version 2.0. -The principal differences from version 1.0 (described here for reference) are as follows:

+ +

A note on MTProto 2.0

+

This article describes the end-to-end encryption layer in the MTProto protocol version 2.0.
The principal differences from version 1.0 (described here for reference) are as follows:

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

-

Key Generation

+

Key Generation

Keys are generated using the Diffie-Hellman protocol.

Let us consider the following scenario: User A would like to initiate end-to-end encrypted communication with User B.

-

Sending a Request

+

Sending a Request

User A executes messages.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. 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. If the version stored on the client is still up-to-date, the server will return the constructor messages.dhConfigNotModified.

-

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 that 2^2047 < p < 2^2048), and that g generates a cyclic subgroup of prime order (p-1)/2, i.e. is a quadratic residue mod p. Since g is always equal to 2, 3, 4, 5, 6 or 7, this is easily done using quadratic reciprocity law, yielding a simple condition on p mod 4g -- namely, p mod 8 = 7 for g = 2; p mod 3 = 2 for g = 3; no extra condition for g = 4; p mod 5 = 1 or 4 for g = 5; p mod 24 = 19 or 23 for g = 6; and p mod 7 = 3, 5 or 6 for g = 7. After g and p have been checked by the client, it makes sense to cache the result, so as to avoid repeating lengthy computations in the future. This cache might be shared with one used for Authorization Key generation.

-

If the client needs additional entropy for the random number generator, it can pass the random_length parameter (random_length> 0) so the server generates its own random sequence random of the appropriate length. -Important: using the server's random sequence in its raw form may be unsafe, it must be combined with a client sequence.

-

Client 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 that 22047 < p < 22048), and that g generates a cyclic subgroup of prime order (p-1)/2, i.e. is a quadratic residue mod p. Since g is always equal to 2, 3, 4, 5, 6 or 7, this is easily done using quadratic reciprocity law, yielding a simple condition on p mod 4g — namely, p mod 8 = 7 for g = 2; p mod 3 = 2 for g = 3; no extra condition for g = 4; p mod 5 = 1 or 4 for g = 5; p mod 24 = 19 or 23 for g = 6; and p mod 7 = 3, 5 or 6 for g = 7. After g and p have been checked by the client, it makes sense to cache the result, so as to avoid repeating lengthy computations in the future. This cache might be shared with one used for Authorization Key generation.

+

If the client needs additional entropy for the random number generator, it can pass the random_length parameter (random_length> 0) so the server generates its own random sequence random of the appropriate length.
Important: using the server's random sequence in its raw form may be unsafe, it must be combined with a client sequence.

+

Client 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.

User B receives the update updateEncryption for all associated authorization keys (all authorized devices) with the chat constructor encryptedChatRequested. The user must be shown basic information about User A and must be prompted to accept or reject the request.

Both clients are to check that g, g_a and g_b are greater than one and smaller than p-1. We recommend checking that g_a and g_b are between 2^{2048-64} and p - 2^{2048-64} as well.

-

Accepting a Request

+

Accepting a Request

After User B confirms the creation of a secret chat with A in the client interface, Client B also receives up-to-date configuration parameters for the Diffie-Hellman method. Thereafter, it generates a random 2048-bit number, b, using rules similar to those for a.

Having received g_a from the update with encryptedChatRequested, it can immediately generate the final shared key: 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. Its fingerprint, key_fingerprint, is equal to the 64 last bits of SHA1 (key).

Note 1: in this particular case SHA1 is used here even for MTProto 2.0 secret chats.

Note 2: this fingerprint is used as a sanity check for the key exchange procedure to detect bugs when developing client software — it is not connected to the key visualization used on the clients as means of external authentication in secret chats. Key visualizations on the clients are generated using the first 128 bits of SHA1(initial key) followed by the first 160 bits of SHA256(key used when secret chat was updated to layer 46).

Client B executes messages.acceptEncryption after passing it g_b := pow(g, b) mod dh_prime and key_fingerprint.

-

For all of Client B's authorized devices, except the current one, updateEncryption updates are sent with the constructor encryptedChatDiscarded. Thereafter, the only device that will be able to access the secret chat is Device B, which made the call to messages.acceptEncryption.

+

For all of Client B's authorized devices, except the current one, updateEncryption updates are sent with the constructor encryptedChatDiscarded. Thereafter, the only device that will be able to access the secret chat is Device B, which made the call to messages.acceptEncryption.

User A will be sent an updateEncryption update with the constructor encryptedChat, for the authorization key that initiated the chat.

With g_b from the update, Client A can also compute the shared key 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. If the fingerprint for the received key is identical to the one that was passed to encryptedChat, incoming messages can be sent and processed. Otherwise, messages.discardEncryption must be executed and the user notified.

-

Perfect Forward Secrecy

+

Perfect Forward Secrecy

In order to keep past communications safe, official Telegram clients will initiate re-keying once a key has been used to decrypt and encrypt more than 100 messages, or has been in use for more than one week, provided the key has been used to encrypt at least one message. Old keys are then securely discarded and cannot be reconstructed, even with access to the new keys currently in use.

The re-keying protocol is further described in this article: Perfect Forward Secrecy in Secret Chats.

Please note that your client must support Forward Secrecy in Secret Chats to be compatible with official Telegram clients.

-

Sending and Receiving Messages in a Secret Chat

-

Serialization and Encryption of Outgoing Messages

+

Sending and Receiving Messages in a Secret Chat

+

Serialization and Encryption of Outgoing Messages

A TL object of type DecryptedMessage is created and contains the message in plain text. For backward compatibility, the object must be wrapped in the constructor decryptedMessageLayer with an indication of the supported layer (starting with 46).

The TL-Schema for the contents of end-to-end encrypted messages is available here »

@@ -126,49 +121,47 @@ The principal differences from version 1.0 (describ

For the obsolete MTProto 1.0, msg_key, aes_key, and aes_iv were computed differently (see this document for reference).

Data is encrypted with a 256-bit key, aes_key, and a 256-bit initialization vector, aes-iv, using AES-256 encryption with infinite garble extension (IGE). Encryption key fingerprint key_fingerprint and the message key msg_key are added at the top of the resulting byte array.

Encrypted data is embedded into a messages.sendEncrypted API call and passed to Telegram server for delivery to the other party of the Secret Chat.

-

Upgrading to MTProto 2.0 from MTProto 1.0

+

Upgrading to MTProto 2.0 from MTProto 1.0

As soon as both parties in a secret chat are using at least Layer 73, they should only use MTProto 2.0 for all outgoing messages. Some of the first received messages may use MTProto 1.0, if a sufficiently high starting layer has not been negotiated during the creation of the secret chat. After the first message encrypted with MTProto 2.0 (or the first message with Layer 73 or higher) is received, all messages with higher sequence numbers must be encrypted with MTProto 2.0 as well.

As long as the current layer is lower than 73, each party should try to decrypt received messages with MTProto 1.0, and if this is not successful (msg_key does not match), try MTProto 2.0. Once the first MTProto 2.0-encrypted message arrives (or the layer is upgraded to 73), there is no need to try MTProto 1.0 decryption for any of the further messages (unless the client is still waiting for some gaps to be closed).

-

Decrypting an Incoming Message

-

The steps above are performed in reverse order. -When an encrypted message is received, you must check that msg_key is in fact equal to the 128 middle bits of the SHA256 hash of the decrypted message, prepended by 32 bytes taken from the shared key. -If the message layer is greater than the one supported by the client, the user must be notified that the client version is out of date and prompted to update.

-

Sequence numbers

+

Decrypting an Incoming Message

+

The steps above are performed in reverse order.
When an encrypted message is received, you must check that msg_key is in fact equal to the 128 middle bits of the SHA256 hash of the decrypted message, prepended by 32 bytes taken from the shared key.
If the message layer is greater than the one supported by the client, the user must be notified that the client version is out of date and prompted to update.

+

Sequence numbers

It is necessary to interpret all messages in their original order to protect against possible manipulations. Secret chats support a special mechanism for handling seq_no counters independently from the server.

Proper handling of these counters is further described in this article: Sequence numbers in Secret Chats.

Please note that your client must support sequence numbers in Secret Chats to be compatible with official Telegram clients.

-

Sending Encrypted Files

-

All files sent to secret chats are encrypted with one-time keys that are in no way related to the chat's shared key. Before an encrypted file is sent, it is assumed that the encrypted file's address will be attached to the outside of an encrypted message using the file parameter of the messages.sendEncryptedFile method and that the key for direct decryption will be sent in the body of the message (the key parameter in the constructors decryptedMessageMediaPhoto, decryptedMessageMediaVideo and decryptedMessageMediaFile.

+

Sending Encrypted Files

+

All files sent to secret chats are encrypted with one-time keys that are in no way related to the chat's shared key. Before an encrypted file is sent, it is assumed that the encrypted file's address will be attached to the outside of an encrypted message using the file parameter of the messages.sendEncryptedFile method and that the key for direct decryption will be sent in the body of the message (the key parameter in the constructors decryptedMessageMediaPhoto, decryptedMessageMediaVideo and decryptedMessageMediaFile.

Prior to a file being sent to a secret chat, 2 random 256-bit numbers are computed which will serve as the AES key and initialization vector used to encrypt the file. AES-256 encryption with infinite garble extension (IGE) is used in like manner.

The key fingerprint is computed as follows:

  • digest = md5(key + iv)
  • fingerprint = substr(digest, 0, 4) XOR substr(digest, 4, 4)
-

The encrypted contents of a file are stored on the server in much the same way as those of a file in cloud chats: piece by piece using calls to upload.saveFilePart. -A subsequent call to messages.sendEncryptedFile will assign an identifier to the stored file and send the address together with the message. The recipient will receive an update with encryptedMessage, and the file parameter will contain file information.

+

The encrypted contents of a file are stored on the server in much the same way as those of a file in cloud chats: piece by piece using calls to upload.saveFilePart.
A subsequent call to messages.sendEncryptedFile will assign an identifier to the stored file and send the address together with the message. The recipient will receive an update with encryptedMessage, and the file parameter will contain file information.

Incoming and outgoing encrypted files can be forwarded to other secret chats using the constructor inputEncryptedFile to avoid saving the same content on the server twice.

-

Working with an Update Box

-

Secret chats are associated with specific devices (or rather with authorization keys), not users. A conventional message box, which uses pts to describe the client's status, is not suitable, because it is designed for long-term message storage and message access from different devices.

+

Working with an Update Box

+

Secret chats are associated with specific devices (or rather with authorization keys), not users. A conventional message box, which uses pts to describe the client's status, is not suitable, because it is designed for long-term message storage and message access from different devices.

An additional temporary message queue is introduced as a solution to this problem. When an update regarding a message from a secret chat is sent, a new value of qts is sent, which helps reconstruct the difference if there has been a long break in the connection or in case of loss of an update.

As the number of events increases, the value of qts increases by 1 with each new event. The initial value may not (and will not) be equal to 0.

The fact that events from the temporary queue have been received and stored by the client is acknowledged explicitly by a call to the messages.receivedQueue method or implicitly by a call to updates.getDifference (the value of qts passed, not the final state). All messages acknowledged as delivered by the client, as well as any messages older than 7 days, may (and will) be deleted from the server.

Upon de-authorization, the event queue of the corresponding device will be forcibly cleared, and the value of qts will become irrelevant.

-

Updating to new layers

+

Updating to new layers

Your client should always store the maximal layer that is known to be supported by the client on the other side of a secret chat. When the secret chat is first created, this value should be initialized to 46. This remote layer value must always be updated immediately after receiving any packet containing information of an upper layer, i.e.:

  • any secret chat message containing layer_no in its decryptedMessageLayer with layer>=46, or
  • a decryptedMessageActionNotifyLayer service message, wrapped as if it were the decryptedMessageService constructor of the obsolete layer 8 (constructor decryptedMessageService#aa48327d).
-

Notifying the remote client about your local layer

+

Notifying the remote client about your local layer

In order to notify the remote client of your local layer, your client must send a message of the decryptedMessageActionNotifyLayer type. This notification must be wrapped in a constructor of an appropriate layer.

There are two cases when your client must notify the remote client about its local layer:

  1. As soon as a new secret chat has been created, immediately after the secret key has been successfully exchanged.
    2. -
  2. Immediately after the local client has been updated to support a new secret chat layer. In this case notifications must be sent to all currently existing secret chats. Note that this is only necessary when updating to new layers that contain changes in the secret chats implementation (e.g. you don't need to do this when your client is updated from Layer 46 to Layer 47).
    3. -
+
  • Immediately after the local client has been updated to support a new secret chat layer. In this case notifications must be sent to all currently existing secret chats. Note that this is only necessary when updating to new layers that contain changes in the secret chats implementation (e.g. you don't need to do this when your client is updated from Layer 46 to Layer 47).
    • + + diff --git a/data/web/corefork.telegram.org/api/pfs.html b/data/web/corefork.telegram.org/api/pfs.html index 4184c1b822..626a930ea2 100644 --- a/data/web/corefork.telegram.org/api/pfs.html +++ b/data/web/corefork.telegram.org/api/pfs.html @@ -42,7 +42,7 @@

    Perfect Forward Secrecy

    -
    Related articles
    +
    Related articles

    • Perfect Forward Secrecy in Secret Chats
      • @@ -65,7 +65,8 @@

      In order to bind a temporary authorization key to the permanent key the client creates a special binding message and executes the auth.bindTempAuthKey method using temp_auth_key. Once auth.bindTempAuthKey has been executed successfully, the client may continue using the API as usual; the client must also rewrite client info using initConnection after each binding. Each permanent key may only be bound to one temporary key at a time, binding a new temporary key overwrites the previous one.

      Once the temporary key expires, the client needs to generate a new temporary key using p_q_inner_data_temp. Then it needs to re-bind that new temporary key to the initial permanent key. A new key can also be generated in advance, so that the client has a new key ready by the time the old one has expired.

      For additional security, the client can store the temporary authorization key in RAM only and never save it in persistent storage.

      -

      A temporary authorization key may expire at any moment before expires_at, since such keys are also stored only in the RAM on the server-side. Be prepared to handle resulting MTProto errors correctly (non-existent auth_key_id results in a 404 error).

    +

    A temporary authorization key may expire at any moment before expires_at, since such keys are also stored only in the RAM on the server-side. Be prepared to handle resulting MTProto errors correctly (non-existent auth_key_id results in a 404 error).

    +
    diff --git a/data/web/corefork.telegram.org/mtproto/description.html b/data/web/corefork.telegram.org/mtproto/description.html index 910d63c396..6d364fcd1d 100644 --- a/data/web/corefork.telegram.org/mtproto/description.html +++ b/data/web/corefork.telegram.org/mtproto/description.html @@ -47,8 +47,7 @@ MTProto v.1.0 is deprecated and is currently being phased…">
    -

    As of version 4.6, major Telegram clients are using MTProto 2.0. -MTProto v.1.0 is deprecated and is currently being phased out.

    +

    As of version 4.6, major Telegram clients are using MTProto 2.0.
    MTProto v.1.0 is deprecated and is currently being phased out.

    This article describes the basic layer of the MTProto protocol version 2.0 (Cloud chats, server-client encryption). The principal differences from version 1.0 (described here for reference) are as follows:

    See also: MTProto 2.0: Secret Chats, end-to-end encryption

    -

    Protocol description

    +

    Protocol description

    Before a message (or a multipart message) is transmitted over a network using a transport protocol, it is encrypted in a certain way, and an external header is added at the top of the message that consists of a 64-bit key identifier auth_key_id (that uniquely identifies an authorization key for the server as well as the user) and a 128-bit message key msg_key.

    The authorization key auth_key combined with the message key msg_key define an actual 256-bit key aes_key and a 256-bit initialization vector aes_iv, which are used to encrypt the message using AES-256 encryption in infinite garble extension (IGE) mode. Note that the initial part of the message to be encrypted contains variable data (session, message ID, sequence number, server salt) that obviously influences the message key (and thus the AES key and iv). In MTProto 2.0, the message key is defined as the 128 middle bits of the SHA-256 of the message body (including session, message ID, padding, etc.) prepended by 32 bytes taken from the authorization key. In the older MTProto 1.0, the message key was computed as the lower 128 bits of SHA-1 of the message body, excluding the padding bytes.

    Multipart messages are encrypted as a single message.

    - MTProto server-client encryption, cloud chats + MTProto server-client encryption, cloud chats
    +

    Got questions about this setup? — Check out the Advanced FAQ!

    -
    Note 1
    +
    Note 1

    Each plaintext message to be encrypted in MTProto always contains the following data to be checked upon decryption in order to make the system robust against known problems with the components:

    -
    Note 2
    -

    Telegram's End-to-end encrypted Secret Chats are using an additional layer of encryption on top of the described above. See Secret Chats, End-to-End encryption for details.

    +
    Note 2
    +

    Telegram's End-to-end encrypted Secret Chats are using an additional layer of encryption on top of the described above. See Secret Chats, End-to-End encryption for details.

    MTProto supports Perfect Forward Secrecy in both cloud chats and secret chats.

    -

    Terminology

    -

    Authorization Key (auth_key)

    +

    Terminology

    +

    Authorization Key (auth_key)

    A 2048-bit key shared by the client device and the server, created upon user registration directly on the client device by exchanging Diffie-Hellman keys, and never transmitted over a network. Each authorization key is user-specific. There is nothing that prevents a user from having several keys (that correspond to “permanent sessions” on different devices), and some of these may be locked forever in the event the device is lost. See also Creating an Authorization Key.

    -

    Server Key

    +

    Server Key

    A 2048-bit RSA key used by the server digitally to sign its own messages while registration is underway and the authorization key is being generated. The application has a built-in public server key which can be used to verify a signature but cannot be used to sign messages. A private server key is stored on the server and changed very infrequently.

    -

    Key Identifier (auth_key_id)

    +

    Key Identifier (auth_key_id)

    The 64 lower-order bits of the SHA1 hash of the authorization key are used to indicate which particular key was used to encrypt a message. Keys must be uniquely defined by the 64 lower-order bits of their SHA1, and in the event of a collision, an authorization key is regenerated. A zero key identifier means that encryption is not used which is permissible for a limited set of message types used during registration to generate an authorization key in a Diffie-Hellman exchange. For MTProto 2.0, SHA1 is still used here, because auth_key_id should identify the authorization key used independently of the protocol version.

    -

    Session

    +

    Session

    A (random) 64-bit number generated by the client to distinguish between individual sessions (for example, between different instances of the application, created with the same authorization key). The session in conjunction with the key identifier corresponds to an application instance. The server can maintain session state. Under no circumstances can a message meant for one session be sent into a different session. The server may unilaterally forget any client sessions; clients should be able to handle this.

    -

    Server Salt

    +

    Server Salt

    A (random) 64-bit number changed every 30 minutes (separately for each session) at the request of the server. All subsequent messages must contain the new salt (although, messages with the old salt are still accepted for a further 1800 seconds). Required to protect against replay attacks and certain tricks associated with adjusting the client clock to a moment in the distant future.

    -

    Message Identifier (msg_id)

    +

    Message Identifier (msg_id)

    A (time-dependent) 64-bit number used uniquely to identify a message within a session. Client message identifiers are divisible by 4, server message identifiers modulo 4 yield 1 if the message is a response to a client message, and 3 otherwise. Client message identifiers must increase monotonically (within a single session), the same as server message identifiers, and must approximately equal unixtime*2^32. This way, a message identifier points to the approximate moment in time the message was created. A message is rejected over 300 seconds after it is created or 30 seconds before it is created (this is needed to protect from replay attacks). In this situation, it must be re-sent with a different identifier (or placed in a container with a higher identifier). The identifier of a message container must be strictly greater than those of its nested messages.

    Important: to counter replay-attacks the lower 32 bits of msg_id passed by the client must not be empty and must present a fractional part of the time point when the message was created.

    -

    Content-related Message

    +

    Content-related Message

    A message requiring an explicit acknowledgment. These include all the user and many service messages, virtually all with the exception of containers and acknowledgments.

    -

    Message Sequence Number (msg_seqno)

    +

    Message Sequence Number (msg_seqno)

    A 32-bit number equal to twice the number of “content-related” messages (those requiring acknowledgment, and in particular those that are not containers) created by the sender prior to this message and subsequently incremented by one if the current message is a content-related message. A container is always generated after its entire contents; therefore, its sequence number is greater than or equal to the sequence numbers of the messages contained in it.

    -

    Message Key (msg_key)

    +

    Message Key (msg_key)

    In MTProto 2.0, the middle 128 bits of the SHA-256 hash of the message to be encrypted (including the internal header and the padding bytes for MTProto 2.0), prepended by a 32-byte fragment of the authorization key.

    In MTProto 1.0, message key was defined differently, as the lower 128 bits of the SHA-1 hash of the message to be encrypted, with padding bytes excluded from the computation of the hash. Authorization key was not involved in this computation.

    -

    Internal (cryptographic) Header

    +

    Internal (cryptographic) Header

    A header (16 bytes) added before a message or a container before it is all encrypted together. Consists of the server salt (64 bits) and the session (64 bits).

    -

    External (cryptographic) Header

    +

    External (cryptographic) Header

    A header (24 bytes) added before an encrypted message or a container. Consists of the key identifier auth_key_id (64 bits) and the message key msg_key (128 bits).

    -

    Payload

    +

    Payload

    External header + encrypted message or container.

    -

    Defining AES Key and Initialization Vector

    +

    Defining AES Key and Initialization Vector

    The 2048-bit authorization key (auth_key) and the 128-bit message key (msg_key) are used to compute a 256-bit AES key (aes_key) and a 256-bit initialization vector (aes_iv) which are subsequently used to encrypt the part of the message to be encrypted (i. e. everything with the exception of the external header that is added later) with AES-256 in infinite garble extension (IGE) mode.

    For MTProto 2.0, the algorithm for computing aes_key and aes_iv from auth_key and msg_key is as follows.

    +

    During the creation of the authorization key, the client obtains its server salt (to be used with the new key for all communication in the near future). The client then creates an encrypted session using the newly generated key, and subsequent communication occurs within that session (including the transmission of the user's registration information and phone number validation) unless the client creates a new session. The client is free to create new or additional sessions at any time by choosing a new random session_id.

    +