图解 mtproto-core深入剖析 MTProto 授权握手流程PQ 分解与 DH 密钥交换【免费下载链接】mtproto-coreTelegram API JS (MTProto) client library for Node.js and browser项目地址: https://gitcode.com/gh_mirrors/mt/mtproto-coremtproto-core 是一个面向 Node.js 和浏览器的Telegram API JS (MTProto) 客户端库它把复杂的加密握手细节全部封装在内部让开发者可以像调用普通函数一样调用 Telegram API。但在每次登录之前客户端都必须与服务器完成一次秘密握手——MTProto 授权握手流程其中最关键的两个密码学环节就是PQ 分解与DH 密钥交换。本文用图解的方式带你一步步拆解这条握手链路。为什么需要 PQ 分解与 DH 密钥交换MTProto 协议要求客户端在正式通信前与服务器协商出一个只有双方知道的auth_key授权密钥。这个密钥不能直接通过网络传输否则会被中间人窃取。Telegram 采用的解决方案是PQ 分解证明客户端有能力做大数质因数分解为 RSA 加密协商打好基础DH 密钥交换双方各自生成随机数通过模幂运算得到相同的共享密钥即便中间人截获所有流量也无法还原密钥。整个过程不传输密钥本身只交换半成品参数安全性和数学原理都源于离散对数难题。图解授权握手全流程七个关键步骤把整个握手浓缩成一张时序图先建立整体印象客户端 (mtproto-core) 服务器 │ │ │ ① req_pq_multi (nonce) ───────────────→│ │ │ │ ② resPQ (pq, server_nonce, 公钥指纹) ←─│ │ │ │ ③ PQ分解 pq p × q │ │ RSA加密 p_q_inner_data │ │ ④ req_DH_params ──────────────────────→│ │ │ │ ⑤ server_DH_inner_data (AES-IGE) ←─────│ │ │ │ ⑥ 生成 b, 计算 authKey g_a^b │ │ set_client_DH_params (g_b) ────────→│ │ │ │ ⑦ dh_gen_ok (new_nonce_hash) ←────────│ │ │ ▼ ▼ 握手完成启用 AES 加密通信接下来逐一剖析每一步在 mtproto-core 源码中的实现位置与原理。第一步客户端发起握手——req_pq_multi 请求如何生成一切始于客户端建立 TCP/WebSocket 连接之后。在 src/rpc/index.js 的handleTransportOpen中如果本地没有缓存的authKey客户端会生成一个16 字节随机 nonce并发送mt_req_pq_multi明文请求生成的nonce用于后续防重放校验服务器会在响应中原样返回此时还没密钥消息以明文传输sendPlainMessage只携带握手所需的最小信息。第二步PQ 分解——如何把大整数拆成两个质数服务器返回resPQ包含一个大整数pq、server_nonce以及一组服务器公钥指纹。客户端要做的事是把pq分解成两个质数p × q。这看似简单却是整个握手的能力证明。在 src/crypto/pq/index.js 中pqPrimeFactorization调用pqLeemon实现了Pollards Rho 质因数分解算法基于 leemon 大数库。算法通过随机迭代与最大公约数计算在多项式期望时间内找到因子引入多轮随机种子3 轮每轮逐步扩大迭代上限1 (i 18)一旦eGCD结果不是 1就找到了一个非平凡因子最终返回[P, Q]和迭代次数P ≤ Q保证后续序列化一致。这是纯数学密集型计算也是客户端诚意的体现——服务器据此判断请求方是真实客户端而非攻击脚本。第三步RSA 加密与 p_q_inner_data 的构造拿到p、q后客户端构造p_q_inner_data包含pq、p、q、nonce、server_nonce和一个32 字节的新随机数 new_nonce。new_nonce 是之后派生临时密钥和最终 auth_key 的核心原料。这段数据不能明文发送必须用服务器公钥加密。在 src/utils/rsa/index.js 中getRsaKeyByFingerprints用服务器返回的公钥指纹匹配内置的 5 个公钥数据先做 SHA1 哈希再填充随机字节到255 字节最后执行 RSA 模幂加密encrypt加密结果随req_DH_params发给服务器服务器用私钥解出 p、q、new_nonce。第四步解析服务端返回的 Server DH 参数服务器验证数据后返回server_DH_inner_data里面携带dh_prime2048 位大质数、生成元g、g_a服务器侧的 DH 公钥和server_time。这个响应是加密的密钥由双方各自独立推导在 src/rpc/index.js 的handleDHParams中客户端用new_nonce和server_nonce通过多组 SHA1 拼接构造出tmp_aes_key 与 tmp_aes_iv再用AES-IGE 模式解密实现见 src/crypto/aes/index.js并校验解密内容的 SHA1 哈希防止篡改。第五步DH 密钥交换——auth_key 的本地生成与安全校验解密成功后进入核心的 DH 密钥交换阶段generateDH客户端生成随机私钥b256 字节计算authKey g_a^b mod dh_prime——由于服务器知道自己的a且g_a g^a它也能算出同样的结果计算serverSalt new_nonce 前 8 字节 ⊕ server_nonce 前 8 字节用于后续消息加盐把authKey和serverSalt写入 storage 缓存下次启动直接复用跳过握手。同时verifyDhParams 做了一系列安全边界校验g必须等于 3、dh_prime必须匹配官方固定值、g_a不能小于2^(2048-64)等从源头杜绝小指数攻击和弱参数注入。第六步AES-IGE 加密与 set_client_DH_params 提交客户端构造client_DH_inner_data包含nonce、server_nonce、retry_id和客户端侧的 DH 公钥g_b g^b mod dh_prime。数据同样先 SHA1 再填充随机字节对齐到 16 字节整数倍用之前推导的tmp_aes_key/tmp_aes_iv 以 AES-IGE 模式加密通过set_client_DH_params提交给服务器。服务器解密后即可组合出完整的 auth_key。第七步dh_gen_ok 确认——握手完成与加密通道启用服务器收到g_b后计算确认哈希并返回三种结果之一见 handleDHAnswer响应类型校验目标含义mt_dh_gen_oknew_nonce_hash1握手成功 ✅mt_dh_gen_retrynew_nonce_hash2密钥不一致携带authKeyAuxHash重试 mt_dh_gen_failnew_nonce_hash3握手失败直接报错 ❌客户端用SHA1(new_nonce [1/2/3] auth_key_aux_hash)截取第 5 到 20 字节来比对哈希。校验通过后isAuth true此后的所有消息都走 AES-IGE 加解密见sendEncryptedMessage与handleEncryptedMessage并支持消息确认ack、序列号seq_no等完整机制。安全性要点总结把整个流程的安全性亮点归纳如下️防重放nonce 与 server_nonce 在每一步都被校验任何一步不匹配立即中止防篡改每一步敏感数据都有 SHA1 哈希校验RSA 加密保证只有服务器能解密密钥不下线auth_key 永远通过 DH 模幂协商得出网络上从未传输过密钥本身参数校验g、dh_prime、g_a 的严格边界检查阻断弱参数攻击本地缓存authKey 与 serverSalt 持久化二次启动秒级恢复会话。如果涉及账号密码登录2FAmtproto-core 还在 src/crypto/index.js 内置了完整的SRP-6a 参数计算PBKDF2 100000 次迭代与本次握手相互独立、各司其职。结语通过这篇图解你应该已经掌握了 mtproto-core 中MTProto 授权握手流程的完整链路从 nonce 握手、PQ 分解、RSA 加密到 DH 密钥交换与 AES-IGE 加密确认每一步都在 src/rpc/index.js 中有清晰的函数实现配合 scheme/mtproto.json 中的协议定义非常适合作为学习 MTProto 协议细节的入口。理解了这层秘密握手再看 Telegram 生态的登录、消息收发与更新推送一切都豁然开朗。【免费下载链接】mtproto-coreTelegram API JS (MTProto) client library for Node.js and browser项目地址: https://gitcode.com/gh_mirrors/mt/mtproto-core创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 图解 mtproto-core：深入剖析 MTProto 授权握手流程（PQ 分解与 DH 密钥交换）
图解 mtproto-core深入剖析 MTProto 授权握手流程PQ 分解与 DH 密钥交换【免费下载链接】mtproto-coreTelegram API JS (MTProto) client library for Node.js and browser项目地址: https://gitcode.com/gh_mirrors/mt/mtproto-coremtproto-core 是一个面向 Node.js 和浏览器的Telegram API JS (MTProto) 客户端库它把复杂的加密握手细节全部封装在内部让开发者可以像调用普通函数一样调用 Telegram API。但在每次登录之前客户端都必须与服务器完成一次秘密握手——MTProto 授权握手流程其中最关键的两个密码学环节就是PQ 分解与DH 密钥交换。本文用图解的方式带你一步步拆解这条握手链路。为什么需要 PQ 分解与 DH 密钥交换MTProto 协议要求客户端在正式通信前与服务器协商出一个只有双方知道的auth_key授权密钥。这个密钥不能直接通过网络传输否则会被中间人窃取。Telegram 采用的解决方案是PQ 分解证明客户端有能力做大数质因数分解为 RSA 加密协商打好基础DH 密钥交换双方各自生成随机数通过模幂运算得到相同的共享密钥即便中间人截获所有流量也无法还原密钥。整个过程不传输密钥本身只交换半成品参数安全性和数学原理都源于离散对数难题。图解授权握手全流程七个关键步骤把整个握手浓缩成一张时序图先建立整体印象客户端 (mtproto-core) 服务器 │ │ │ ① req_pq_multi (nonce) ───────────────→│ │ │ │ ② resPQ (pq, server_nonce, 公钥指纹) ←─│ │ │ │ ③ PQ分解 pq p × q │ │ RSA加密 p_q_inner_data │ │ ④ req_DH_params ──────────────────────→│ │ │ │ ⑤ server_DH_inner_data (AES-IGE) ←─────│ │ │ │ ⑥ 生成 b, 计算 authKey g_a^b │ │ set_client_DH_params (g_b) ────────→│ │ │ │ ⑦ dh_gen_ok (new_nonce_hash) ←────────│ │ │ ▼ ▼ 握手完成启用 AES 加密通信接下来逐一剖析每一步在 mtproto-core 源码中的实现位置与原理。第一步客户端发起握手——req_pq_multi 请求如何生成一切始于客户端建立 TCP/WebSocket 连接之后。在 src/rpc/index.js 的handleTransportOpen中如果本地没有缓存的authKey客户端会生成一个16 字节随机 nonce并发送mt_req_pq_multi明文请求生成的nonce用于后续防重放校验服务器会在响应中原样返回此时还没密钥消息以明文传输sendPlainMessage只携带握手所需的最小信息。第二步PQ 分解——如何把大整数拆成两个质数服务器返回resPQ包含一个大整数pq、server_nonce以及一组服务器公钥指纹。客户端要做的事是把pq分解成两个质数p × q。这看似简单却是整个握手的能力证明。在 src/crypto/pq/index.js 中pqPrimeFactorization调用pqLeemon实现了Pollards Rho 质因数分解算法基于 leemon 大数库。算法通过随机迭代与最大公约数计算在多项式期望时间内找到因子引入多轮随机种子3 轮每轮逐步扩大迭代上限1 (i 18)一旦eGCD结果不是 1就找到了一个非平凡因子最终返回[P, Q]和迭代次数P ≤ Q保证后续序列化一致。这是纯数学密集型计算也是客户端诚意的体现——服务器据此判断请求方是真实客户端而非攻击脚本。第三步RSA 加密与 p_q_inner_data 的构造拿到p、q后客户端构造p_q_inner_data包含pq、p、q、nonce、server_nonce和一个32 字节的新随机数 new_nonce。new_nonce 是之后派生临时密钥和最终 auth_key 的核心原料。这段数据不能明文发送必须用服务器公钥加密。在 src/utils/rsa/index.js 中getRsaKeyByFingerprints用服务器返回的公钥指纹匹配内置的 5 个公钥数据先做 SHA1 哈希再填充随机字节到255 字节最后执行 RSA 模幂加密encrypt加密结果随req_DH_params发给服务器服务器用私钥解出 p、q、new_nonce。第四步解析服务端返回的 Server DH 参数服务器验证数据后返回server_DH_inner_data里面携带dh_prime2048 位大质数、生成元g、g_a服务器侧的 DH 公钥和server_time。这个响应是加密的密钥由双方各自独立推导在 src/rpc/index.js 的handleDHParams中客户端用new_nonce和server_nonce通过多组 SHA1 拼接构造出tmp_aes_key 与 tmp_aes_iv再用AES-IGE 模式解密实现见 src/crypto/aes/index.js并校验解密内容的 SHA1 哈希防止篡改。第五步DH 密钥交换——auth_key 的本地生成与安全校验解密成功后进入核心的 DH 密钥交换阶段generateDH客户端生成随机私钥b256 字节计算authKey g_a^b mod dh_prime——由于服务器知道自己的a且g_a g^a它也能算出同样的结果计算serverSalt new_nonce 前 8 字节 ⊕ server_nonce 前 8 字节用于后续消息加盐把authKey和serverSalt写入 storage 缓存下次启动直接复用跳过握手。同时verifyDhParams 做了一系列安全边界校验g必须等于 3、dh_prime必须匹配官方固定值、g_a不能小于2^(2048-64)等从源头杜绝小指数攻击和弱参数注入。第六步AES-IGE 加密与 set_client_DH_params 提交客户端构造client_DH_inner_data包含nonce、server_nonce、retry_id和客户端侧的 DH 公钥g_b g^b mod dh_prime。数据同样先 SHA1 再填充随机字节对齐到 16 字节整数倍用之前推导的tmp_aes_key/tmp_aes_iv 以 AES-IGE 模式加密通过set_client_DH_params提交给服务器。服务器解密后即可组合出完整的 auth_key。第七步dh_gen_ok 确认——握手完成与加密通道启用服务器收到g_b后计算确认哈希并返回三种结果之一见 handleDHAnswer响应类型校验目标含义mt_dh_gen_oknew_nonce_hash1握手成功 ✅mt_dh_gen_retrynew_nonce_hash2密钥不一致携带authKeyAuxHash重试 mt_dh_gen_failnew_nonce_hash3握手失败直接报错 ❌客户端用SHA1(new_nonce [1/2/3] auth_key_aux_hash)截取第 5 到 20 字节来比对哈希。校验通过后isAuth true此后的所有消息都走 AES-IGE 加解密见sendEncryptedMessage与handleEncryptedMessage并支持消息确认ack、序列号seq_no等完整机制。安全性要点总结把整个流程的安全性亮点归纳如下️防重放nonce 与 server_nonce 在每一步都被校验任何一步不匹配立即中止防篡改每一步敏感数据都有 SHA1 哈希校验RSA 加密保证只有服务器能解密密钥不下线auth_key 永远通过 DH 模幂协商得出网络上从未传输过密钥本身参数校验g、dh_prime、g_a 的严格边界检查阻断弱参数攻击本地缓存authKey 与 serverSalt 持久化二次启动秒级恢复会话。如果涉及账号密码登录2FAmtproto-core 还在 src/crypto/index.js 内置了完整的SRP-6a 参数计算PBKDF2 100000 次迭代与本次握手相互独立、各司其职。结语通过这篇图解你应该已经掌握了 mtproto-core 中MTProto 授权握手流程的完整链路从 nonce 握手、PQ 分解、RSA 加密到 DH 密钥交换与 AES-IGE 加密确认每一步都在 src/rpc/index.js 中有清晰的函数实现配合 scheme/mtproto.json 中的协议定义非常适合作为学习 MTProto 协议细节的入口。理解了这层秘密握手再看 Telegram 生态的登录、消息收发与更新推送一切都豁然开朗。【免费下载链接】mtproto-coreTelegram API JS (MTProto) client library for Node.js and browser项目地址: https://gitcode.com/gh_mirrors/mt/mtproto-core创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考