Update content of files

data/web/core.telegram.org/techfaq.html

@@ -5,11 +5,11 @@
     <title>FAQ for the Technically Inclined</title>
     <meta name="viewport" content="width=device-width, initial-scale=1.0">
     <meta property="description" content="This FAQ about MTProto is intended for advanced users. You may also want to check out our Basic FAQ.
-Please note, that…">
+Note that client developers…">
     <meta property="og:title" content="FAQ for the Technically Inclined">
     <meta property="og:image" content="https://core.telegram.org/file/811140746/2/CzMyJPVnPo8.81605/c2310d6ede1a5e220f">
     <meta property="og:description" content="This FAQ about MTProto is intended for advanced users. You may also want to check out our Basic FAQ.
-Please note, that…">
+Note that client developers…">
     <link rel="icon" type="image/svg+xml" href="/img/website_icon.svg?4">
 <link rel="apple-touch-icon" sizes="180x180" href="/img/apple-touch-icon.png">
 <link rel="icon" type="image/png" sizes="32x32" href="/img/favicon-32x32.png">
@@ -45,7 +45,7 @@ Please note, that…">
   <h1 id="dev_page_title">FAQ for the Technically Inclined</h1>
   
   <div id="dev_page_content"><blockquote>
-<p>This FAQ about <a href="http://core.telegram.org/mtproto">MTProto</a> is intended for advanced users. You may also want to check out our <a href="http://telegram.org/faq"><strong>Basic FAQ</strong></a>.<br>Please note, that client developers are required to comply with the <a href="/mtproto/security_guidelines">Security Guidelines</a>.</p>
+<p>This FAQ about <a href="http://core.telegram.org/mtproto">MTProto</a> is intended for advanced users. You may also want to check out our <a href="http://telegram.org/faq"><strong>Basic FAQ</strong></a>.<br>Note that client developers are required to comply with the <a href="/mtproto/security_guidelines">Security Guidelines</a>.</p>
 </blockquote>
 <p><div class="dev_page_nav_wrap"></p>
 <p><a href="#general-questions"><strong>General</strong></a></p>
@@ -71,7 +71,7 @@ Please note, that…">
 <li><a href="#q-how-is-the-server-authenticated-during-dh-key-exchange">How is the server authenticated during DH key exchange?</a></li>
 <li><a href="#q-how-are-clients-authenticated">How are clients authenticated?</a></li>
 <li><a href="#q-how-are-secret-chats-authenticated">How are secret chats authenticated?</a></li>
-<li><a href="#q-how-are-voice-calls-authenticated">How are voice calls authentication?</a></li>
+<li><a href="#q-how-are-voice-and-video-calls-authenticated">How are voice and video calls authenticated?</a></li>
 <li><a href="#q-do-you-have-forward-secrecy">Do you have Forward Secrecy?</a></li>
 </ul>
 <p><a href="#protection-against-known-attacks"><strong>Protection against known attacks</strong></a></p>
@@ -138,13 +138,13 @@ Please note, that…">
 <li><a href="/api/end-to-end/voice-calls">End-to-end encrypted Voice Calls</a></li>
 </ul>
 <h4><a class="anchor" name="q-why-are-you-not-using-x-insert-solution" href="#q-why-are-you-not-using-x-insert-solution"><i class="anchor-icon"></i></a>Q: Why are you not using X? (insert solution)</h4>
-<p>While other ways of achieving the same cryptographic goals, undoubtedly, exist, we feel that the present solution is both robust and also sucсeeds at our secondary task of beating unencrypted messengers in terms of delivery time and stability.</p>
+<p>While other ways of achieving the same cryptographic goals undoubtedly exist, we feel that the present solution is both robust and also sucсeeds at our secondary task of beating unencrypted messengers in terms of delivery time and stability.</p>
 <h4><a class="anchor" name="q-why-are-you-mostly-relying-on-classical-crypto-algorithms" href="#q-why-are-you-mostly-relying-on-classical-crypto-algorithms"><i class="anchor-icon"></i></a>Q: Why are you mostly relying on classical crypto algorithms?</h4>
-<p>We prefer to use well-known algorithms, created in the days when bandwidth and processing power were both a much rarer commodity. This has valuable side-effects for modern-day mobile development and sending large files, provided one takes care of the known drawbacks.</p>
-<p>The weakspots of such algorithms are also well-known, and have been exploited for decades. We use these algorithms in such a combination that, to the best of our knowledge, prevents any known attacks.</p>
+<p>We prefer to use well-known algorithms, created in the days when bandwidth and processing power were both a much rarer commodity. This has valuable side effects for modern-day mobile development and sending large files, provided one takes care of the known drawbacks.</p>
+<p>The weaknesses of such algorithms are also well-known, and have been exploited for decades. We use these algorithms in such a combination that, to the best of our knowledge, prevents any known attacks.</p>
 <h4><a class="anchor" name="q-i-39m-a-security-expert-and-i-have-comments-about-your-setup" href="#q-i-39m-a-security-expert-and-i-have-comments-about-your-setup"><i class="anchor-icon"></i></a>Q: I&#39;m a security expert and I have comments about your setup.</h4>
-<p>Any comments on Telegram&#39;s security are welcome at <a href="mailto:security@telegram.org">security@telegram.org</a>. All submissions which result in a change of code or configuration are eligible for bounties, ranging from <strong>$100</strong> to <a href="https://telegram.org/blog/crowdsourcing-a-more-secure-future"><strong>$100,000</strong></a> or more, depending on the severity of the issue.</p>
-<p>Please note that we can not offer bounties for issues that are disclosed to the public before they are addressed.</p>
+<p>Telegram welcomes developers and the security research community to audit its services, <a href="https://telegram.org/apps#source-code">code</a> and <a href="https://core.telegram.org/mtproto">protocol</a> seeking vulnerabilities or security-related issues. Check out our official <a href="https://core.telegram.org/bug-bounty">Bounty Program</a> to learn how you can report your findings.</p>
+<p>Please note that we can&#39;t offer bounties for issues that are disclosed to the public before they are addressed.</p>
 <h3><a class="anchor" name="encryption" href="#encryption"><i class="anchor-icon"></i></a>Encryption</h3>
 <h4><a class="anchor" name="q-how-are-mtproto-messages-authenticated" href="#q-how-are-mtproto-messages-authenticated"><i class="anchor-icon"></i></a>Q: How are MTProto messages authenticated?</h4>
 <p>All Telegram apps <a href="https://core.telegram.org/mtproto/security_guidelines#mtproto-encrypted-messages">ensure</a> that <em>msg_key</em> is equal to SHA-256 of a fragment of the <em>auth_key</em> concatenated with the decrypted message (including 12…1024 bytes of random padding). It is important that the plaintext always contains message length, server salt, <em>session_id</em> and <a href="#note-1">other data</a> not known to the attacker.</p>
@@ -156,7 +156,7 @@ Please note, that…">
 </blockquote>
 <h4><a class="anchor" name="q-why-don-39t-you-go-for-a-standard-encrypt-then-mac-approach" href="#q-why-don-39t-you-go-for-a-standard-encrypt-then-mac-approach"><i class="anchor-icon"></i></a>Q: Why don&#39;t you go for a standard encrypt-then-MAC approach?</h4>
 <p>Using encrypt-then-MAC, e.g. involving GCM (Galois Counter Mode), would enable the receiving party to detect unauthorized or modified ciphertexts, thus eliminating the need to decrypt them in case of tampering.</p>
-<p>In MTProto, the clients and the server authenticate messages by <a href="https://core.telegram.org/mtproto/security_guidelines#mtproto-encrypted-messages">ensuring</a> that SHA-256(auth_key_fragment + plaintext + padding) = msg_key and that the plaintext always contains message length, server salt, session_id and <a href="#note-1">other data</a> not known to a potential attacker before accepting any message. These <a href="https://core.telegram.org/mtproto/security_guidelines#mtproto-encrypted-messages">security checks</a> performed on the client before any message is accepted ensure that invalid or tampered with messages will always be safely (and silently) discarded.</p>
+<p>In MTProto, the clients and the server authenticate messages by <a href="https://core.telegram.org/mtproto/security_guidelines#mtproto-encrypted-messages">ensuring</a> that SHA-256(auth_key_fragment + plaintext + padding) = msg_key and that the plaintext always contains message length, server salt, session_id and <a href="#note-1">other data</a> not known to a potential attacker before accepting any message. These <a href="https://core.telegram.org/mtproto/security_guidelines#mtproto-encrypted-messages">security checks</a> performed on the client before any message is accepted ensure that invalid or tampered-with messages will always be safely (and silently) discarded.</p>
 <p>This way we arrive at the same result. The difference is that the security check is performed before decryption in Encrypt-then-MAC and after decryption in MTProto – but in either case before a message is accepted. AES encryption / decryption on devices currently in use is comparable in speed with the additional HMAC computation required for the encrypt-then-MAC approach.</p>
 <h4><a class="anchor" name="q-do-you-still-use-sha-1" href="#q-do-you-still-use-sha-1"><i class="anchor-icon"></i></a>Q: Do you still use SHA-1?</h4>
 <p>The current version of the protocol is using <strong>SHA-256</strong>. MTProto 1.0 used to rely on SHA-1 (<a href="/techfaq/mtproto_v1#q-why-did-you-use-sha-1-sha-1-is-broken">see this FAQ</a> for details).</p>
@@ -178,8 +178,8 @@ Please note, that…">
 <p>Notice that new_nonce is transferred explicitly only once, inside an RSA-encrypted message from the client to the server.</p>
 <h4><a class="anchor" name="q-how-are-secret-chats-authenticated" href="#q-how-are-secret-chats-authenticated"><i class="anchor-icon"></i></a>Q: How are Secret Chats authenticated?</h4>
 <p>Keys for <a href="https://core.telegram.org/api/end-to-end">end-to-end encrypted secret chats</a> are generated by a new instance of DH key exchange, so they are known only to the parties involved and not to the server. To establish the identities of these parties and to ensure that no MitM is in place, it is recommended to compare identicons, generated from hashes of the DH secret chat keys (key visualizations).</p>
-<h4><a class="anchor" name="q-how-are-voice-calls-authenticated" href="#q-how-are-voice-calls-authenticated"><i class="anchor-icon"></i></a>Q: How are Voice Calls authenticated?</h4>
-<p>Keys for <a href="https://core.telegram.org/api/end-to-end/voice-calls">end-to-end encrypted calls</a> are generated using the Diffie-Hellman key exchange. Users who are on a call can ensure that there is no MitM by comparing key visualizations.</p>
+<h4><a class="anchor" name="q-how-are-voice-and-video-calls-authenticated" href="#q-how-are-voice-and-video-calls-authenticated"><i class="anchor-icon"></i></a>Q: How are Voice and Video Calls authenticated?</h4>
+<p>Keys for <a href="https://core.telegram.org/api/end-to-end/video-calls">end-to-end encrypted calls</a> are generated using the Diffie-Hellman key exchange. Users who are on a call can ensure that there is no MitM by comparing key visualizations.</p>
 <p>To make key verification practical in the context of a voice call, Telegram uses a three-message modification of the standard DH key exchange for calls:</p>
 <ul>
 <li>A-&gt;B : (generates a and) sends g_a_hash := hash(g^a)</li>
@@ -189,9 +189,9 @@ Please note, that…">
 </ul>
 <p>The idea is that Alice commits to a specific value of <em>a</em> (and of <em>g_a</em>), but does not reveal <em>g_a</em> to Bob (or Eve) until the very last step. Bob has to choose his value of <em>b</em> and <em>g_b</em> without knowing the true value of <em>g_a</em>. If Eve is performing a Man-in-the-Middle attack, she cannot change <em>a</em> depending on the value of <em>g_b</em> received from Bob and she also can&#39;t tune her value of <em>b</em> depending on <em>g_a</em>. As a result, Eve only gets <strong>one</strong> shot at injecting her parameters — and she must fire this shot with her eyes closed.</p>
 <p>Thanks to this modification, it becomes possible to prevent eavesdropping (MitM attacks on DH) with a probability of more than 0.9999999999 by using just over 33 bits of entropy in the visualization. These bits are presented to the users in the form of four emoticons. We have selected a pool of 333 emoji that all look quite different from one another and can be easily described in simple words in any language.</p>
-<p>You can read more about key verification for Telegram calls <a href="https://core.telegram.org/api/end-to-end/voice-calls#key-verification">here</a>.</p>
+<p>You can read more about key verification for Telegram calls <a href="https://core.telegram.org/api/end-to-end/video-calls#key-verification">here</a>.</p>
 <h4><a class="anchor" name="q-do-you-have-forward-secrecy" href="#q-do-you-have-forward-secrecy"><i class="anchor-icon"></i></a>Q: Do you have Forward Secrecy?</h4>
-<p>Telegram&#39;s Secret chats support Perfect Forward Secrecy, you can read more about it <a href="/api/end-to-end/pfs">here</a>.</p>
+<p>MTProto supports <a href="https://en.wikipedia.org/wiki/Forward_secrecy">Perfect Forward Secrecy</a> in both <a href="https://core.telegram.org/api/pfs">cloud chats</a> and <a href="https://core.telegram.org/api/end-to-end/pfs">secret chats</a>.</p>
 <h3><a class="anchor" name="protection-against-known-attacks" href="#protection-against-known-attacks"><i class="anchor-icon"></i></a>Protection against known attacks</h3>
 <h4><a class="anchor" name="known-plaintext-attacks" href="#known-plaintext-attacks"><i class="anchor-icon"></i></a>Known-Plaintext Attacks</h4>
 <p>By definition, the known-plaintext attack (KPA) is an attack model for cryptanalysis where the attacker has samples of both the plaintext, and its encrypted version (ciphertext).</p>
@@ -228,7 +228,7 @@ Please note, that…">
 </blockquote>
 <h4><a class="anchor" name="length-extension-attacks" href="#length-extension-attacks"><i class="anchor-icon"></i></a>Length extension attacks</h4>
 <p>By definition, length extension attacks are a type of attack when certain types of hashes are misused as message authentication codes, allowing for inclusion of extra information.</p>
-<p>A message in MTProto consists of an <em>msg_key</em>, equal to the SHA-256 of a fragment of the <em>auth_key</em> concatenated with the plaintext (including 12…1024 bytes of random padding and <a href="#note-1">some additional parameters</a>), followed by the ciphertext. The attacker cannot append extra bytes to the end and recompute the SHA-256, since the SHA-256 is computed from the plaintext, not the ciphertext, and the attacker has no way to obtain the ciphertext corresponding to the extra plaintext bytes she may want to add. </p>
+<p>A message in MTProto consists of an <em>msg_key</em>, equal to the SHA-256 of a fragment of the <em>auth_key</em> concatenated with the plaintext (including 12…1024 bytes of random padding and <a href="#note-1">some additional parameters</a>), followed by the ciphertext. The attacker cannot append extra bytes to the end and recompute the SHA-256, since the SHA-256 is computed from the plaintext, not the ciphertext, and the attacker has no way to obtain the ciphertext corresponding to the extra plaintext bytes they may want to add. </p>
 <p>Apart from that, changing the <em>msg_key</em> would also change the AES decryption key for the message in a way unpredictable for the attacker, so even the original prefix would decrypt to garbage — which would be immediately detected since the app performs a <a href="/mtproto/security_guidelines">security check</a> to ensure that the SHA-256 of the plaintext (combined with a fragment of the <em>auth_key</em>) matches the <em>msg_key</em> received.</p>
 <h3><a class="anchor" name="encrypted-cdns" href="#encrypted-cdns"><i class="anchor-icon"></i></a>Encrypted CDNs</h3>
 <p>As of Telegram 4.2, we support encrypted CDNs for caching media from public channels with over 100.000 members. The CDN caching nodes are located in regions with significant Telegram traffic where we wouldn&#39;t want to place Telegram servers for various reasons.</p>