调研日期：2026-10-08 证据层级说明：【官】官方文档确认（telegram.org / core.telegram.org）｜【学】学术论文分析｜【社】社区验证（开源客户端代码、长期一致的多方指南）｜【推】合理推测（已标注依据）

0. 关键结论摘要表

维度结论证据层级
功能定位手动开启的一对一 E2E 聊天；默认云聊天/群组/频道均为服务端可读【官】
密钥交换2048 位安全素数上的经典 DH（g∈{2..7}），非 X25519；共享密钥 256 字节【官】
密钥验证客户端把密钥渲染成图形，用户线下比对防 MITM；64 位指纹仅用于开发排错【官】
前向保密>100 条消息或 >1 周（且至少发过 1 条）即 re-keying，旧密钥销毁【官】
设备绑定密钥绑定授权（设备），不进云；登出/重装/换设备即永久丢失，不可迁移【官】
自毁计时器1秒–1周共 6 档，阅读后开始计时；服务端看不到计时器，由客户端执行【官】+【推】
禁转发/双向删除客户端强制 + E2E 服务消息实现【官】
截图Android 系统级拦截（FLAG_SECURE），iOS 截屏后通知对方；均可被绕过【社】
群组私密聊天不支持，协议层面仅支持一对一【官】
客户端支持仅 Android / iOS / macOS(App Store 版)；Desktop 与 Web 不支持【社】
推送元数据学术研究证实 Telegram 未向 FCM/Google 泄露消息内容或个人信息【学】
已知密码学弱点re-keying 存在 unknown key-share 理论弱点；初始 DH 无认证，依赖人工比对【学】
近两年协议改动无官方公告的私密聊天协议改动【官】+【社】

1. 功能定位与入口

1.1 是什么

私密聊天是 Telegram 中手动开启的、一对一的端到端加密聊天。官方 FAQ 定位其为"想要比普通人更多保密性的人"准备的功能：全部消息使用端到端加密，只有对话双方能读，“包括 Telegram 自己在内无人能解密”【官】。它与默认的云聊天是两套并行的产品形态，而非同一聊天的"加密模式"开关。

1.2 各客户端发起路径

  • Android / iOS：打开对方个人资料页 → 点「…」→「Start Secret Chat」并确认；或从新建消息入口选「New Secret Chat」再选联系人【官】【社】。
  • macOS（App Store 版，TelegramSwift 系）：支持发起与使用【社】。
  • Telegram Desktop（Qt 版，Windows/macOS/Linux）与 Telegram Web（WebZ/WebK）：不支持。GitHub tdesktop 上关于私密聊天的 feature request（#5、#844 等）累计上百个，长期未实现；bugs.telegram.org 的 WebZ 缺失功能清单中明确列有 Secret Chats【社】。Telegram 官方给出的理由是"桌面不如手机私密"（多人共用、易被网管监控等），社区普遍认为该解释牵强【社】。
  • 注意：部分内容站把"桌面版支持私密聊天"写进对比表（如 clixsensesuccess.com），与上述所有一手来源矛盾，判定为错误信息，不予采信。

1.3 是否支持群组私密聊天

不支持。官方文档开篇即定义：“Secret Chats are one-on-one chats”【官】。协议层面没有群组成员密钥分发机制；同一联系人可建立多个并行的私密聊天（每个对应不同设备），但无法把第三人加入【官】。

2. 加密机制

2.1 密钥交换流程（Diffie-Hellman 细节）

以下全部来自官方 MTProto 文档（core.telegram.org/api/end-to-end）【官】：

  1. 取参：A 调用 messages.getDhConfig 获取 DH 参数——2048 位安全素数 p（p 与 (p−1)/2 均为素数，2^2047 < p < 2^2048），以及生成元 g（恒为 2–7 之一，且为 p 的二次剩余）。客户端必须自行校验 p、g 的合法性（文档给出用二次互反律的快速判定条件，如 g=2 时要求 p mod 8 = 7 等）；发起方 A 在建立每个新密钥前都应重新获取/核验参数。
  2. 发起：A 生成 2048 位随机秘密数 a，计算 g_a = g^a mod p，随 messages.requestEncryption 发出。B 的所有已授权设备都会收到 updateEncryption(encryptedChatRequested) 弹窗，由用户决定接受或拒绝。
  3. 接受：B 同样生成 2048 位随机数 b，计算共享密钥 key = g_a^b mod p（不足 256 字节则前导补零至恰好 256 字节/2048 位），并把 g_b = g^b mod p 与 key_fingerprint 回传（messages.acceptEncryption）。
  4. 确认：A 计算 key = g_b^a mod p，比对指纹一致后方可收发消息；不一致则执行 messages.discardEncryption 并通知用户。
  5. 双方必须校验 g、g_a、g_b ∈ (1, p−1)，并推荐校验其落在 [2^1984, p−2^1984] 区间内（TDLib 实现中为强制检查）【官】【社】。

澄清一点常见误传：部分中文营销号文章称私密聊天用 “X25519 + AES-256-GCM”，这是把 Signal 协议的原语张冠李戴了。官方文档明确为经典模幂 DH + AES-256-IGE，消息密钥派生走 SHA-256 KDF【官】。

2.2 密钥可视化 / 指纹验证（防 MITM 的人工环节）

这是整个设计中最关键、也最依赖用户的一环：

  • 64 位 key_fingerprint（SHA1(key) 低 64 位；注意 MTProto 2.0 下此处仍用 SHA1）仅用于开发调试排错，与用户验证无关——官方文档用专门的 Note 强调了这一点【官】。
  • 真正供用户比对的是"密钥可视化"：客户端把 SHA1(初始密钥)前128位 + SHA256(升级到 layer 46 时所用密钥)前160位 渲染成一张图形（彩色方块图），双方通过线下/可信渠道比对图形是否一致来确认没有中间人【官】。
  • 风险：初始 DH 交换本身没有任何签名或身份认证——服务器完全有能力对 g_a/g_b 做 MITM。如果双方跳过图形比对，MITM 在密码学上不可被察觉。这是学术界反复指出的根本性弱点（见 §6）【学】。

2.3 前向保密（Forward Secrecy）

  • 触发条件（官方文档原话）：当密钥被用于加解密超过 100 条消息，或连续使用超过 1 周（且该密钥至少加密过 1 条消息）时，官方客户端发起 re-keying；旧密钥被安全销毁，“即使拿到新密钥也无法重建旧密钥”【官】。
  • re-keying 流程：复用建聊时的同一组 (g,p) 参数，双方在已建立的 E2E 加密通道内交换新的 DH 半密钥（四步服务消息：RequestKey → AcceptKey → CommitKey），新密钥协商完成后旧密钥删除。任何一方都可发起，但不得在已有未完成的交换时再发起新的【官】。
  • 自 Layer 20 起支持；第三方客户端必须实现 re-keying 才能与官方客户端互通【官】。
  • 学术评价：Miculan 等人的形式化验证确认了该机制提供的前向保密性，但也指出"泄露一个会话密钥最多暴露 100 条消息或一周消息，在某些场景下这个窗口仍可能过宽"【学】。

2.4 消息加密原语（MTProto 2.0）

  • AES-256-IGE；每条消息的 msg_key = SHA256(共享密钥中 32 字节 + 明文 + 12~1024 字节随机填充)的中间 128 位；AES 密钥/IV 由两次 SHA-256 派生，发送方向不同则 x 取 0/8 以隔离【官】。
  • 文件使用与聊天密钥完全无关的一次性密钥：发送前生成随机 256 位 AES key + IV，密文分片上传服务器，解密密钥随 E2E 消息体发送【官】。

3. 设备绑定与同步

  • 为什么只存在于发起设备：官方文档明确——“Secret chats are associated with specific devices (or rather with authorization keys), not users.” 密钥只存于两端设备的本地授权中，从不上传服务器、不进入云同步体系【官】。
  • 接受方的设备锁定：B 点接受后，B 名下其他所有已授权设备会收到 encryptedChatDiscarded 更新——只有执行接受的那一台设备能进入该私密聊天【官】。
  • 换设备 / 重装 / 登出：本地密钥丢失，私密聊天永久不可恢复（无云端备份、无导出——官方导出工具明确排除私密聊天）。FAQ 原话：“If you log out, you will lose all your secret chats."【官】
  • 能否多设备迁移：不能。没有官方迁移通道；唯一"办法"是换设备后与对方重新建立新的私密聊天（会产生新的密钥与新的会话）【官】【社】。
  • 服务端残留：未送达的加密消息暂存于服务端的临时队列（qts），客户端确认送达即删；超过 7 天的消息服务器也会删除；账号取消授权则清空队列【官】。即服务端最多持有 7 天的密文，且永远没有密钥。

4. 隐私保护功能

4.1 自毁计时器（Self-Destruct Timer）

  • 粒度：Off / 1秒 / 5秒 / 1分钟 / 1小时 / 1天 / 1周，共 6 档（多家社区指南一致）【社】。
  • 计时起点：官方 FAQ 为"在对方阅读或打开后开始计时”；社区实测描述为消息出现"已读"（双勾）即开始倒计时，到期从双方设备同时消失【官】【社】。
  • 实现与服务端角色：计时器值（ttl_seconds）封装在 E2E 加密的 DecryptedMessage 内部，服务端在密文之外看不到计时器，删除动作完全由两端客户端本地执行【推：依据为官方文档的加密结构 + FAQ"从双方设备消失"的表述】。服务端能做的只是按 §3 转发密文并在送达/7 天后清队列【官】。因此自毁的可靠性取决于对方客户端是否诚实——修改版客户端可无视计时器。
  • 与云聊天自动删除的区别：后者（2021 年上线）按"发送时间"计时、档位为 24 小时/7 天/1 个月，是另一套服务端可见的机制【社】。

4.2 禁止转发

  • 官方 FAQ 确认：私密聊天消息不可转发【官】。
  • 实现为客户端侧强制：官方客户端不提供转发入口，E2E schema 中也没有转发原语。属行为约束而非密码学保证——对方仍可用修改版客户端或手动复制内容外发【社】。

4.3 截图通知

  • Android：私密聊天窗口设置 FLAG_SECURE，由系统合成器直接阻止截屏与录屏（尝试截屏得到黑图或失败），因此不需要"通知"环节【社：与开源 Android 客户端行为一致】。
  • iOS：监听系统截屏事件，检测到后通过 E2E 服务消息（decryptedMessageActionScreenshotMessages）通知对方，对方会看到"对方截了屏"的服务消息【社：与开源 iOS 客户端行为一致】。
  • 绕过手段（均【社】）：第三方修改版客户端可关闭检测或拦截通知；root/越狱设备；用另一台设备/相机直拍屏幕。官方 FAQ 亦承认"我们会尽力提醒，但仍可能被静默绕过"【官】。
  • 分歧记录：downloaderbaba.com 曾称"私密聊天截屏也不通知"，与多数来源及开源客户端代码行为矛盾，判定为该站错误。

4.4 消息删除（双向删除）

  • 官方 FAQ 确认：一方删除消息时，“对方的客户端会被命令同步删除”——通过 E2E 的 decryptedMessageActionDeleteMessages 服务消息实现【官】。
  • 删除整个私密聊天时，可选"仅删自己"或"双方都删"；一旦删除，无任何恢复途径【社】。

5. 功能限制（与云聊天对比）

能力云聊天私密聊天证据
群组 E2EN/A（本就非 E2E）不支持，仅一对一【官】
机器人支持不支持（机器人是服务端实体，无法持 E2E 密钥）；仅支持 inline bots 行内查询【官】+【社】
贴纸/GIF/链接预览/回复/媒体说明支持支持（Secret Chats 3.0，2017 年补齐）【官】（官方博客）
消息编辑支持无确凿支持证据（E2E schema 无编辑原语，客户端无编辑入口）【社】
消息置顶/投票支持不支持【社】
云草稿/多设备同步/服务端搜索支持不支持（无云端状态）【官】
文件上限2GB同为 2GB（一次性密钥机制）【社】
语音/视频通话支持私密聊天内无独立通话入口；但可与同一联系人发起独立的 E2E 通话（表情符号比对验真）【社】
桌面端/Web 端支持完全不支持【社】
自毁计时器仅私聊媒体全部消息，阅读后计时【官】

6. 安全评估

6.1 已知攻击面

  1. 初始密钥交换的 MITM：DH 交换无认证，活跃攻击者（包括 Telegram 服务器自身）可在双方跳过图形比对时实施中间人。这是设计上最大的信任假设：安全性最终落在"用户是否真的比对了密钥图形"上【学】【官】。
  2. re-keying 的 unknown key-share 弱点：Miculan–Vitacolonna 用 ProVerif 发现，恶意客户端 E（已分别与 A、B 建过私密聊天）可通过并行会话让 A 与 B 算出相同的新密钥，却各自误以为是与 E 共享。属理论弱点，需 E 已是双方的合法聊天对象，实际利用门槛高【学】。
  3. re-keying 缺隐式密钥确认/认证：同上论文指出，re-keying 不保证"A 确信 B 能算出新密钥"及"除 B 外无人知晓新密钥"【学】。
  4. 推送通知元数据：2024 年学术研究（arXiv:2407.10589）实测确认 Telegram 未通过 FCM 向 Google 泄露消息内容或任何个人信息，与 Signal 同属最干净的一档【学】。但通知仍经由 Apple/Google 的推送通道发出（通道级元数据如"某设备收到推送"不可避免），且设备本地通知栏本身是取证/旁观泄露面【推】。
  5. 桌面端密钥存储：官方 Telegram Desktop 根本不支持私密聊天，故不存在"桌面端私密聊天密钥存储"问题；macOS App Store 版的密钥存于本机应用沙盒。历史上有社区对各客户端本地存储强度的零散讨论，但未发现针对私密聊天密钥存储的已确认高危漏洞——此项标记为未能确认。
  6. 客户端行为可绕过：禁转发、截图通知、自毁计时器均为客户端侧执行，修改版客户端可全部无视；属"防君子不防小人"【社】【官】。

6.2 学术界对 MTProto 2.0 私密聊天的审计结论

  • Miculan & Vitacolonna（SECRYPT 2021；Computers & Security 2023）：在"密码学原语理想"的符号模型下，证明了 MTProto 2.0 的认证、普通聊天、E2E 聊天与 re-keying 在机密性/完整性/认证/前向保密上成立；同时发现 re-keying 的 UKS 弱点。总体评价：协议设计经得起形式化验证，但证明依赖"原语完美"的强假设【学】。
  • Albrecht 等（IEEE S&P 2022《Four Attacks and a Proof for Telegram》）：对 MTProto 2.0 对称密码部分给出安全证明（模型经微调），同时给出 4 个攻击：实用的消息重排序攻击、理论的 IND-CPA 攻击、三个官方客户端的计时侧信道攻击、针对服务端密钥交换实现的认证性破坏（可 MITM）。Telegram 已修复并回应。该文主攻云聊天的记录层，但其"密钥交换认证性可被破坏"的结论对私密聊天初始 DH 交换同样是警示【学】。
  • ETH 苏黎世《Analysis of Telegram Client Security》（Theo von Arx）：梳理官方客户端实现安全，确认除私密聊天外无 E2E，MTProto 2.0 可抵御线路上的攻击者【学】。

6.3 与 Signal 协议的关键差异（同等一对一场景）

维度Telegram 私密聊天Signal 协议
密钥协商静态 DH（2048 位模幂），一次性协商 + 周期性 re-keyX3DH 初始协商 + Double Ratchet 每条消息推进
前向保密粒度100 条消息 / 1 周一切换每条消息一换（棘轮），粒度细得多
崩溃后安全/密钥泄露恢复无（长期密钥泄露则后续可解，直到下次轮换）有（棘轮自愈，post-compromise security）
身份认证无签名，靠用户人工比对密钥图形安全码比对同样是可选人工环节，但协议内建长期身份密钥
否认性无有（deniability）
群组 E2E无有（Sender Keys）
多设备无（单设备绑定）有（每设备独立会话/Sender Key 分发）
离线消息需双方同时在线才能建聊；消息可经服务端队列中转（7 天）支持完整的离线/异步（预密钥包）
开源与审计客户端开源、服务端闭源；自研非标准协议全开源；协议经广泛学术审计

证据层级：协议事实部分【官】（Telegram 侧）+【社】（Signal 侧为公认的协议公开特性）；“优劣"判断为基于上述事实的分析性结论。

7. 近年变化（2024–2026）

  • 私密聊天协议本身：无官方公告的改动。近年的隐私功能更新（Premium 私聊"禁止分享”、云聊天自动删除档位扩展等）均针对云聊天，与私密聊天无关【官】【社】。
  • 2024-09 隐私政策调整（扩大向执法机关披露 IP/电话的范围）与透明度报告影响的是账号元数据，不改变私密聊天内容 E2E 不可读的性质，官方 FAQ 口径未变【社】。
  • 辟谣：某 2025 年中文"安全指南"博客声称"Premium 用户的私密聊天已支持多设备同步"——无任何官方公告佐证，且与官方 FAQ"设备专属、登出即丢失"直接矛盾，判定为不实信息【社】。
  • 辟谣：部分营销号称私密聊天用 “X25519 + AES-256-GCM”——与官方文档（DH-2048 + AES-256-IGE）矛盾，系误传【官】。

8. 来源

官方文档

  • Telegram FAQ（Secret Chats 章节）：https://telegram.org/faq —— E2E 定位、禁转发、双向删除、自毁、设备专属、发起路径【官】
  • End-to-End Encryption, Secret Chats（MTProto 2.0 技术文档）：https://core.telegram.org/api/end-to-end —— DH 细节、密钥可视化算法、PFS、消息/文件加密、设备绑定、服务端队列【官】
  • Perfect Forward Secrecy in Secret Chats：https://core.telegram.org/api/end-to-end/pfs —— re-keying 触发条件与流程【官】
  • Secret Chats 3.0（官方博客，2017）：https://telegram.org/blog/voice-2-secret-3 —— 回复/说明/贴纸/inline bots/GIF/链接预览补齐【官】

学术论文

  • Miculan, Vitacolonna《Automated Symbolic Verification of Telegram’s MTProto 2.0》：https://arxiv.org/pdf/2012.03141 —— 形式化验证通过 + re-keying UKS 弱点【学】
  • Albrecht, Mareková, Paterson, Stepanovs《Four Attacks and a Proof for Telegram》(IEEE S&P 2022)：https://mtpsym_github_io.proxy.wescribble.io/paper.pdf —— 记录层证明 + 4 攻击（含密钥交换 MITM）【学】
  • Cogliati, Ethan, Jha《Subverting Telegram’s End-to-End Encryption》(IACR ToSC)：https://tosc.iacr.org/index.php/ToSC/article/download/10302/9747/9181 —— E2E 消息编码形式化分析【学】
  • 《The Medium is the Message》(arXiv:2407.10589, 2024)：http://arxiv.org/pdf/2407.10589 —— Telegram 未向 FCM/Google 泄露个人信息【学】
  • ETH Zurich《Analysis of Telegram Client Security》(Theo von Arx)：https://ethz.ch/content/dam/ethz/special-interest/infk/inst-infsec/appliedcrypto/education/theses/report_TheoVonArx.pdf —— 客户端实现安全梳理【学】

社区与技术验证

  • Telethon-Secret-Chat 协议参考（对照官方文档 + TDLib 源码，2026-09 更新）：https://github.com/kiarosama/telethon-secret-chat/blob/HEAD/docs/protocol-reference.md【社】
  • tdesktop GitHub issues（#5、#844、#5861、#6992）：桌面版不支持私密聊天【社】
  • bugs.telegram.org/c/4003/4：WebZ 缺失功能含 Secret Chats【社】
  • tdem.in（Telegram 安全分析）：https://github.com/tdemin/tdem.in/blob/HEAD/content/post/telegram-and-secure-messaging.md —— 桌面版长期缺席、与 Signal/OTR 对比【社】
  • paprika.bot 私密聊天完整指南：https://paprika.bot/blog/telegram-secret-chat/ —— 发起/删除/截图/设备绑定实操【社】（其中"macOS 不支持"一说存疑，已按他源修正）
  • moneycontrol（2024-09，引述 FAQ 截图政策）：https://www.moneycontrol.com/technology/telegram-secret-chats-what-they-are-how-to-use-and-more-article-12811695.html【社】
  • socialagechecker（2026）：https://socialagechecker.net/blog/does-telegram-notify-when-you-screen-record-a-call/ —— Android 拦截 / iOS 通知 / 通话无检测【社】
  • tdesktop-encrypted（社区为桌面版补私密聊天的尝试）：https://github.com/telegram-encrypted/tdesktop-encrypted【社】
  • telegra.ph《How really secure and private is Telegram》(2026-05 更新)：Telegram 相关安全研究编年梳理【社】

未能确认 / 开放问题

  1. 私密聊天本地密钥在各移动端的存储加固细节（iOS Keychain / Android Keystore 的具体使用方式）——未找到权威披露。
  2. 私密聊天是否支持消息编辑——E2E schema 与客户端均无编辑入口的证据，倾向"不支持"，但缺官方明示。
  3. 自毁计时器在对方使用修改版客户端时的实际对抗效果——属客户端诚实假设，无法从外部验证。
  4. 桌面端官方未来是否会支持私密聊天——截至 2026-10 仍无官方路线图。