完美的前向保密
Telegram 从第 20 层开始支持秘密聊天中的完美前向保密 (PFS)。请参阅更新到新层。
任何参与秘密聊天的客户端都可以在感知到当前密钥已使用时间过长或用于加密过多消息时为了确保过去的通信安全，一旦使用密钥对超过 100 条消息进行解密和加密，或已使用超过一周，官方 Telegram 客户端将启动重新加密，前提是该密钥已用于加密至少一条消息。旧密钥随后会被安全丢弃且无法重建，即使访问当前正在使用的新密钥也是如此。
任何参与秘密聊天的客户端都可以在感知到当前密钥已使用时间过长或用于加密过多消息时立即启动重新输入密钥。请注意，如果存在由任何一方发起的未完成的实例，则永远不应启动重新键入协议的新实例。
注意：第三方开发人员需要保持相同级别的安全性。所有具有秘密聊天支持的客户端都必须能够启动重新键入并接受相关的服务消息。请参阅安全指南。
重新加密协议
新密钥是通过交换特殊消息生成的，使用先前建立的密钥进行加密。A 方和 B 方之间的密钥更新协议通常包括四个步骤：
1.解密的MessageActionRequestKey
A（密钥更新发起者）生成一个新值a ，受到与初始 Diffie-Hellman 密钥交换相同的限制，并将pow(g,a)的值发送给 B，嵌入在decryptedMessageService中：
decryptedMessageActionRequestKey exchange_id:long g_a:string = DecryptedMessageAction;
exchange_id是一个随机数，用于标识双方的此 Re-Keying Protocol 实例
请注意，在此秘密聊天中使用与初始 Diffie-Hellman 密钥交换相同的 Diffie-Hellman 参数(p,g) 。它们不需要明确地重新传输。
2.解密的MessageActionAcceptKey
收到上述服务消息后，B 检查其内容，并为新生成的b值生成具有相同exchange_id的响应：
decryptedMessageActionAcceptKey exchange_id:long g_b:string key_fingerprint:long = DecryptedMessageAction;
exchange_id与收到的decryptedMessageActionRequestKey相同
g_b是pow(g,b) mod p的值
key_fingerprint是新生成的key = pow(g_a, b) mod p的 64 位指纹，用作实现的健全性检查在这个阶段，B 已经可以计算出新的密钥key = pow(g_a, b) mod p和它的key_fingerprint（它的 SHA-1 的最后 64 位）。但是，它会继续使用之前的密钥，直到交换完成。
一旦 B 方发送了decryptedMessageActionAcceptKey，它就不能中止密钥交换；它必须准备好在decryptedMessageActionCommitKey收到 a 后立即切换到新密钥。因此，如果 B 方希望延迟新密钥的使用，例如为了先填补一些 seq_no 空白，它必须decryptedMessageActionAcceptKey相应地延迟回答。
3. 解密的MessageActionCommitKey
一旦 A 收到一个 valid decryptedMessageActionAcceptKey，它就会执行所有必要的检查，并通过以下服务消息“提交”新密钥：
decryptedMessageActionCommitKey exchange_id:long key_fingerprint:long = DecryptedMessageAction;
exchange_id与前两条消息中的相同telegrami.html' target='_blank' title='TG安卓版下载' >TG安卓版下载
key_fingerprint是 A 计算的新密钥的哈希值（SHA-1 的最后 64 位），用于实现完整性检查
之后，A 可以（并且必须）使用新密钥加密所有后续消息。
如果 A 方希望延迟安装新密钥，例如因为它想先填充一些 seq_no 间隙，则它必须相应地延迟 decryptedMessageActionCommitKey回答。
