今日开源[第26期]SimpleX Chat
SimpleX Chat 项目分析报告
分析日期:2026-07-05
一、项目介绍
1.1 项目概述
SimpleX Chat 自称是世界上第一个完全没有任何用户标识符的即时通讯平台——100% 隐私设计 [1]。它不使用手机号、用户名、邮箱地址、公钥或任何随机数字来标识用户,而是通过单向消息队列(Simplex Messaging Queues) 的地址来传递消息。这相当于为每个联系人使用不同的"邮箱地址",从根本上杜绝了用户身份被关联和追踪的可能性。
SimpleX Chat 由 Evgeny Poberezkin 创建,底层基于 SimpleX 协议,采用 Haskell 实现核心逻辑,提供 iOS、Android、Linux、macOS、Windows 全平台客户端 [2]。
1.2 项目信息
| 项目 | 详情 |
|---|---|
| 项目名称 | SimpleX Chat |
| 项目地址 | https://github.com/simplex-chat/simplex-chat |
| 项目官网 | https://simplex.chat |
| 作者 | Evgeny Poberezkin (epoberezkin) |
| 组织 | simplex-chat (GitHub Organization) |
| Stars | 8,600+(截至 2026 年 7 月) |
| 当前版本 | v6.5.6(稳定版);v7.0.0-beta.2 开发中 |
| 开源协议 | GNU AGPL v3.0 |
| 主要语言 | Haskell(核心协议层)、Kotlin(Android)、Swift(iOS)、TypeScript/Dart(桌面端) |
| 首次发布 | 约 2022 年初 |
| 仓库创建 | 2019 年 12 月 21 日 |
| 总提交数 | 6,183+ commits |
1.3 项目示意图
SimpleX Chat 拥有现代化的全平台 UI:
- 暗色/亮色主题切换支持
- 聊天界面:支持文本、图片、文件、语音消息、视频通话
- 群组管理:支持群聊、频道功能
- 高级功能:消息反应(Reactions)、已读回执、阅后即焚
- 安全验证:量子加密标识、连接安全验证界面(非可选 MITM 防护)
二、项目亮点
2.1 无用户标识符——最核心差异化优势
SimpleX 不使用任何用户标识符(手机号、用户名、邮箱、公钥、随机 ID)。每个联系人使用独立的单向消息队列集合,服务器无法关联不同队列属于同一用户。这从根本上消除了 Signal、TG、WhatsApp 等平台无法解决的元数据隐私问题 [3]。
2.2 双层端到端加密
| 加密层 | 算法 | 说明 |
|---|---|---|
| 第一层(双棘轮) | X3DH 密钥协商 + ephemeral Curve448 密钥 | 基于 Signal 双棘轮,提供前向保密和 break-in recovery |
| 第二层(队列加密) | NaCl crypto_box(Curve25519 + Salsa20 + Poly1305) | 每条 SMP 队列消息额外加密 |
| 传输加密 | TLS 1.3 | 网络传输层保护 |
| 服务器认证 | Ed448 签名密钥 | 自动生成,用于授权 SMP 命令 |
2.3 元数据隐私保护——全方位防流量分析
| 机制 | 说明 |
|---|---|
| 消息固定 16KB 填充 | 所有消息填充到固定大小,防止消息大小分析攻击 |
| 无共同标识符 | 入站和出站消息之间没有共同的标识符或加密明文,流量难以关联 |
| 2-hop 洋葱路由 | 发送者 IP 仅对第一跳可见,接收者 IP 仅对第二跳可见,隐藏双方传输身份 |
2.4 非可选 MITM 防护——强制两因素密钥交换
密钥指纹嵌入在连接邀请链接中,中间人攻击防护成为非可选(non-optional)的强制步骤。与 Signal 等平台的可选安全码验证有本质区别——用户无法跳过安全验证 [3]。
2.5 量子抗性双棘轮算法
从 v5.6 开始,可选启用量子抗性双棘轮算法,使用 Streamlined NTRU Prime (sntrup761) 算法集成到双棘轮内部。采用双 KEM 并行设计(lock-step),不仅保护初始密钥交换,还保护 break-in recovery 特性 [4]。
2.6 去中心化网络架构
- 用户可使用自己的服务器或预设服务器
- 服务器之间不互联、不相互感知
- 不存在全网单一命名空间,无法进行网络级攻击
- 用户可随时切换服务器而不丢失联系人和消息
2.7 与同类项目对比
| 特性 | SimpleX Chat | Signal | TG | Matrix | |
|---|---|---|---|---|---|
| 需要用户标识符 | 否 | 是(手机号) | 是(用户名) | 是(手机号) | 是(DNS地址) |
| MITM 防护 | 非可选(强制) | 可选 | 可选 | 可选 | 可选 |
| 依赖 DNS | 否 | 否 | 是 | 否 | 是 |
| 单一运营商/网络 | 否 | 是 | 是 | 是 | 否 |
| 全网攻击面 | 无 | 有 | 有 | 有 | 有 |
| 消息固定大小填充 | 是(16KB) | 160 字节 | 否 | 否 | 否 |
| 量子抗性 | 是(Beta) | 仅初始密钥 | 否 | 否 | 否 |
| 可否认性 | 全栈 | 客户端-客户端 | 否 | 否 | 部分 |
| 开源 | 是(AGPLv3) | 是(GPLv3) | 客户端开源 | 否 | 是(Apache) |
与 P2P 协议的关键区别:
- P2P 网络存在全局命名空间,存在全网 Sybil 攻击风险;SimpleX 无全局命名空间
- P2P 消息需经过 O(log N) 节点顺序传递,延迟更高;SimpleX 通过并行传递提供更低延迟
- P2P 网络可能被 ISP 封锁;SimpleX 是传输层无关的,可运行在标准 Web 协议之上
三、项目运行环境
3.1 硬件要求
| 平台 | 要求 |
|---|---|
| 移动端 | Android 8.0+ 或 iOS 15.0+ 的智能手机 |
| 桌面端 | 标准 PC/Mac,支持 Linux、macOS、Windows |
| 服务器端 | 标准云服务器即可运行 SMP 转发服务器(推荐内存中运行,无需大量存储) |
3.2 操作系统与分发方式
| 平台 | 客户端 | 分发方式 |
|---|---|---|
| Android | 移动 App | Google Play / APK 直装 / F-Droid |
| iOS | 移动 App | App Store / TestFlight |
| Linux | 终端 CLI + 桌面 GUI | APT (.deb) / AppImage / 编译安装 |
| macOS | 终端 CLI + 桌面 GUI | DMG / Homebrew 编译 |
| Windows | 终端 CLI + 桌面 GUI | MSI 安装包 / 可执行文件 |
3.3 软件依赖
构建依赖(从源码编译):
- Haskell GHC 9.6.3 + Cabal 3.10.1.0(核心协议和 CLI)
- Android SDK(Android App)
- Xcode(iOS App)
系统依赖(Linux): build-essential、libgmp3-dev、zlib1g-dev
系统依赖(macOS): openssl@3.0 (via Homebrew)
3.4 安装步骤
Linux/macOS 快速安装(推荐):
curl -o- https://raw.githubusercontent.com/simplex-chat/simplex-chat/stable/install.sh | bash
从源码编译:
git clone git@github.com:simplex-chat/simplex-chat.git
cd simplex-chat
git checkout stable
# 安装 Haskell 工具链后
cabal update
cabal install simplex-chat
Docker 构建:
DOCKER_BUILDKIT=1 docker build --output ~/.local/bin .
移动端: 从 Google Play Store 或 Apple App Store 直接安装。
四、项目代码介绍
4.1 代码架构图
simplex-chat/
├── .github/ # CI/CD 配置
├── apps/ # 移动端应用
│ ├── android/ # Kotlin / Jetpack Compose
│ └── ios/ # Swift / SwiftUI
├── assets/ # 静态资源
├── blog/ # 官方博客文章
├── bots/ # 聊天机器人支持
├── docs/ # 文档(RFCs、指南、翻译)
│ ├── rfcs/ # 协议设计 RFC
│ ├── guide/ # 用户指南
│ └── lang/ # 多语言文档
├── packages/ # 桌面应用
│ └── simplex-chat/ # 桌面 App(Dart/Flutter 或原生)
├── scripts/ # 构建和部署脚本
├── src/ # 核心源代码(Haskell)
│ └── Simplex/
│ ├── Chat/ # 聊天应用逻辑
│ │ ├── Options.hs # 预配置 SMP 服务器
│ │ ├── Protocol.hs # 聊天协议实现
│ │ └── ...
│ ├── Messaging/ # 消息协议层
│ └── ...
├── tests/ # 测试代码
├── website/ # 官方网站源码
├── simplex-chat.cabal # Haskell 项目配置
├── cabal.project # Cabal 构建配置
├── Dockerfile # Docker 构建
├── install.sh # 安装脚本
└── CHANGELOG.md # 更新日志
独立子模块仓库 simplexmq 包含底层协议实现、SMP 服务器和协议白皮书。
4.2 架构层次
用户设备 互联网 第三方服务器
------------------ | ---------------------- | -------------------------
SimpleX Chat | |
+----------------+ | |
| Chat App | | |
+----------------+ | |
| SimpleX Agent | | |
+----------------+ | ------- TLS ---------- +----------------+
| SimpleX Client | | --- SMP 消息协议 ----> | SimpleX Router |
+----------------+ | ---------------------- +----------------+
4.3 核心模块介绍
| 模块 | 功能 | 语言 |
|---|---|---|
| SMP Server | 消息队列转发服务器,接收、缓冲、转发消息 | Haskell |
| SMP Client | 客户端库,与 SMP 服务器通信 | Haskell |
| SMP Agent | 高级 API 层,管理连接、队列、E2EE | Haskell |
| Chat Core | 聊天应用核心逻辑 | Haskell |
| Android App | 移动端 Android 应用 | Kotlin |
| iOS App | 移动端 iOS 应用 | Swift |
| Desktop App | 桌面 GUI 应用 | 多语言 |
| CLI | 终端命令行应用 | Haskell |
4.4 核心代码解析
4.4.1 SMP 服务器预配置(Options.hs)
-- src/Simplex/Chat/Options.hs
-- 客户端预配置了默认 SMP 服务器地址及其离线证书指纹
-- 用于 TLS 握手时的服务器验证
defaultSMP servers = [
"smp://LcJUMfVhwD8yxjAiSaDzzGF3-kLG4Uh0Fl_ZIjrRwjI=@smp.example.com",
-- 服务器地址格式:smp://<base64编码的证书指纹>@<服务器域名>
-- 证书指纹在连接建立前已知,确保 TLS 握手时无法被中间人攻击
...
]
每个 SMP 服务器地址包含其离线证书指纹,客户端在建立 TLS 连接前就已经知道服务器身份,这使得 TLS 中间人攻击无法实施。
4.4.2 双层加密架构
第一层——双棘轮加密(Signal 协议):
- 密钥协商:X3DH 协议 + ephemeral Curve448 密钥
- 提供前向保密(Forward Secrecy)和 break-in recovery
- 每条消息使用新的消息密钥,泄露历史密钥不影响后续消息安全
第二层——队列加密(NaCl crypto_box):
- 密钥交换:Curve25519
- 加密算法:Salsa20
- 认证算法:Poly1305
- 每条 SMP 队列消息在传输层之上额外加密,服务器无法解密
服务器认证:
- Ed448 签名密钥,自动生成,用于授权 SMP 命令
- 防止未授权方操作消息队列
传输加密:
- TLS 1.3,保护网络传输层
4.4.3 消息传递流程——SMP 单向队列协议
1. 接收者(Bob)创建单向队列 → 获得队列地址
2. Bob 通过带外通道(当面扫码/视频通话)将队列地址分享给 Alice
3. Alice 使用 SMP 协议向该队列发送消息(固定填充到 16KB)
4. SMP 服务器接收消息 → 暂存 → 转发给 Bob
5. Bob 收到消息后,服务器删除该消息
6. 每条消息使用独立的队列或同队列表项,无关联标识符
关键设计原则:
- 单向性:每个队列只支持单向传递,收发双方使用不同的队列集合
- 固定大小:所有消息填充到 16KB 固定块,防止消息大小分析
- 无状态:消息投递后立即从服务器删除,服务器不保留历史
4.4.4 2-hop 洋葱路由
发送者(Alice) --> 第一跳路由器(Alice选择) --> 第二跳路由器(Bob选择) --> 接收者(Bob)
| | | |
IP仅对第一跳可见 不关联双方身份 不关联双方身份 IP仅对第二跳可见
发送者的 IP 地址仅对第一跳路由器可见,接收者的 IP 地址仅对第二跳路由器可见,有效保护双方传输层身份。
4.4.5 量子抗性双棘轮——双 KEM 并行设计
# 伪代码:双 KEM 并行运行的量子抗性双棘轮
# 传统 DH 是对称的:
# Alice_pub -> Bob 计算 shared_secret
# Bob_pub -> Alice 计算 shared_secret
# sntrup761 是非对称的 KEM:
# Alice_pub -> Bob 封装 shared_secret -> 发送密文给 Alice
# Bob_pub -> Alice 封装 shared_secret -> 发送密文给 Bob
# SimpleX 解决方案:双 KEM 并行(lock-step)
def quantum_resistant_ratchet_step(alice_state, bob_state):
# 每个棘轮步骤同时进行两个方向的 KEM 密钥协商
# Alice -> Bob 方向
bob_ciphertext, bob_shared = sntrup761_encap(alice.public_key)
# Bob -> Alice 方向
alice_ciphertext, alice_shared = sntrup761_encap(bob.public_key)
# 两个方向的共享密钥混合到棘轮状态中
# 保持双棘轮算法的对称性
combined_shared = kdf(bob_shared, alice_shared)
new_root_key, new_chain_key = ratchet_forward(
root_key, combined_shared
)
return new_root_key, new_chain_key
双 KEM 并行设计确保量子抗性集成到双棘轮算法内部,不仅保护初始密钥交换,还保护 break-in recovery 特性。两个方向的 KEM 分别作为 DH 密钥交换的替代,在同一个棘轮步骤中并行完成 [4]。
五、项目应用与评价
5.1 应用场景
| 场景 | 说明 |
|---|---|
| 高隐私需求通信 | 记者、人权活动家、律师、举报人需要保护通信元数据的场景 |
| 企业安全通信 | 需要防中间人攻击、不可否认性的商业机密通信 |
| 敏感地区通信 | 在审查严格地区的安全通信,可通过 Tor 进一步隐藏 |
| IoT 设备通信 | SimpleX 队列协议被用于传感器数据采集和设备控制 |
| AI 服务集成 | 可在 SimpleX Chat 核心上构建自动化服务 |
| 安全监控与控制系统 | 用于设备监控、机器人控制等场景 |
| SimpleGo 微控制器 | 由独立组织开发的微控制器设备,可在单次电池充电下运行 20+ 天 |
5.2 项目优点
- 最强的元数据隐私保护:不存储任何用户标识符,服务器无法知道谁在通信,这是目前所有即时通讯工具中独一无二的特性。
- 非可选的 MITM 防护:密钥验证嵌入连接流程,无法跳过,从根本上杜绝中间人攻击。
- 真正的去中心化:无中心化组件,无全网攻击面,服务器之间不互联。
- 量子抗性加密:率先在双棘轮算法内部实现量子抗性,不仅保护初始密钥交换,还保护 break-in recovery。
- 数据主权:用户数据完全存储在本地,服务器仅临时转发消息,投递后即删除。
- 开源透明:AGPL v3 协议,经过 Trail of Bits 安全审计(2022 年 11 月)。
- 跨平台全覆盖:iOS、Android、Linux、macOS、Windows 全平台客户端。
- 可扩展平台:提供 SDK 用于构建聊天机器人和自定义应用。
5.3 项目不足
- 不支持多设备同时登录:由于 break-in recovery 安全特性,同一配置文件不能同时在多设备上使用(数据可从手机导出到桌面端,但不能同时在线),这是安全性和便利性的权衡。
- 用户规模较小:相比 Signal/TG/WhatsApp 数十亿用户,用户基数小,网络效应有限,实际使用中联系人较少。
- 需要带外通道建立连接:首次连接需要通过其他渠道(当面扫码、视频通话等)分享一次性邀请链接,增加了使用门槛。
- Haskell 生态门槛:核心协议使用 Haskell 编写,虽然保证了安全性,但开发者社区相对较小,第三方贡献和扩展受限。
- 功能仍在完善中:频道功能(v7.0)、量子加密默认启用等功能仍在迭代中,部分功能标记为 Beta。
- 消息投递可能延迟:异步队列机制导致消息投递有轻微延迟,不如中心化平台实时。
- 商业化路径不明确:虽然公司运营但商业模式仍在探索中,长期可持续性有待验证。
- AGPL v3 许可证限制:对商业集成有一定限制,需要衍生作品同样开源。

浙公网安备 33010602011771号