自研技术：XO 通讯
XO通讯在线体验
前言
起初是因为觉得微信传输助手的传输速度太过于缓慢，而且在中国大陆内还有内容限制，于是下定决心自研即时通讯，坚定这个想法的时候，大概在2024年的9月份。
我的想法很疯狂，但现实是，因为服务器没有足够的带宽，无法运行整个聊天系统，项目被搁置…
XO通讯：临时聊天 · P2P端到端加密 · 离线即清空
但是GitHub上面有很多免费开源的端到端加密聊天项目，为什么我不用呢？其实我也不知道。至于市面上的临时聊天工具，我也信不过，怎么安全的端到端加密也有被劫持的可能。
XO通讯功能
这就是页面效果图部分，前端效果是让Agent做的，已经手动去除大部分的AI味，剩下的UI想改动恐怕有点难，也暂时还没想到有更好的布局和UI风格。
可以创造聊天跟加入聊天，还有历史记录功能！
创造聊天
顾名思义，创造新的聊天室。新的聊天室创造后会随机获取一个长度30位的随机字符串作为聊天室的ID，这个ID不可更改，以保证聊天室的安全。
创造聊天室的被称为群主，群主的设备将有作为整个服务聊天的服务器义务，用户上传的图片、视频文件以及聊天的信息等存储性元素都会加密存储于群主的设备中。
当群主离开聊天室，聊天室内的缓存就是仅剩的聊天记录，这就是为什么群主一旦离开群聊天，立马解散，意思是。所有人的缓存都完全清楚之后将会没有数据备份。
加入聊天
用户可以通过好友发送的30位聊天房间ID进入房间，也可以通过扫描好友发送的二维码或者点击链接来进入房间，这也是我们下面要说的分享房间功能。
因为生成二维码的组件后面跟某些功能发生冲突，所以便舍去。没办法尽力了，况且有链接了要二维码干嘛？
分享格式目前只保留了房间码跟链接形式，后续有时间可能会继续优化，引入回二维码，不过未来可能不会那么有空。有空的时候我会研制看看有没有什么更好的代替方法。
聊天界面与功能
最基本的，编辑群聊消息，可以改群名，可以改自己的昵称，群主可以踢除禁言群成员。
聊天界面经过了挺多轮的优化，其实现在界面我觉得是我改的最美的一版，这个对话只有依旧部分广东人看得懂。
右键菜单已被优化，现在更加自然一点。
XO通讯技术
一、核心定义
P2P E2EE（Peer-to-Peer End-to-End Encryption，点对点端到端加密）： 通信双方设备直接完成密钥生成、消息加解密，中转服务器仅转发密文，无能力解密聊天明文；不存在中心化密钥存储，从根源避免站长、平台服务商窃取聊天内容。
二、整体技术架构分层
1. 网络层：P2P 点对点穿透通信
- STUN/TURN 中继服务器（站长仅提供中转）
- STUN：获取设备公网IP、端口，实现内网设备直连（绝大多数情况不走服务器流量）
- TURN：内网严格隔离、NAT无法穿透时，作为流量中继转发密文
- 关键：服务器只转发二进制密文，不参与任何加密运算，无法解析内容
- P2P 直连优先级设备直连 > TURN中继转发，降低服务器流量成本，同时减少中间人风险。
2. 密码学层：混合非对称+对称加密（行业标准组合）
（1）非对称加密（ECDH 椭圆曲线密钥协商）
- 算法：X25519 / Curve25519（轻量化、移动端/浏览器友好）
- 作用：双方交换公钥，本地计算出共享密钥，全程不传输私钥
- 流程：
- 用户A本地生成：A公钥 + A私钥
- 用户B本地生成：B公钥 + B私钥
- A、B互相交换公钥（公钥明文可被服务器抓取，无安全风险）
- A = A私钥 + B公钥 → 算出共享密钥
- B = B私钥 + A公钥 → 算出完全一致的共享密钥
风险点：服务器/站长篡改公钥 → 中间人劫持攻击（MITM）
（2）对称加密（消息主体加密）
- 算法：AES-GCM-256
- 作用：用ECDH算出的共享密钥加密聊天文字、图片、文件
- 特性：自带完整性校验+防篡改，消息被站长修改后对方直接解密失败
（3）签名/指纹校验（抵御站长劫持核心方案）
- 算法：Ed25519 椭圆曲线签名
- 用途：对公钥生成固定指纹（数字验证码/二维码）
- 使用逻辑：通信双方手动核对6位数字指纹，确认对方公钥未被服务器篡改；只要核对一致，站长无法劫持聊天。
（4）额外安全组件
- HKDF：密钥派生，分层拆分聊天密钥、文件密钥，避免复用密钥泄露风险
- HMAC：消息校验，防止密文被篡改、重放攻击
- 随机Nonce：每条消息生成唯一随机串，同内容不会生成相同密文
3. 前端/客户端运行层（网页端核心风险点）
1）独立客户端（桌面/APP）
加密逻辑编译进本地程序，代码固定，站长无法篡改，安全等级最高。
2）网页版P2P聊天（你搭建网站的场景，存在劫持漏洞）
加密JS脚本由站长服务器下发，存在两大可控漏洞：
- 恶意篡改JS，窃取本地私钥、明文；
- 替换加密算法，关闭E2EE裸传消息。
三、完整通信流程（标准安全流程）
- 双方设备初始化，生成X25519密钥对、Ed25519签名密钥；
- 通过网站服务器交换公钥（仅中转，不解密）；
- 双方手动核对公钥指纹，确认无中间人劫持；
- 本地ECDH计算共享密钥，HKDF导出AES加密密钥；
- 发送方明文→AES-GCM加密为密文→P2P直连/TURN转发；
- 接收方本地私钥解密，校验消息完整性；
- 所有聊天明文仅留存双方本地设备，服务器无任何明文记录。
四、站长可劫持/不可劫持场景区分
| 场景 | 是否会被站长劫持 | 风险说明 |
|---|---|---|
| 网页P2P、不核对密钥指纹 | ✅ 极易劫持 | 站长篡改公钥实施中间人攻击，偷看全部聊天 |
| 网页P2P、每次手动核对指纹 | ❌ 无法劫持 | 指纹校验拦截假公钥，中间人攻击失效 |
| 网页P2P、站长恶意修改前端JS | ✅ 完全失控 | 加密代码被篡改，私钥/明文直接上传站长后台 |
| 独立客户端P2P E2EE | ❌ 无法解密内容 | 站长仅中转密文，无权限修改本地加密逻辑 |
五、规避站长劫持的工程优化方案
- 强制指纹校验：不核对指纹禁止发起聊天；
- JS脚本完整性校验：前端内置脚本哈希值，加载时校验，篡改直接拒绝运行；
- 静态资源CDN固定哈希（Subresource Integrity SRI）：网页加密脚本绑定固定校验值，站长修改JS后浏览器直接拦截加载；
- 可选离线客户端：脱离网页环境，彻底杜绝前端投毒风险；
- 公钥本地缓存：缓存对方可信公钥，二次聊天自动校验，防止中途篡改。
六、元数据说明（站长必然可收集，无法加密隐藏）
即使E2EE完全安全，站长仍能获取以下行为数据：
- 双方IP地址、在线时间、消息发送频次；
- 消息长度、文件大小、通信时长；
- 无法获取：文字内容、图片、文件、语音明文。
七、和普通加密聊天的核心区别
- 中心化加密聊天：服务器持有密钥，站长可一键解密所有聊天；
- P2P端到端加密：密钥仅存在用户设备，服务器永久无法解密密文。
汇总
- 底层密码学：X25519 密钥协商 + AES-GCM-256 消息加密 + Ed25519 指纹防劫持；
- 网络：STUN/TURN 实现 P2P 直连，服务器只转发密文；
- 最大安全短板：网页版 JS 由站长下发，可篡改窃取私钥；
- 唯一防御劫持手段：双方手动核对公钥指纹。
总结
XO通讯暂时没有开源项目，因为这个系统也算是基于MmzMing大佬的博客二次开发的，尽管它是新的系统，也脱离不了原始架构，所以想独立估计不太可能，后面可能有时间会单独重构做一个域名。
大家感兴趣也可以去体验一下：blog.xuioo.com/chat
部分内容可能已过时
