Telegram

调研日期：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 自己在内无人能解密”【官】。它与默认的云聊天是两套并行的产品形态，而非同一聊天的"加密模式"开关。 ...

调研日期：2026-10-06（UTC） 报告语言：中文，技术术语保留英文原文 信息可信度分级：✅ 官方确认（Telegram 官方文档 / 官方博客 / 官方 GitHub 仓库）｜ 📄 学界分析（同行评审论文、预印本）｜ 📊 媒体/二手（新闻、社区文档，需交叉验证）｜ 💬 社区推测（未证实，仅供参考） 1. 整体架构与设计哲学 1.1 中心化架构：有意为之的非联邦设计 Telegram 采用集中式客户端-服务器（client-server）架构，而非联邦式（federated，如 Matrix / XMPP / Email）或纯 P2P 架构。所有客户端通过自研的 MTProto 协议连接 Telegram 自营的数据中心（DC）集群；服务器端代码完全闭源，只有客户端开源。 这一选择的直接后果是：Telegram 可以提供无缝的多设备同步与云端存储——用户在新设备登录后可立即获得全部聊天记录，无需像 Signal 那样做设备间迁移。这是其产品哲学的核心：官方 FAQ 明确回答"为什么不把所有聊天都做成 secret（端到端加密）"——因为 E2E 范式下"在新设备上恢复聊天记录没有优雅的解决方案"，而可靠备份是大众市场通讯软件的必备功能。Telegram 选择了第三条路：Cloud Chats（服务端可读的加密云存储）+ Secret Chats（可选的 E2E），并认为这"是对大众流行应用而言目前最安全的方案"（✅ 官方：telegram.org/faq，2026-10-06 经 archive.org 摘录读取）。 代价同样明确：默认聊天的明文对 Telegram 服务器可见（传输层 MTProto 加密、存储时服务器持有解密能力），其隐私保证建立在"分布式跨国基础设施 + 密钥分片"之上，而非数学上的不可读。官方称：云聊天数据分散存储在全球多个数据中心，由不同法域的法律实体控制，解密密钥被切分且从不与所保护的数据存放在同一地点，因此需要多个法域的法院命令才能调取数据；并宣称"至今已向第三方（包括政府）披露了 0 字节用户消息"（✅ 官方：telegram.org/faq）。 1.2 多数据中心与账号分片 Telegram 在全球运营 5 个生产数据中心（DC1–DC5），客户端通过 help.getNearestDc 等机制获知 DC 拓扑（✅ 官方 TL schema 有 DC 相关方法；具体位置为 💬 社区测定）： ...