1. Demo 简介
是什么
SSP 是一款端到端加密即时通讯应用，包含 Android 客户端、iOS 客户端和 Go 后端服务。所有消息采用 X3DH 密钥协商 + AES-256-GCM 加密，服务器仅转发密文，永远无法读取任何消息内容。
面向谁
-
对隐私安全有强烈需求的个人用户
-
需要保密通讯的记者、律师、维权人士
-
关注数据主权、不信任第三方云服务的用户
-
希望拥有自主可控加密通讯能力的组织
主要功能
-
端到端加密聊天 — X3DH 密钥协商协议 + AES-256-GCM 对称加密，服务器零知识，私钥永远只在用户设备上
-
文件加密传送 — 任意文件类型加密传输，送达即删，1小时过期自动清理
-
语音消息与实时通话 — 加密语音录制传输，P2P 实时语音通话（WebRTC 信令中继，媒体直连）
-
OTA 安全更新 — 应用内 256KB 分片下载升级，断点续传，无需应用商店
-
密码注册登录 — BCrypt 加盐哈希存储，防止撞库攻击
界面展示：
| 登录界面 | 通讯录 | 聊天界面 |
|---|---|---|
2. Demo 创作思路
灵感来源
在当今数据泄露频发的时代，主流即时通讯应用（如微信、WhatsApp）虽然宣称加密，但用户的密钥、消息仍需经过服务商的服务器，用户只能"信任"服务商不会窥探。Edward Snowden 事件和各类数据泄露事件反复证明：如果密钥不在你手上，加密就不属于你。 我想知道：一个普通人，借助 AI 编程工具，能不能从零构建一个真正"服务器零知识"的加密通讯系统？
想解决的问题
-
服务端无法解密：当前主流即时通讯工具的服务端理论上可以访问用户明文消息，用户隐私完全依赖服务商的自觉
-
消息持久化风险：消息长期存储在服务器上，即使加密也存在密钥泄露后被解密的风险
-
信任过度集中：用户必须信任单一服务商的安全能力和商业道德，缺乏技术层面的保障
为什么做这个方向
加密通讯并非新话题，Signal、Matrix 等方案已经存在。但它们要么依赖中心化服务商，要么部署门槛极高。SSP 的核心取舍是：
-
技术上：选择 X3DH + AES-256-GCM（Signal 协议核心），保证加密强度与行业标准一致
-
架构上：服务器只做密文中继和信令转发，不持有私钥、不存储明文、不提供"解密"接口，从架构层面消灭窥探可能性
-
体验上：让端到端加密对用户无感——注册、聊天、发文件、打电话，操作体验和普通 IM 一样简单
3. Demo 体验方式
在线体验
-
管理后台（可查看系统运行状态、用户信息、在线统计）：http://116.198.40.126:8080/admin/
-
用户名：
admin -
密码：
e2ee-admin-2026
-
-
APK 直接下载安装（Android 8.0+）：http://116.198.40.126:8080/api/update?platform=android
源码本地运行
# 克隆仓库
git clone https://github.com/Josslao/ssp-e2ee-chat.git
# 服务端
cd ssp-e2ee-chat/server
go build -o ssp-server ./...
STORAGE=redis REDIS_ADDR=127.0.0.1:6379 ./ssp-server
# Android 客户端
cd ssp-e2ee-chat/android
./gradlew assembleRelease
# APK 输出: app/build/outputs/apk/release/app-release.apk
4. TRAE 实践过程
项目开发全流程
本项目从零开始，全程使用 TRAE IDE 完成，涵盖后端服务、Android 客户端、iOS 客户端三个平台的开发。以下是关键开发阶段：
阶段一：加密协议设计与后端开发
-
与 TRAE AI 对话，设计 X3DH 密钥协商协议的实现方案
-
AI 协助编写 Go 后端服务：用户注册、公钥存储、密文中继、WebSocket 推送
-
使用 Bouncy Castle 实现 X25519 密钥交换 + HKDF 密钥派生 + AES-256-GCM 加解密
-
服务器架构设计：仅提供密文中继，管理后台不包含任何"读取消息"、“解密”、"私钥"接口
阶段二：Android 客户端开发
-
TRAE AI 生成完整的 Android 项目结构（Kotlin + OkHttp + Bouncy Castle）
-
实现端到端加密消息流程：本地生成密钥对 → 公钥上传 → X3DH 协商共享密钥 → AES-GCM 加密发送
-
逐步添加功能：文件传送、语音消息、实时语音通话（WebRTC 信令中继）
-
UI 设计参考 Telegram/iMessage 风格，左右气泡布局
阶段三：安全加固与功能完善
-
添加用户密码注册/登录（BCrypt 哈希）
-
修复多 WebSocket 连接导致消息丢失的问题（单例 ChatService）
-
聊天界面改为国际通用返回箭头，添加删除对话功能
-
接收文件可保存到手机下载目录（MediaStore API）
阶段四：OTA 更新与部署
-
实现 App 内在线升级功能
-
解决移动网络下载不稳定问题：从整包下载改为 256KB 分片下载，每个分片独立短连接，彻底解决运营商连接重置
-
服务器添加 Range 断点续传支持
-
编译部署到云服务器，版本自动检查与更新
阶段五：iOS 客户端与开源
-
开发 iOS 客户端（Swift + SwiftUI）
-
TestFlight 分发测试
-
项目开源至 GitHub：https://github.com/Josslao/ssp-e2ee-chat
关键技术决策（与 TRAE AI 协作完成）
| 决策 | 选择 | 原因 |
|---|---|---|
| 加密协议 | X3DH + AES-256-GCM | Signal 协议核心，经过广泛安全审计 |
| 服务器架构 | 密文中继，零知识 | 从架构层面保证服务器无法解密 |
| 消息存储 | 送达即删 + 7天TTL | 最小化密文留存时间 |
| 文件存储 | Redis 密文缓存1小时 | 下载后立即删除，不过期不留存 |
| OTA 更新 | 256KB 分片下载 | 移动网络短连接更稳定，抗运营商重置 |
| 密码存储 | BCrypt 加盐哈希 | 防止撞库和彩虹表攻击 |
Session ID
以下为使用 TRAE IDE 开发本项目的关键 Session ID：
6a4b630a1aea188e262223c2— 核心功能开发：加密协议、Android 客户端、消息推送（开发过程中持续使用 TRAE IDE 进行对话式编程，完整 Session 记录可在 TRAE IDE 中查看）
5. 安全设计说明
为什么"服务器零知识"很重要
传统即时通讯的信任模型是：用户信任服务商不会滥用数据。但这种信任是脆弱的——服务商可能被黑客攻击、被政府要求交出数据、或被商业利益驱动分析用户内容。
SSP 的信任模型是：用户不需要信任服务商。因为：
-
私钥永远不在服务器上 — 用户注册时本地生成密钥对，仅上传公钥
-
服务器只看到密文 — 所有消息、文件在客户端加密后才发送
-
管理后台没有解密接口 — 管理员也无法读取消息内容
-
消息送达即删 — 服务器不持久化存储密文，最短生命周期
-
WebSocket 推送不含密文 — 只推送消息 ID 和类型，客户端主动拉取密文
加密流程
发送方 服务器 接收方
| | |
|-- 1. 获取接收方公钥包 ----------------->| |
|<-- 2. 返回公钥包 ----------------------| |
| | |
|-- 3. X3DH 协商共享密钥（本地） | |
|-- 4. AES-256-GCM 加密消息（本地） | |
| | |
|-- 5. 发送密文 ------------------------>|-- 6. 存储密文，推送通知 ID ----------->|
| | |
| |<-- 7. 接收方拉取密文 -----------------|
| |-- 8. 送达即删 ---------------------->|
| | |
| | 9. X3DH 协商共享密钥（本地） |
| | 10. AES-256-GCM 解密（本地） |
6. 技术架构
| 层级 | 技术选型 |
|---|---|
| 加密协议 | X3DH（密钥协商）+ AES-256-GCM（对称加密）+ BCrypt（密码哈希） |
| 后端服务 | Go + Redis + WebSocket |
| Android 客户端 | Kotlin + OkHttp + Bouncy Castle + Google WebRTC |
| iOS 客户端 | Swift + SwiftUI + Network.framework + STUN |
| OTA 更新 | 256KB 分片下载 + Range 断点续传 |
报名帖链接： （待发布后补充）