技术达人常见问题解答

本 MTProto 常见问题解答面向高级用户。您可能还需要查看我们的基础常见问题解答。
请注意，客户端开发人员必须遵守安全准则。

一般性问题

问：为什么选择定制协议？

为了在弱移动网络连接下实现可靠性，并在处理大型文件（例如照片、大型视频以及单个文件最大可达 4 GB 的文件）时保持速度，MTProto 采用了一种独创的方法。本文档旨在阐明我们设置中的一些细节，并指出一些乍一看可能被忽略的重要事项。

问：我可以在哪里阅读更多关于该协议的信息？

详细的协议文档请点击此处查看。请注意，MTProto 支持两层加密：Telegram 云聊天中使用的客户端-服务器加密和 Telegram 秘密聊天中使用的端到端加密。更多信息请参见下文。

如果您有任何意见，请随时联系 security@telegram.org

问：MTProto 中的服务器-客户端加密是如何工作的？

Telegram云聊天中使用了服务器-客户端加密。以下是设置简要概述：

注1

MTProto 中待加密的每条明文消息始终包含以下数据，以便在解密时进行检查，从而使系统能够抵御组件的已知问题：

服务器盐（64 位）
会话 ID
消息序列号
消息长度
时间

注2

有关我们使用IGE和消息认证的更多说明，请参阅相关说明。

注3

Telegram 的端到端加密秘密聊天功能在上述加密的基础上增加了一层加密。

问：MTProto 中的端到端加密是如何工作的？

Telegram 的秘密聊天、语音通话和视频通话均采用端到端加密。您可以点击此处了解更多信息：秘密聊天，端到端加密。以下是设置概览：

详情请参阅以下文章：

问：为什么不使用X？（插入解决方案）

虽然无疑存在其他实现相同加密目标的方法，但我们认为目前的解决方案既稳健又成功完成了我们的次要任务，即在传输时间和稳定性方面击败未加密的即时通讯工具。

问：为什么你们主要依赖传统的加密算法？

我们倾向于使用成熟的算法，这些算法诞生于带宽和处理能力都远比现在稀缺的时代。只要能克服已知的缺点，这对于现代移动开发和传输大文件来说，会有一些有益的附加好处。

此类算法的弱点众所周知，并且已被利用数十年。我们采用的组合方式使用这些算法，据我们所知，可以防止任何已知的攻击。

问：我是一名安全专家，我对你的设置有一些意见。

Telegram 欢迎开发者和安全研究人员对其服务、代码和协议进行审计，以发现漏洞或安全相关问题。请查看我们的官方漏洞赏金计划，了解如何提交您的发现。

请注意，对于在问题解决之前已向公众披露的问题，我们无法提供赏金。

加密

问：MTProto消息是如何进行身份验证的？

所有 Telegram 应用都会确保 msg_key 等于 auth_key 片段与解密后的消息（包含 12 到 1024 字节的随机填充）拼接而成的 SHA-256 校验值。重要的是，明文始终包含消息长度、服务器盐值、session_id 以及其他攻击者无法获取的数据。

至关重要的是，AES 解密密钥依赖于 msg_key 和 auth_key，而这两个密钥只有参与交换的各方才知道。

问：你们采用的是先加密后MAC、先MAC后加密还是先MAC后加密？

严格来说，我们并没有执行上述任何操作。对于消息认证，我们在收到消息后计算 SHA-256(auth_key_fragment + AES_decrypt(…,encrypted_message))，并将该值与随加密消息一起收到的 msg_key 进行比较。

另请参阅：为什么不先加密再进行 MAC 验证？

问：为什么不采用标准的先加密后MAC的方法呢？

使用加密后进行 MAC 验证，例如采用 GCM（伽罗瓦计数器模式），可以让接收方检测到未经授权或修改的密文，从而避免在篡改的情况下对其进行解密。

在 MTProto 协议中，客户端和服务器通过确保 SHA-256(auth_key_fragment + plaintext + padding) = msg_key，并且明文始终包含消息长度、服务器盐值、session_id 以及其他潜在攻击者未知的数据，来验证消息的真实性。这些在客户端执行的安全检查确保无效或被篡改的消息始终会被安全（且静默地）丢弃。

这样我们就能得到相同的结果。区别在于，在先加密后消息认证码（Encrypt-then-MAC）方法中，安全检查是在解密之前执行的；而在MTProto方法中，安全检查是在解密之后执行的——但无论哪种情况，安全检查都是在接受消息之前进行的。目前使用的设备上，AES加密/解密的速度与先加密后消息认证码（Encrypt-then-MAC）方法所需的额外HMAC计算速度相当。

问：你们现在还使用 SHA-1 算法吗？

当前版本的协议使用 SHA-256。MTProto 1.0 以前依赖于 SHA-1（详情请参阅此常见问题解答）。

在 MTProto 2.0 中，仅当哈希函数的选择与安全性无关时才使用 SHA-1，例如：

生成新密钥时
用于从 auth_key 计算 64 位 auth_key_id
用于计算秘密聊天中用于健全性检查的 64 位 密钥指纹（这些不是密钥可视化——它们使用不同的算法，请参阅Diffie-Hellman 密钥的哈希碰撞）

问：你们用IGE吗？IGE出问题了！

是的，我们使用了IGE，但它在我们的实现中并没有失效。我们没有将IGE用作MAC，再加上我们系统的其他特性，使得已知的针对IGE的攻击不再适用。

与普遍使用的 CBC 一样，IGE 也容易受到分块自适应 CPA 攻击。但自适应攻击只有在同一个密钥可以在多个消息中使用时才构成威胁（MTProto并非如此）。

自适应攻击在 MTProto 中理论上是不可能的，因为密钥取决于消息内容，消息必须先完全形成才能加密。至于非自适应 CPA，IGE 和 CBC 都能抵御此类攻击。

验证

问：DH密钥交换期间如何对服务器进行身份验证？

DH 交易所通过内置于客户端的服务器公钥进行身份验证（同一个 RSA 密钥也用于防止中间人攻击）。

问：如何对客户端进行身份验证？

在密钥生成过程中交换的各种秘密（nonce、server_nonce、new_nonce）保证了 DH 密钥只能由发起交换的实例获得。

请注意，new_nonce 只会在客户端到服务器的 RSA 加密消息中显式传输一次。

问：秘密聊天是如何验证身份的？

端到端加密秘密聊天的密钥由新的 DH 密钥交换实例生成，因此只有参与方知道，服务器无法获取。为了确定参与方的身份并确保不存在中间人攻击，建议比较由 DH 秘密聊天密钥哈希值生成的识别图标（密钥可视化）。

问：语音和视频通话如何进行身份验证？

端到端加密通话的密钥使用 Diffie-Hellman 密钥交换算法生成。通话中的用户可以通过比较密钥可视化结果来确保不存在中间人攻击 (MitM)。

为了使语音通话中的密钥验证切实可行，Telegram 对标准的 DH 密钥交换进行了三条消息的修改，用于通话：

A->B：（生成 a 并）发送 g_a_hash := hash(g^a)
B->A：（存储 g_a_hash，生成 b 并）发送 g_b := g^b
A->B：（计算密钥（g_b）^a，然后）发送 g_a := g^a
B：检查 hash(g_a) == g_a_hash，然后计算 key(g_a)^b

其思路是，Alice 确定 a（以及 g_a）的特定值，但直到最后一步才将 g_a 透露给 Bob（或 Eve）。Bob 必须在不知道 g_a 真实值的情况下选择 b 和 g_b 的值。如果 Eve 发起中间人攻击，她既不能根据从 Bob 那里得到的 g_b 值来改变 a 的值，也不能根据 g_a 来调整 b 的值。因此，Eve 只有一次机会注入参数——而且她必须在完全保密的情况下执行这次操作。

得益于这项改进，只需在可视化中使用略多于 33 比特的熵，即可将窃听（针对 DH 的中间人攻击）的概率提升至 0.99999999999 以上。这些熵以四个表情符号的形式呈现给用户。我们精心挑选了 333 个表情符号，它们彼此之间差异显著，并且可以用任何语言的简单词汇轻松描述。

您可以在此处阅读有关 Telegram 通话密钥验证的更多信息。

问：你们有前向保密功能吗？

MTProto 在云聊天和秘密聊天中都支持完美前向保密。

抵御已知攻击

已知明文攻击

根据定义，已知明文攻击（KPA）是一种密码分析攻击模型，攻击者同时拥有明文及其加密版本（密文）的样本。

MTProto 中使用的 AES IGE 对 KPA 攻击具有鲁棒性（如果您想了解如何安全使用 IGE，请参阅此处）。此外，明文在 MTProto 中始终包含 server_salt 和唯一的会话 ID。

选择明文攻击

根据定义，选择明文攻击（CPA）是一种密码分析攻击模型，假设攻击者有能力选择任意明文进行加密并获取相应的密文。

MTProto 使用 IGE 模式的 AES（如果您想了解如何安全使用 IGE，请参阅此处），它对非自适应 CPA 具有安全性。IGE 已知对分块自适应 CPA 不安全，但 MTProto 通过以下方式修复了这一问题：

每条待加密的明文消息始终包含以下内容，在解密时进行检查：

服务器盐（64 位）
消息序列号
时间

此外，为了替换明文，您还需要使用正确的 AES 密钥和 iv，两者都依赖于 auth_key。这使得 MTProto 对 CPA 具有鲁棒性。

选择密文攻击

根据定义，选择密文攻击（CCA）是一种密码分析攻击模型，密码分析师至少部分地通过选择密文并在未知密钥下获取其解密来收集信息。在攻击中，对手有机会将一个或多个已知密文输入系统并获取结果明文。从这些信息中，对手可以尝试恢复用于解密的隐藏密钥。

每次在 MTProto 中解密消息时，都会执行检查以确保 msg_key 等于 auth_key 片段与解密消息（包括 12…1024 字节的随机填充）拼接后的 SHA-256。明文（解密数据）还始终包含消息长度、服务器盐和序列号。这否定了已知的 CCA。

IND-CCA 怎么样？

MTProto 2.0 满足选择密文攻击下不可区分性（IND-CCA）的条件。

阅读有关 MTProto 1.0 中 IND-CCA 的更多信息

回放攻击

回放攻击被拒绝，因为每条待加密的明文都包含服务器盐和唯一的消息 ID 及序列号。

这意味着每条消息只能发送一次。

中间人攻击

Telegram 有两种通信模式——使用客户端-服务器加密的普通聊天和使用端到端加密的秘密聊天。

客户端-服务器通信在 DH 密钥生成期间通过嵌入在客户端软件中的服务器 RSA 公钥来防止 MiTM 攻击。之后，如果两个客户端都信任服务器软件，则它们之间的秘密聊天将受到服务器的保护，免受 MiTM 攻击。

该接口为不信任服务器的用户提供了一种比较秘密聊天密钥的方式。密钥的可视化以身份图标的形式呈现（示例在此）。通过比较密钥可视化，用户可以确保没有发生 MITM 攻击。

DH 密钥的哈希冲突

目前，指纹使用 128 位 SHA-1 与 160 位密钥 SHA-256 拼接，共产生 288 位指纹位，从而否定了哈希冲突攻击的可能性。

阅读有关早期版本 Telegram 中指纹的更多信息

长度扩展攻击

根据定义，长度扩展攻击是一种攻击类型，当某些类型的哈希被误用作消息认证码时，允许包含额外信息。

MTProto 中的消息由 msg_key 组成，它等于 auth_key 片段与明文（包括 12…1024 字节的随机填充和一些附加参数）拼接后的 SHA-256，后面是密文。攻击者无法在末尾附加额外字节并重新计算 SHA-256，因为 SHA-256 是从明文计算的，而不是密文，攻击者无法获取与他们可能想要添加的额外明文字节对应的密文。

除此之外，更改 msg_key 还会以攻击者不可预测的方式更改消息的 AES 解密密钥，因此即使原始前缀也会解密为乱码——这将立即被检测到，因为应用程序会执行安全检查以确保明文的 SHA-256（与 auth_key 片段组合）与收到的 msg_key 匹配。

加密 CDN

从 Telegram 4.2 开始，我们支持加密 CDN 来缓存拥有超过 100,000 名成员的公共频道的媒体。CDN 缓存节点位于 Telegram 流量显著的地区，但由于各种原因，我们不希望在这些地区放置 Telegram 服务器。

有关实现、加密和数据验证的技术细节，请参阅 CDN 手册。

有关此常见问题解答的波斯语版本，请参阅此文档。

问：为什么你们决定使用 CDN？

我们使用自己的分布式服务器来加速言论自由得到保障的地区的下载速度——即使在那里，我们也不会将此视为理所当然。但是当 Telegram 在其他地区变得非常流行时，我们只能依赖 CDN，从技术角度来看，我们将其视为 ISP，因为它们只获取无法解密的加密数据。

得益于这项技术，土耳其、印度尼西亚、南美洲、印度、伊朗或伊拉克等地区的公共照片和视频下载速度可以显著提高，而安全性不会有丝毫妥协。

问：CDN 可以解密文件吗？

不能。发送到 CDN 的每个文件都使用 AES-256-CTR 加密并使用唯一密钥加密。CDN 无法访问其存储的数据，因为这些密钥只有主 MTProto 服务器和授权客户端才能访问。

问：CDN 可以用自己的版本替换数据吗？

不能。从 CDN 缓存节点下载的数据始终由接收 Telegram 应用程序通过哈希进行验证：攻击者无法用自己的版本替换任何文件。

问：CDN 可以删除任何文件吗？

不能。CDN 节点只缓存文件的加密副本，原始文件存储在 Telegram 服务器上。用户收到文件的通知来自 Telegram 服务器。如果 CDN 缓存节点没有向用户提供文件，用户将直接从 Telegram 服务器接收文件。

问：CDN 可以用于审查吗？

不能。所有原始文件都存储在 Telegram 服务器上。CDN 只获取加密数据——它们无法解密。它们无法替换任何数据。如果 CDN 出现任何问题，文件将直接从 Telegram 服务器传递给用户。用户将始终获得他们的数据，没有人可以阻止这一点。

问：我可以验证这一点吗？

可以。任何人都可以通过检查 Telegram 应用程序的源代码并检查流量来验证我们的 CDN 实现。

问：这会影响私人数据吗？

不会。CDN 缓存节点不是 Telegram 云的一部分。CDN 缓存节点仅用于缓存大型频道的流行公共媒体。私人数据永远不会到达那里。

问：这是否与政府要求将私人数据移至其领土有关？

不是。我们没有与任何政府就 CDN 达成任何协议，CDN 也不是任何交易的一部分。CDN 的唯一目的是在 Telegram 无法放置服务器的高需求地区安全地改善连接。

问：这是否赋予某些国家对 Telegram 的影响力？

不会。我们已采取特别预防措施，确保没有国家可以通过 CDN 缓存节点对 Telegram 施加任何影响：

CDN 不属于 Telegram——所有风险都由向我们提供全球 CDN 节点的第三方公司承担。
我们没有对这些 CDN 进行任何投资，只会为将缓存项目从我们的主集群传递到最终用户的流量付费。

因此，如果任何国家决定干扰其所在地区的 CDN，除了降低本国公民的网络连接之外，他们一无所获——而 Telegram 也不会损失任何价值。

还有其他问题？请查看我们的基础常见问题解答或联系 security@telegram.org