<p>Telegram supports Perfect Forward Secrecy (PFS) in Secret Chats as of Layer 20. See <ahref="/api/end-to-end#updating-to-new-layers">updating to new layers</a>.</p>
</blockquote>
<p>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.</p>
<p>Any client participating in a Secret Chat can initiate re-keying as soon as it perceives that the current key has been used for too long or for encrypting too many messages. Please note that you should never initiate a new instance of the re-keying protocol if an uncompleted instance exists, initiated by either party.</p>
<p><strong>Note:</strong> third-party developers are required to maintain the same level of security. All clients with secret chat support must be able to initiate re-keying and accept relevant service messages. See <ahref="/mtproto/security_guidelines">Security Guidelines</a>.</p>
<p>New keys are generated by exchanging special messages, using previously established keys for encryption. The re-keying protocol between parties A and B normally consists of four steps:</p>
<p>A (re-keying initiator) generates a new value of <em>a</em>, subject to the same limitations as for the <ahref="https://core.telegram.org/api/end-to-end#key-generation">initial Diffie-Hellman key exchange</a>, and sends the value of <em>pow(g,a)</em> to B, embedded in a <ahref="/constructor/decryptedMessageService">decryptedMessageService</a>:</p>
<li><em>exchange_id</em> is a random number identifying this instance of the Re-Keying Protocol for both parties</li>
<li><em>g_a</em> is the value of <em>pow(g,a) mod p</em></li>
</ul>
<p>Note that the same Diffie--Hellman parameters <em>(p,g)</em> as for the initial Diffie--Hellman key exchange in this secret chat are used. They do not need to be re-transmitted explicitly.</p>
<p>Upon receipt of the above service message, B checks its content, and generates a response with same <em>exchange_id</em>, for a newly generated value of <em>b</em>:</p>
<li><em>exchange_id</em> is the same as in the received <ahref="/constructor/decryptedMessageActionRequestKey">decryptedMessageActionRequestKey</a></li>
<li><em>g_b</em> is the value of <em>pow(g,b) mod p</em></li>
<li><em>key_fingerprint</em> is the 64-bit fingerprint of the newly generated <em>key = pow(g_a, b) mod p</em>, used as a sanity check of the implementation</li>
</ul>
<p>At this stage, B can already compute the new key <em>key</em> = <em>pow(g_a, b) mod p</em> and its <em>key_fingerprint</em> (last 64 bits of its SHA-1). However, it continues using the previous key until the completion of the exchange.</p>
<p>Once side B sends <ahref="/constructor/decryptedMessageActionAcceptKey">decryptedMessageActionAcceptKey</a>, it cannot abort the key exchange; it must be ready to switch to the new key immediately after a <code>decryptedMessageActionCommitKey</code> is received. Therefore, if side B wishes to delay the usage of new key, for example in order to fill some seq_no gaps first, it must delay the <code>decryptedMessageActionAcceptKey</code> answer accordingly.</p>
<p>Once A receives a valid <code>decryptedMessageActionAcceptKey</code>, it performs all necessary checks, and "commits" the new key by means of the following service message:</p>
<li><em>exchange_id</em> is the same as in the two previous messages</li>
<li><em>key_fingerprint</em> is the value of the hash (last 64 bits of SHA-1) of the new key computed by A, for implementation sanity check</li>
</ul>
<p>After that, A can (and must) encrypt all following messages with the new key.</p>
<p>If side A wishes to delay installation of the new key, for example because there are some seq_no gaps that it wants to fill first, it must delay <ahref="/constructor/decryptedMessageActionCommitKey">decryptedMessageActionCommitKey</a> answer accordingly.</p>
<h5><aclass="anchor"href="#4-final-step"id="4-final-step"name="4-final-step"><iclass="anchor-icon"></i></a>4. Final step</h5>
<p>When B receives either a <code>decryptedMessageActionCommitKey</code> or a message encrypted by the new key, recognized by the value of <em>key_fingerprint</em> prepended to the encrypted message (it may happen that the <code>decryptedMessageActionCommitKey</code> has been lost and will be re-requested later), it assumes that A has started using the new key for encryption, and does the same.</p>
<p>However, the previous key may be kept until there are no gaps in received messages up to the switch to the new key. Once all the gaps have been filled, the old key must be securely discarded.</p>
<p>There is one exception to this rule —the SHA-1 of the original key (generated during the establishment of Secret Chat in question) is always stored, in order to show <ahref="#key-visualization">key visualizations</a> on the clients.</p>
<p>Any of the parties may abort any instance of an uncompleted re-keying protocol, unless <code>decryptedMessageActionCommitKey</code> or <code>decryptedMessageActionAcceptKey</code> has been already sent by the party in question. In order to abort re-keying, send</p>
<p>This could be done, for example, if the party is already participating in a different instance of the re-keying protocol, or if the received values of <em>g_a</em>, <em>g_b</em> and other parameters do not pass security checks. In the latter case, it might be advisable to abort the Secret Chat altogether.</p>
<p>Once B receives <code>decryptedMessageActionCommitKey</code>, it can safely discard the previous key provided there are no gaps. However, A may only discard the previous key after a message encrypted with the new key has been received. If no ordinary messages are scheduled to be sent, a special <ahref="/constructor/decryptedMessageActionNoop">no-op message</a> should sent by B for this purpose:</p>
<p>It may happen that both parties concurrently initiate re-keying by sending <code>decryptedMessageActionRequestKey</code> without knowing that the other party has already done so. If each side aborts re-keying because it is already participating in another instance of the protocol initiated by itself, the re-keying will never happen.</p>
<p>Because of this possibility, we suggest that only the instance with the smaller <em>exchange_id</em> is aborted, with the option to re-use its <em>(a,g_a)</em> for the re-keying protocol instance with the larger <em>exchange_id</em> (when compared as a <code>long</code>, i.e. signed little-endian 64-bit integer).</p>
<p>In other words, if a <code>decryptedMessageActionRequestKey</code> is received after A has sent its <code>decryptedMessageActionRequestKey</code>, but has not yet received <code>decryptedMessageActionAcceptKey</code>, the following is to be done:</p>
<ul>
<li>if <em>exchange_id</em> in the sent <code>decryptedMessageActionRequestKey</code> was larger than that in the <code>decryptionActionRequestKey</code> just received, abort the newly-suggested re-keying protocol instance without sending explicit <ahref="/constructor/decryptedMessageActionAbortKey">decryptedMessageActionAbortKey</a> (the other side will do the same according to the next rule).</li>
<li>if <em>exchange_id</em> in our <code>decryptedMessageActionRequestKey</code> was smaller, respond to the newly-received <code>decryptedMessageActionRequestKey</code> with a <code>decryptedMessageActionAcceptKey</code>, and participate only in the re-keying protocol instance initiated by the other side. It is possible to re-use at this stage the value of <em>g_a</em> (now called <em>g_b</em>) that was generated for the original <code>decryptedMessageActionRequestKey</code>, now abandoned, or totally new <em>(b,g_b)</em> can be generated. </li>
<li>in the unlikely (2^{-64}) case both <em>exchange_id</em> are equal, abort both instances without sending an explicit <code>decryptedMessageActionAbortKey</code>. The other side will do the same.</li>
<p>Since all re-keying instances are carried over the secure channel established when the secret chat is created, it is necessary for the user to confirm that no MITM attack had taken place during the initial exchange. The key visualization on the clients uses the first 128-bits of the SHA-1 of the original key created when the Secret Chat was first established, followed by the first 160 bits of the SHA-256 of the key in use when the secret chat was updated to layer 46 (coincides with the original key if chat was created using layer 46).</p>
<blockquote>
<p>Please note that the <em>key_fingerprint</em> parameter was introduced as a maintenance tool (with a misleading name) and is <strong>not</strong> related to key visualization on the clients.</p>
</blockquote></div>
</div>
</div>
</div>
<divclass="footer_wrap">
<divclass="footer_columns_wrap footer_desktop">
<divclass="footer_column footer_column_telegram">
<h5>Telegram</h5>
<divclass="footer_telegram_description"></div>
Telegram is a cloud-based mobile and desktop messaging app with a focus on security and speed.
