同样是聊天软件，Telegram 的私密聊天能让服务器「连你发的什么都不知道」，而微信的每一条消息，服务器都「读得一清二楚」。
这个差距不是「技术高低」决定的，而是由架构决定的——一端把密钥放在了你的手机里，另一端把密钥放在了服务器上。
引言：一个被「丝滑」掩盖的真相
对比 Telegram 与微信，人们常从三个角度切入：性能体验、加密设计、用户协议。表面看这是三件不相干的事，但把它们拼在一起，会得到一个统一的结论：
Telegram 与微信的本质区别，不在 UI 动画谁更顺滑，而在「密钥到底握在谁手里」。
性能、加密、用户协议，其实是同一个架构选择在不同层面的投影：
| 对比维度 | 现象 | 背后的架构原因 |
|---|---|---|
| 性能体验 | Telegram 秒开丝滑，微信臃肿笨重 | Telegram 轻量客户端 + 全球 DC 就近接入；微信是「超级 App」基座堆叠 |
| 加密设计 | Telegram 有真正的端到端加密 | Secret Chats 把密钥放在两端设备，服务器只转发密文 |
| 用户协议 | 双方隐私条款差距悬殊 | 架构差异的法律化表达——服务器读得到，才能「承诺」或「不承诺」 |
为什么这件事值得掰开揉碎地讲？因为大多数人以为自己选了「安全的聊天软件」，其实只是选了「更好看的聊天软件」。很多人每天用着某款聊天工具，却从未意识到：你的聊天记录，可能只是「存在别人服务器上的一堆明文」，区别只在于「被读的概率」和「被读的权限」。
本文要做的，就是把 Telegram 的软件架构和端到端加密拆到底：它到底怎么做到「服务器也读不了你的消息」，以及——为什么这一点，微信做不到、或者说，选择不这么做。
在进入正题前，先给一个全文的「地图」，方便你带着框架往下读：
| 章节 | 要回答的问题 |
|---|---|
| 一、软件架构 | Telegram 凭什么快？它的骨架长什么样？ |
| 二、MTProto 2.0 | 客户端与服务器之间的「管道」怎么加密？ |
| 三、端到端加密 | 为什么服务器读不了 Secret Chats？ |
| 四、对比微信 | 微信为什么「做不到」或「不做」？ |
| 五、元数据 | E2EE 保护了什么，又没保护什么？ |
| 六、常见误区 | 关于 Telegram「安全」的十个误区 |
| 七、实操安全清单 | 真要用，该怎么安全地用它 |
| 八、安全启示 | 拆到底之后，我们该冷静地看到什么 |
一、Telegram 的软件架构：轻，是有原因的
1. 客户端-服务器模型，不是 P2P
很多人以为「安全的聊天」应该像 P2P 一样点对点直连——两台手机直接通信，不经任何中间人，这样才够隐私。但 Telegram 恰恰相反——所有消息都经过服务器中转：
1 | 你的手机 ──密文──▶ Telegram 服务器 ──密文──▶ 对方手机 |
为什么不用 P2P？因为 P2P 有几个致命伤：
- 离线消息：对方关机，消息往哪发？P2P 需要有一方在线。
- 多设备同步：你的手机、平板、电脑都要收到同一份消息，P2P 很难做到「一份消息多处落地」。
- 网络穿透：双方都在 NAT 后面（家里/公司局域网），直连穿透成功率很低，往往还是要靠服务器打洞。
于是 Telegram 选择了「服务器中转」这个看起来更「不隐私」、实则更实用的模型。这也带来一个重要事实：「服务器中转」和「服务器能读」是两回事——前者是数据必经之路，后者取决于密钥在哪，这正是本文后半部分的核心。
2. 全球数据中心（DC）：丝滑的物理基础
Telegram 在全球部署了多个数据中心（DC，Data Center），用户就近接入，账号归属某个「主 DC」。海量消息并发下仍能「秒开」，靠的不是黑魔法，而是三件套：
- 客户端原生 UI 渲染：不靠 WebView 套壳。原生渲染的启动速度和滚动流畅度，是 Web 套壳难以企及的。
- 协议紧凑：TL 二进制序列化，而非 JSON/XML 明文膨胀。同样的数据，二进制比文本小好几倍，传输和解析都快。
- DC 分布式就近路由：你在中国，就接入最近的 DC；你在欧洲，就接入欧洲的 DC。物理距离短，延迟自然低。
而微信这类「超级 App」，内嵌小程序、支付、公众号、视频号、朋友圈、直播等庞杂基座，内存占用和启动成本自然水涨船高。这是「专一」与「全能」的架构代价差异，无关技术高低。 一个只做聊天的 App，和一个把支付、电商、社交、内容全塞进去的 App，天然不在同一复杂度水平。
这里有个值得玩味的点：「快」不是一种魔法，而是一种取舍。 Telegram 选择「专一做聊天」，于是它轻；微信选择「什么都做」，于是它重。两者没有对错，只是你在下载一个 App 时，其实是在替它的架构取舍投票。
3. MTProto 协议 + TL 序列化
Telegram 自研了一套二进制加密传输协议 MTProto 2.0，配合 TL（Type Language） 描述所有对象的序列化格式。它紧凑、跨语言，是 Telegram 传输层的基石。
这里有两个关键设计：
- TL 序列化：一种描述「对象长什么样、按什么字节序排」的语言。它让客户端（Android/iOS/桌面/Web）和服务器用同一种「语言」说话，且序列化结果紧凑，几乎零冗余。
- 分层设计：MTProto 不是一层，而是多层叠加——最外层处理「如何把字节流安全地在网络上传输」，内层处理「消息本身的加解密」，再往里才是「业务数据」。这种分层让协议既能应对不稳定的移动网络，又能保持安全性。
一句话理解：TLS 是「通用安全传输」，MTProto 是「为即时通讯量身定制的专用安全传输」。 微信用 TLS + 自定义私有协议，Telegram 用 MTProto——两者都要保传输安全，区别在于 MTProto 更针对「移动端弱网 + 高频小消息」的场景做了优化。
二、MTProto 2.0：传输层怎么加密
MTProto 解决的是「客户端与服务器之间」的通信安全。它的关键机制，浓缩起来是一套「握手 + 派生」的流水线：
| 步骤 | 机制 | 作用 |
|---|---|---|
| 1. 生成 auth_key | DH-2048（MODP Group）密钥交换 | 客户端与服务器协商长期共享密钥 |
| 2. 派生 msg_key | 对明文（含 salt、会话号、消息体）做 SHA-256，取中间 128 位 | 派生本次消息的 AES 密钥与 IV |
| 3. 加密 | AES-256-IGE（Infinite Garble Extension）模式 | 加密任意长度数据 |
| 4. 完整性 | SHA-256 校验 | 防篡改 |
| 5. 防重放 | server salt + 递增 msg_id | 防重放与降级攻击 |
| 6. 会话 | auth_key 之上建立多个会话，密钥轮换 | 隔离与会话管理 |
1. auth_key：长期共享密钥
客户端第一次连接服务器时，通过 Diffie-Hellman（DH-2048） 密钥交换，在公开信道中协商出一个只有「客户端和服务器」知道的长期共享密钥 auth_key。这个密钥一旦建立，就可以在之后的所有通信中反复使用，避免每次连接都重新协商。
2. msg_key + 派生
为了不「一钥多用」，MTProto 对每一条消息都要派生出独立的加密密钥。它对明文（包含盐 salt、会话号、消息体）做 SHA-256，取中间 128 位作为 msg_key，再由 auth_key 与 msg_key 共同派生出一个 256 位的 aes_key 和对应的 IV。
关键点：同一把 auth_key，配合不同的 msg_key，就能派生出不同的消息密钥。 这样即使某条消息的密钥被破解，也不会牵连到整个会话——这是「每个消息独立密钥」的工程价值。
3. AES-256-IGE
MTProto 使用 IGE（Infinite Garble Extension） 模式，而不是更常见的 GCM。为什么？因为 IGE 能对任意长度数据做「整体加密」而无需填充，适合消息流场景。IGE 的一个特性是：即使只篡改一个比特，解密后也会影响整个块链，所以天然有很强的「错误扩散」——改动会被放大，容易被察觉。
注意：我们下一篇的 Go 实战会用更简单、也更主流的 AES-GCM 来演示端到端加密思路，因为「演示原理」和「生产协议」是两码事。GCM 自带认证标签，API 更友好，适合讲清原理；MTProto 的 IGE 则是为了消息流场景的特殊工程选择。
4. 防重放与防降级
MTProto 有完整的防重放体系：
- server salt：服务器每次下发一个随机盐值，参与消息密钥派生。同一请求在「盐值不同」的情况下重放是无效的。
- 递增 msg_id：每条消息带一个单调递增的 ID，服务器可以拒绝「重复或乱序」的消息。
- 防降级攻击：协议握手时会协商版本，防止攻击者把客户端「降级」到不安全的旧协议。
5. MTProto 1.0 → 2.0 改了什么
MTProto 2.0 是在原版基础上的重要升级，核心改进包括：
| 改进点 | 说明 |
|---|---|
| 哈希覆盖 | SHA-256 覆盖整个明文消息（含尾部填充），完整性校验更强 |
| 随机填充 | 每条消息末尾带随机字节，防止固定长度暴露消息结构 |
| 移除不安全旧路径 | 弃用了一些被证明有问题的早期设计 |
| 消息认证 | 加强了对消息来源的认证，防止伪造 |
但必须诚实：MTProto 是「闭源自研 + 部分公开」的协议。 相比经过多年开放审计的 TLS 或 Signal 的 Signal Protocol，MTProto 受到的第三方安全审计更少，这也是安全社区对它始终有争议的原因之一。好的一面是它足够创新，坏的一面是「自研密码学协议」本身就是一个高风险标签。
三、端到端加密（Secret Chats）：服务器也读不了
这是整个对比里最核心、也最容易被误解的部分。
1. 关键区分：云聊天 vs 私密聊天
Telegram 有两类聊天，加密强度天差地别：
| 类型 | 加密 | 服务器能读？ | 多设备同步 | 特性 |
|---|---|---|---|---|
| 云聊天（Cloud Chats） | 仅传输层加密 | 能读明文 | 支持 | 群聊、频道、机器人 |
| 私密聊天（Secret Chats） | 端到端加密（E2EE） | 不能读 | 仅两端设备 | 阅后即焚、密钥指纹 |
这是一句必须点破的真相：Telegram 的「安全」主要体现在 Secret Chats，而你日常用的普通云聊天，服务器是能读的。很多人以为「用 Telegram = 加密 = 安全」，这是个危险的误解。
- 云聊天：默认模式，加密只在「你的手机 → 服务器」这一跳，服务器拿到的是明文。它能搜、能同步、能跨设备——代价是服务器能读。
- 私密聊天（Secret Chats）：手动开启，端到端加密，服务器只转发密文，自己永远解不开。
2. E2EE 的核心：密钥只在两端
端到端加密（E2EE）的「端到端」，指的是密钥只在通信的两端设备上生成和保存，任何中间方（包括服务器）都拿不到。
1 | DH 密钥交换（两端本地完成） |
服务器在整个过程中只转发公钥和密文，它手里只有「公钥 A、公钥 B、一串密文」，唯独没有「私钥」，因此永远算不出共享密钥 s，也就解不开任何一条消息。
数学上这靠的是离散对数难题：已知 g、p、A、B，在 2048 位的大素数域下，反推私钥在计算上是不可行的。DH 的妙处在于：双方在公开信道上交换公钥，却能各自算出同一个共享密钥，而偷听者永远算不出。
这回答了一个尖锐的问题：「如果执法部门或攻击者逼 Telegram 交出聊天记录，会怎样？」 答案取决于聊天的类型——云聊天，它能交出来；Secret Chats，它交出来的只有一堆它自己也解不开的密文。
3. 认证加密：为什么光加密不够
很多人以为「加密了就够了」。但只加密不认证，等于只锁门不装门禁。攻击者虽然打不开门，却可以「偷换」门里的内容——这就是篡改攻击。
Telegram 的 E2EE 采用认证加密：密文里带一个认证标签，任何篡改（哪怕改动一个比特）都会导致解密失败并被立即发现。这与微信的「撤回」有本质区别：
- 撤回：把消息「假装删掉」，但服务器上仍有原始记录，攻击者/执法者仍能翻出明文。
- 认证加密：消息内容被改动，接收方立刻报错，无法被无声替换。
4. 密钥指纹：肉眼防中间人
E2EE 最大的天敌是中间人攻击（MITM）：攻击者在你和对方之间，各自冒充对方完成 DH 交换，于是你和「假对方」、攻击者和「真对方」各持有一把密钥，明文在攻击者那里裸奔。
Telegram 的解法是密钥指纹（key fingerprint）：
- 两端各自计算公钥的指纹（一段可视化图形 / 数字串 / 二维码）
- 用户通过另一条可信通道（打电话、见面）肉眼比对
- 指纹一致 → 无中间人；不一致 → 已被窃听
Telegram 的指纹做成了图形化 + 二维码两种形式：
| 形式 | 优点 | 适用场景 |
|---|---|---|
| 图形指纹（emoji 组合） | 人类易记、易比对 | 面对面时快速核对 |
| 数字串指纹（十六进制） | 精确、可复制 | 电话/文字通道核对 |
| 二维码 | 扫描即比对 | 两台手机靠近时 |
这个设计被 Signal、WhatsApp 等后续产品广泛借鉴，成为 E2EE 的标配。下一篇实战，我们会在 Go 里亲手实现它——两端算出同一串 AA:BB:CC:... 指纹，肉眼比对一致即无中间人。
5. 阅后即焚与设备绑定
- 阅后即焚：消息定时销毁，销毁指令端到端同步，两端同时删除，服务器端只留密文（且大概率也已删除）。
- 设备绑定：私密聊天绑定在发起设备上，不跨设备同步——因为密钥只存在于那台设备。这是 E2EE 与云聊天在「多设备」上最大的差别：要安全，就放弃多设备同步，这是鱼与熊掌。
6. 登录与验证：安全链的第一环
端到端加密再强，也防不住「账号被登录」。Telegram 的登录验证有几个层次：
| 机制 | 作用 | 弱点 |
|---|---|---|
| 手机号 + 短信验证码 | 基础身份认证 | 短信可被拦截、SIM 卡可被劫持 |
| 已登录设备转发验证码 | 老设备代收验证码 | 依赖老设备安全 |
| 两步验证（2FA 密码） | 额外一层密码 | 防 SIM 劫持，但密码要足够强 |
| 设备管理 | 查看/踢出登录设备 | 需要用户主动检查 |
实操中还有一个常被忽视的风险：输入法。如果你用了第三方输入法（尤其是有云同步/联网功能的），你输入验证码、密码时的按键内容可能被上传到输入法厂商的服务器——即使 Telegram 再安全，你的密码也可能在输入法这一环泄了。同理，剪贴板里的明文残留，也可能被恶意 App 读取。
结论：安全的木桶，短板往往不在协议，而在「人」的环节——验证码、输入法、剪贴板、密码强度、设备管理，任何一个环节漏了，前面费尽心思的加密都白搭。
四、为什么微信「做不到」？——架构决定协议
微信没有默认的端到端加密，这不是「腾讯技术不行」，而是架构选择：
- 微信是「服务端可读」架构：聊天记录存储在腾讯服务器，配合实名、监管、支付、反诈等需求，服务器必须能读明文。
- 微信不提供私密聊天：它用「撤回」替代「阅后即焚」，但撤回不等于销毁——服务器上仍有记录。
- 用户协议的「坑」由此而来：当服务器天然能读你的聊天，用户协议里关于「数据使用权限」的条款，就不可能写得像 Telegram 私密聊天那样「我们读不了」。这份「反差」的根源就在这里。
更深一层想：不是微信「做不到」E2EE，而是它的商业模式要求「服务器能读」。 微信要推送广告、要做风控反诈、要配合监管审计、要做支付安全——这些全都建立在「服务器能读到明文」之上。端到端加密会直接砍掉这些能力，所以对微信而言，E2EE 不是「技术问题」，而是「商业和合规问题」。
Telegram vs 微信 全景对比
| 维度 | Telegram | 微信 |
|---|---|---|
| 默认加密 | 云聊天仅传输层加密；私密聊天 E2EE | 传输层加密，无默认 E2EE |
| E2EE 能力 | Secret Chats 端到端加密 | 普通聊天不提供 |
| 服务器可读性 | 云聊天可读 / 私密聊天不可读 | 可读（配合监管合规） |
| 密钥指纹防 MITM | 支持 | 无 |
| 阅后即焚 | 支持 | 无（仅撤回） |
| 多设备同步 | 云聊天支持，私密聊天单设备 | 支持 |
| 客户端体量 | 轻量、原生渲染 | 超级 App，功能臃肿 |
| 用户协议口径 | 私密聊天承诺不读 | 数据权限界定宽泛 |
| 元数据收集 | 相对较少 | 深度收集（社交图谱、使用行为） |
| 开源 | 客户端/协议部分开源（TDLib 等） | 闭源 |
| 注册方式 | 手机号（私聊可隐藏） | 手机号（强绑定实名/支付） |
参照系：Signal 与 WhatsApp
把视野拉宽一点，E2EE 的「天花板」是 Signal：
| 维度 | Telegram | Signal | 微信 | |
|---|---|---|---|---|
| 默认 E2EE | 否（需手动开私密聊天） | 是（默认） | 是（默认） | 否 |
| 协议 | MTProto（部分自研） | Signal Protocol（开源审计多） | Signal Protocol | 私有 |
| 元数据收集 | 相对少 | 极简（只存手机号/联系人） | 相对多（Meta 生态） | 深度 |
| 开源 | 部分 | 全开源 | 客户端开源 | 闭源 |
这个参照系告诉我们：「E2EE」不是非黑即白。Telegram 把 E2EE 做成「可选项」，Signal 把 E2EE 做成「默认值」，WhatsApp 默认 E2EE 但元数据收集多，微信则是「服务端可读」。四者真正的差距，不是「有没有加密」这种非黑即白，而是「安全默认值」和「元数据态度」的灰度。
五、元数据（Metadata）：E2EE 保护不了的那一半
这是几乎所有讲 E2EE 的文章都会漏掉，却至关重要的一点：
端到端加密保护的是「消息内容」，不保护「消息的元数据」——谁在什么时候、跟谁、聊了多久、从哪台设备。
元数据包括但不限于：
- 你和谁建立了联系（联系人关系）
- 你什么时候在线、什么时候发消息
- 你从哪个 IP / 哪台设备登录
- 你消息的大小、频率（即使内容是密文，流量模式也能暴露大量信息）
- 你加入了哪些群、关注了哪些频道
元数据为什么危险？ 因为即使密文不可读，元数据已经能拼出一个人的「行为画像」——你几点睡、几点醒、和谁最亲密、工作节奏如何。情报界有句话：「元数据杀得死人。」（Metadata kills people.）美国 NSA 前局长就说过：我们杀人的时候，靠的是元数据。
| 关注点 | 内容 | 元数据能泄露什么 |
|---|---|---|
| 内容 | 你说了什么 | 被 E2EE 保护 |
| 元数据 | 你和谁、何时、多久、多频繁 | 不被保护 |
| 身份 | 你的手机号、IP、设备 | 登录环节可被获取 |
所以，一个诚实的结论是：Telegram 的 E2EE 保护了「说什么」，但没有保护「你存在、你在跟谁聊、你的行为模式」。 这一点，在评估「Telegram 是否安全」时，必须同时纳入。
六、常见误区：关于 Telegram「安全」的十个误区
这一段专门用来辟谣——市面上关于 Telegram 的「安全神话」和「安全恐慌」，多半是误解：
| 误区 | 真相 |
|---|---|
| 误区一：用 Telegram 就代表全部加密 | 只有手动开的私密聊天（Secret Chats）才端到端加密，云聊天服务器可读 |
| 误区二：Telegram 比 Signal 更安全 | Signal 默认 E2EE、协议开源审计多；Telegram 是「可选的 E2EE」 |
| 误区三：加密了就可以随意发 | 元数据仍会泄露你的行为画像 |
| 误区四：阅后即焚 = 彻底删除 | 内容销毁不等于元数据销毁，且双方屏幕截图无法阻止 |
| 误区五：私密聊天能多设备同步 | 私密聊天绑定单设备，这是 E2EE 的特性而非缺陷 |
| 误区六：MITM 不可能发生 | 只要不做密钥指纹比对，中间人依然可能得逞 |
| 误区七：MTProto 闭源 = 一定不安全 | 闭源不必然不安全，但审计更少，风险更高，需谨慎评估 |
| 误区八：验证码一定能防住入侵 | SIM 卡劫持、输入法泄露、剪贴板残留都是突破口 |
| 误区九：删了聊天记录就安全 | 服务器端、对方端、云备份可能仍留有数据 |
| 误区十：开源 = 绝对安全 | 开源只是「可审计」，不等于「已被充分审计」或「部署正确」 |
一句话总结误区：「安全」不是一个开关，而是一连串默认值、审计记录和用户习惯的总和。 任何单一特性（哪怕 E2EE）都不能单独定义「安全」。
七、实操安全清单：真要用，该怎么安全地用它
如果你决定使用 Telegram，并且希望尽量安全，这里是一份可执行的清单：
| 操作 | 说明 |
|---|---|
| 1. 开启两步验证（2FA） | 设置一个强密码，防 SIM 卡劫持后直接登号 |
| 2. 敏感聊天用私密聊天 | 需要隐私时，手动开启 Secret Chats，不要用云聊天 |
| 3. 核对密钥指纹 | 首次建立私密聊天时，通过另一条可信通道比对指纹/二维码 |
| 4. 设置阅后即焚 | 对敏感内容设置较短的销毁时间 |
| 5. 定期检查登录设备 | 在设置里查看并踢掉陌生设备 |
| 6. 警惕第三方输入法 | 敏感信息尽量用系统自带输入法，避免云同步输入法读取 |
| 7. 注意剪贴板残留 | 复制敏感内容后及时清除剪贴板 |
| 8. 不点不明链接 | 防止钓鱼与恶意文件，即便在加密软件里也一样 |
| 9. 理解元数据边界 | 意识到 E2EE 保护内容，不保护「你和谁、何时」 |
| 10. 群聊/频道默认不加密 | 群聊、频道、机器人走的是云聊天，服务器可读 |
安全不是「装了个安全软件」就自动到账的，而是「默认值 + 习惯 + 认知」三者的乘积。工具只给你「可能性」，安全取决于你怎么用。
八、安全启示：E2EE 是一把双刃剑
拆解到最后，我们应该冷静地看待 Telegram 的「安全」：
它给我们的几个启示：
「安全」是可选配置，不是默认配置。Telegram 的云聊天同样是服务端可读的——真正的 E2EE 只存在于你主动开启的 Secret Chats 里。默认状态下的「安全」，往往是幻觉。
端到端加密的本质，是「把信任从服务器转移到两端」。它不保证「没人能偷看」，只保证「服务器和中间人偷看不了」——前提是你要亲手核对密钥指纹。
架构决定一切。性能、加密、用户协议，都是「密钥握在谁手里」这一个根本选择的投影。理解了这一点，你就能看穿任何一款聊天软件在隐私宣传上的话术。
E2EE 是一把双刃剑。它保护了普通人的隐私，也保护了罪犯的勾当。各国执法部门长期施压科技公司开后门，就是这场博弈的缩影。我们不能天真地认为「加密即正义」，但也要清醒地知道：真正的隐私保护，从来都建立在「密钥在你手里」之上。
最后一句：
所谓「安全的聊天软件」，安全的从来不是软件本身，而是密钥的归属。
把密钥放在手机里，服务器就成了「看不懂的邮差」；把密钥放在服务器上，手机就成了「会说话的监控」。
你选择用哪一款，本质上是在选择——让谁，成为你秘密的守门人。
下一篇预告
本文把 Telegram 的架构与 E2EE 原理拆到了位。下一篇《Go 实现仿 Telegram 端到端加密：从 DH 密钥交换到 AES-GCM》里，我们用 Go 的标准库，亲手把这套「服务器读不懂的邮差」模型敲出来——DH-2048 交换密钥、SHA-256 派生密钥、AES-GCM 加密、密钥指纹比对，一步步验证「为什么服务器永远解不开你的消息」。
参考
- Telegram MTProto 2.0 官方文档：https://core.telegram.org/mtproto
- Telegram Secret Chats（端到端加密）：https://core.telegram.org/api/end-to-end
- RFC 3526 — MODP Groups for IKE（2048-bit Group 14）
- Signal 官网关于端到端加密的说明：https://signal.org
- 《深入理解 Telegram 通信核心：MTProto 协议加密》系列技术解读
相关文章
本文是「端到端加密与安全通信」系列的一员：
- 《Go 实现仿 Telegram 端到端加密：从 DH 密钥交换到 AES-GCM》 —— 端到端加密的代码级实现
- 《手机密码、加密通讯与取证对抗》 —— 移动设备加密与取证对抗
- 《bitchat：连服务器都没有，拿什么监管你？——去中心化、免疫审查的蓝牙 Mesh 即时聊天软件》 —— 无服务器的去中心化通讯
- 《在国内搭一台隐私副机：GrapheneOS + 随身 WiFi + 国内 WireGuard 加密通道》 —— 隐私通讯的设备落地
评论