mirror of
https://github.com/MarshalX/telegram-crawler.git
synced 2025-01-16 22:53:12 +01:00
Update content of files
This commit is contained in:
GitHub Action
parent
fc0a4bfd70
commit
c1f49de62f
9 changed files with 13 additions and 13 deletions
|
|
@ -90,7 +90,7 @@ The principal differences from version 1.0 (<a href="/api/end-to-end_v1">describ
|
|||
<p>After User <strong>B</strong> confirms the creation of a secret chat with <strong>A</strong> in the client interface, Client <strong>B</strong> also receives up-to-date configuration parameters for the Diffie-Hellman method. Thereafter, it generates a random 2048-bit number, <strong>b</strong>, using rules similar to those for <strong>a</strong>. </p>
|
||||
<p>Having received <strong>g_a</strong> from the update with <a href="/constructor/encryptedChatRequested">encryptedChatRequested</a>, it can immediately generate the final shared key: <code>key = (pow(g_a, b) mod dh_prime)</code>. If key length < 256 bytes, add several leading zero bytes as padding — so that the key is exactly 256 bytes long. Its fingerprint, <strong>key_fingerprint</strong>, is equal to the 64 last bits of SHA1 (key). </p>
|
||||
<p><strong>Note 1:</strong> in this particular case SHA1 is used here even for MTProto 2.0 secret chats. </p>
|
||||
<p><strong>Note 2:</strong> 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. <a href="/api/end-to-end/pfs#key-visualization">Key visualizations</a> on the clients are generated using the first 128 bits of SHA1(intial key) followed by the first 160 bits of SHA256(key used when secret chat was updated to layer 46).</p>
|
||||
<p><strong>Note 2:</strong> 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. <a href="/api/end-to-end/pfs#key-visualization">Key visualizations</a> 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).</p>
|
||||
<p>Client <strong>B</strong> executes <a href="/method/messages.acceptEncryption">messages.acceptEncryption</a> after passing it <code>g_b := pow(g, b) mod dh_prime</code> and <strong>key_fingerprint</strong>.</p>
|
||||
<p>For all of Client <strong>B’s</strong> authorized devices, except the current one, <a href="/constructor/updateEncryption">updateEncryption</a> updates are sent with the constructor <a href="/constructor/encryptedChatDiscarded">encryptedChatDiscarded</a>. Thereafter, the only device that will be able to access the secret chat is Device <strong>B</strong>, which made the call to <a href="/method/messages.acceptEncryption">messages.acceptEncryption</a>.</p>
|
||||
<p>User <strong>A</strong> will be sent an <a href="/constructor/updateEncryption">updateEncryption</a> update with the constructor <a href="/constructor/encryptedChat">encryptedChat</a>, for the authorization key that initiated the chat.</p>
|
||||
|
|
|
|||
|
|
@ -76,7 +76,7 @@ For information on end-to-end encryption used in up-to-date Telegram clients, ki
|
|||
<h4><a class="anchor" href="#accepting-a-request" id="accepting-a-request" name="accepting-a-request"><i class="anchor-icon"></i></a>Accepting a Request</h4>
|
||||
<p>After User <strong>B</strong> confirms the creation of a secret chat with <strong>A</strong> in the client interface, Client <strong>B</strong> also receives up-to-date configuration parameters for the Diffie-Hellman method. Thereafter, it generates a random 2048-bit number, <strong>b</strong>, using rules similar to those for <strong>a</strong>. </p>
|
||||
<p>Having received <strong>g_a</strong> from the update with <a href="/constructor/encryptedChatRequested">encryptedChatRequested</a>, it can immediately generate the final shared key: <code>key = (pow(g_a, b) mod dh_prime)</code>. If key length < 256 bytes, add several leading zero bytes as padding — so that the key is exactly 256 bytes long. Its fingerprint, <strong>key_fingerprint</strong>, is equal to the 64 last bits of SHA1 (key).</p>
|
||||
<p><strong>Note:</strong> this fingerprint is used as a sanity check for the key exchange procedure to detect bugs while developing client software — it is not connected to the key visualization used on the clients as means of external authentication in secret chats. <a href="/api/end-to-end/pfs#key-visualization">Key visualizations</a> on the clients are generated using the first 128 bits of SHA1(intial key) followed by the first 160 bits of SHA256(key used when secret chat was updated to layer 46).</p>
|
||||
<p><strong>Note:</strong> this fingerprint is used as a sanity check for the key exchange procedure to detect bugs while developing client software — it is not connected to the key visualization used on the clients as means of external authentication in secret chats. <a href="/api/end-to-end/pfs#key-visualization">Key visualizations</a> 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).</p>
|
||||
<p>Client <strong>B</strong> executes <a href="/method/messages.acceptEncryption">messages.acceptEncryption</a> after passing it <code>g_b := pow(g, b) mod dh_prime</code> and <strong>key_fingerprint</strong>.</p>
|
||||
<p>For all of Client <strong>B’s</strong> authorized devices, except the current one, <a href="/constructor/updateEncryption">updateEncryption</a> updates are sent with the constructor <a href="/constructor/encryptedChatDiscarded">encryptedChatDiscarded</a>. Thereafter, the only device that will be able to access the secret chat is Device <strong>B</strong>, which made the call to <a href="/method/messages.acceptEncryption">messages.acceptEncryption</a>.</p>
|
||||
<p>User <strong>A</strong> will be sent an <a href="/constructor/updateEncryption">updateEncryption</a> update with the constructor <a href="/constructor/encryptedChat">encryptedChat</a>, for the authorization key that initiated the chat.</p>
|
||||
|
|
|
|||
|
|
@ -1511,7 +1511,7 @@ Notice that all <code>PINNED_*</code> <a href="https://core.telegram.org/api/pus
|
|||
<li>Added <a href="/constructor/updateDialogFilterOrder">updateDialogFilterOrder</a> - New <a href="/api/folders">folder</a> order</li>
|
||||
<li>Added <a href="/constructor/updateDialogFilters">updateDialogFilters</a> - Clients should update <a href="/api/folders">folder</a> info</li>
|
||||
<li>Added <a href="/constructor/statsDateRangeDays">statsDateRangeDays</a> - <a href="/api/stats">Channel statistics</a> date range</li>
|
||||
<li>Added <a href="/constructor/statsAbsValueAndPrev">statsAbsValueAndPrev</a> - Statistics value couple; intial and final value for period of time currently in consideration</li>
|
||||
<li>Added <a href="/constructor/statsAbsValueAndPrev">statsAbsValueAndPrev</a> - Statistics value couple; initial and final value for period of time currently in consideration</li>
|
||||
<li>Added <a href="/constructor/statsPercentValue">statsPercentValue</a> - <a href="/api/stats">Channel statistics percentage</a>. </li>
|
||||
<li>Added <a href="/constructor/statsGraphAsync">statsGraphAsync</a> - This <a href="/api/stats">channel statistics graph</a> must be generated asynchronously using <a href="/method/stats.loadAsyncGraph">stats.loadAsyncGraph</a> to reduce server load</li>
|
||||
<li>Added <a href="/constructor/statsGraphError">statsGraphError</a> - An error occurred while generating the <a href="/api/stats">statistics graph</a></li>
|
||||
|
|
|
|||
|
|
@ -4,10 +4,10 @@
|
|||
<meta charset="utf-8">
|
||||
<title>statsAbsValueAndPrev</title>
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
<meta property="description" content="Statistics value couple; intial and final value for period of time currently in consideration">
|
||||
<meta property="description" content="Statistics value couple; initial and final value for period of time currently in consideration">
|
||||
<meta property="og:title" content="statsAbsValueAndPrev">
|
||||
<meta property="og:image" content="">
|
||||
<meta property="og:description" content="Statistics value couple; intial and final value for period of time currently in consideration">
|
||||
<meta property="og:description" content="Statistics value couple; initial and final value for period of time currently in consideration">
|
||||
<link rel="shortcut icon" href="/favicon.ico?4" type="image/x-icon" />
|
||||
|
||||
<link href="/css/bootstrap.min.css?3" rel="stylesheet">
|
||||
|
|
@ -39,7 +39,7 @@
|
|||
<div class="dev_page_bread_crumbs"><ul class="breadcrumb clearfix"><li><a href="/api" >API</a></li><i class="icon icon-breadcrumb-divider"></i><li><a href="/schema" >TL-schema</a></li><i class="icon icon-breadcrumb-divider"></i><li><a href="/constructor/statsAbsValueAndPrev" >statsAbsValueAndPrev</a></li></ul></div>
|
||||
<h1 id="dev_page_title">statsAbsValueAndPrev</h1>
|
||||
|
||||
<div id="dev_page_content"><p>Statistics value couple; intial and final value for period of time currently in consideration</p>
|
||||
<div id="dev_page_content"><p>Statistics value couple; initial and final value for period of time currently in consideration</p>
|
||||
<p><div class="clearfix">
|
||||
<ul class="dev_layer_select slightly-pull-right nav nav-pills">
|
||||
<li class="dropdown">
|
||||
|
|
|
|||
|
|
@ -4,10 +4,10 @@
|
|||
<meta charset="utf-8">
|
||||
<title>account.initTakeoutSession</title>
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
<meta property="description" content="Intialize account takeout session">
|
||||
<meta property="description" content="Initialize account takeout session">
|
||||
<meta property="og:title" content="account.initTakeoutSession">
|
||||
<meta property="og:image" content="">
|
||||
<meta property="og:description" content="Intialize account takeout session">
|
||||
<meta property="og:description" content="Initialize account takeout session">
|
||||
<link rel="shortcut icon" href="/favicon.ico?4" type="image/x-icon" />
|
||||
|
||||
<link href="/css/bootstrap.min.css?3" rel="stylesheet">
|
||||
|
|
@ -39,7 +39,7 @@
|
|||
<div class="dev_page_bread_crumbs"><ul class="breadcrumb clearfix"><li><a href="/api" >API</a></li><i class="icon icon-breadcrumb-divider"></i><li><a href="/methods" >All Methods</a></li><i class="icon icon-breadcrumb-divider"></i><li><a href="/method/account.initTakeoutSession" >account.initTakeoutSession</a></li></ul></div>
|
||||
<h1 id="dev_page_title">account.initTakeoutSession</h1>
|
||||
|
||||
<div id="dev_page_content"><p>Intialize account takeout session</p>
|
||||
<div id="dev_page_content"><p>Initialize account takeout session</p>
|
||||
<p><div class="clearfix">
|
||||
<ul class="dev_layer_select slightly-pull-right nav nav-pills">
|
||||
<li class="dropdown">
|
||||
|
|
|
|||
|
|
@ -292,7 +292,7 @@
|
|||
<tbody>
|
||||
<tr>
|
||||
<td><a href="/method/account.initTakeoutSession">account.initTakeoutSession</a></td>
|
||||
<td>Intialize account takeout session</td>
|
||||
<td>Initialize account takeout session</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><a href="/method/account.finishTakeoutSession">account.finishTakeoutSession</a></td>
|
||||
|
|
|
|||
|
|
@ -165,7 +165,7 @@ Bytes <code>4-8</code> must also not be equal to <code>0x00000000</code>, since
|
|||
<p>The protocol identifier, if present, must be inserted in the initialization payload at byte offset <code>56</code>: if its length is less than 4, it must be padded using the protocol identifier itself, to make its length 4 (<code>0xef</code> => <code>0xefefefef</code>): the standalone protocol identifier must be not be sent aftwerwards.</p>
|
||||
<p>This protocol is also (but not exclusively) used when connecting to MTProxies: <strong>only in this case</strong>, the DC ID in a specially encoded form must also be inserted in the initialization payload at offset <code>60</code>.
|
||||
The encoding simply consist of the DC ID in two-byte signed little-endian form; <code>10000</code> has to be added to the DC ID to connect to the test servers; it has to be made negative if the DC we're connecting to is a media (not CDN) DC. </p>
|
||||
<p>Next, a secondary initialization payload is generated by reversing the primary intialization payload. </p>
|
||||
<p>Next, a secondary initialization payload is generated by reversing the primary initialization payload. </p>
|
||||
<p>Two keys are extracted from both initialization payloads, using bytes at offsets <code>8-40</code>: the key extracted from the primary payload is used as encryption key, the key extracted from the secondary payload is used as decryption key.</p>
|
||||
<p>Two IVs are extracted from both initialization payloads, using bytes at offsets <code>40-56</code>: the IV extracted from the primary payload is used as encryption IV, the IV extracted from the secondary payload is used as decryption IV.</p>
|
||||
<p><strong>Only if using MTProxy</strong>, the secret is used to provide connection with the MTProxy server.
|
||||
|
|
|
|||
|
|
@ -64,7 +64,7 @@
|
|||
<tbody>
|
||||
<tr>
|
||||
<td><a href="/constructor/statsAbsValueAndPrev">statsAbsValueAndPrev</a></td>
|
||||
<td>Statistics value couple; intial and final value for period of time currently in consideration</td>
|
||||
<td>Statistics value couple; initial and final value for period of time currently in consideration</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table></div>
|
||||
|
|
|
|||
|
|
@ -83,7 +83,7 @@
|
|||
<tbody>
|
||||
<tr>
|
||||
<td><a href="/method/account.initTakeoutSession">account.initTakeoutSession</a></td>
|
||||
<td>Intialize account takeout session</td>
|
||||
<td>Initialize account takeout session</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table></div>
|
||||
|
|
|
|||
Loading…
Reference in a new issue