Telegram 加密密钥是如何排列的？

根据一般常见问题解答，您可以找到有关存储在服务器上的信息的密钥的一些信息：

• 秘密聊天根本不存储在那里。钥匙是不可能的。
• 对于非机密聊天，他们声称在多个司法管辖区分发密钥，因此需要多个法院的命令来披露任何信息。要做到这一点，必须发生一些非同寻常的事情。

根据技术人员（技术倾向）的常见问题，我们可以得出一些关于解密传输流量的可能性的结论：

• 由于Diffie-Hellman (DH)协商的密钥在传输过程中无处不在，如果 Telegram 服务器不存储会话密钥（理论上可以，但几乎没有），则很可能无法解密先前记录的数据。因为服务器和客户端都可能很长时间都忘记了它们的密钥。
• Telegram 有一个用于服务器身份验证的私有RSA密钥，其公共“兄弟”被硬连接到客户端。使用此私钥，可以安排MITM 攻击，迫使受控网络中的客户端将自己的服务器视为真正的 Telegram 服务器，因此客户端将认为该通道受信任并继续与冒名顶替者协商会话密钥，反过来，谁将能够代表客户端与真实服务器联系。
• Telegram 具有会话DH密钥，用于与特定客户端（并且多个客户端可以从一个帐户连接）有关云聊天（没有端到端加密）进行通信。当您可以随时就一个新密钥达成一致时，保存它们是没有意义的，因此，尽管这个密钥存在，但很有可能公开它是没有意义的，因为它不会长期有效。
• 对于秘密聊天，生成DH密钥以保护不与服务器的交互，而是直接与收件人的交互。因此，服务器在任何阶段都不会收到准备好的密钥，即使记录了密钥协商过程的流量，也无法生成它们。因为它是Diffie-Hellman。

由于 Telegram 鼓吹最大程度的隐私，因此有理由相信它们不存储会话密钥。基于所有这些，FSB 可以与两种类型的密钥相交，因为它们是唯一具有足够生命周期的密钥，因此提前接收它们是有意义的：

• 服务器的私有RSA密钥 - 是的，他们无法解密任何内容，但在它的帮助下，您可以从真实的 Telegram 服务器获取会话密钥并解密您可以使用它请求的数据：据说是来自真实服务器的客户端。也就是说，执行MITM 攻击。
• 如果您突然设法从 Telegram 服务器的磁盘中获取数据，则用于云聊天服务器硬盘上的数据的加密密钥（未知类型） （秘密密钥仅在客户端设备上以解密形式存在）。它们有多少，每个密钥的范围是多少，由于 Telegram 服务器代码的紧密性，不确定，具有这些密钥的客户端无法以任何方式工作；理论上，可能没有加密。这些密钥至少在存在来自服务器的磁盘时具有一定的意义。而且即使在这种情况下，全盘加密也可以把猪放进去。

当然，我假设 Diffie-Hellmann 协议和 RSA 在它们应该存在的地方非常安全。如果他们真的取得了突破，Telegram 的可持续性将是最不重要的问题。Internet 上的大部分交互都基于这些协议——例如 HTTPS。

从这个文档“专家1号解释”来看，可以得出Diffie-Hellman（shared secret generation）、RSA（authentication）、AES（encryption）用于加密流量。换句话说，此捆绑包提供与 TLS 中的密码套件相同的安全级别：TLS_DHE_RSA_WITH_AES_...

在密钥传输下，它们很可能意味着服务器的私有 RSA 密钥的传输。（在 TLS 的情况下，这将是从证书传输私钥）。拥有此密钥的人将能够使用中间人解密（和修改）流量。同时，如果他们之前保存了流量，他们将来将无法使用私钥（如perfect forward secrecy在 TLS 中）对其进行解密。