[开源] ECP：基于 ML-KEM-1024 + X25519 的后量子混合加密双棘轮协议 (纯前端/无后端/剪贴板传输)

[jamesliu96]

大家好，最近开源了一个纯前端、零后端的端到端加密（ E2EE ）传输协议与工具：E2EE Clipboard Protocol (ECP)

💡 为什么做这个项目？

我们日常在不信任的通道（如第三方聊天软件、邮件、社交媒体、在线文档甚至公共剪贴板）发送敏感数据（密钥、密码、私密信息）时，往往不得不依赖中央服务器或平台的安全性。

ECP 的目标是实现完全脱离后端的 Out-of-Band 端到端安全传输:

1. 本地生成密钥并与对方交换 Identity Bundle ；
2. 文本/媒体加密后生成 Base64URL 字符串并复制到剪贴板；
3. 通过任何渠道发送给对方，对方粘贴即可在本地解密。

🛡️ 核心密码学 Stack (NIST Level 5 PQC)

考虑到未来量子计算的 Threat Model ，协议从一开始就采用了经典密码学与后量子密码学（ PQC ）结合的混合架构 (Hybrid Construction):

• 混合密钥交换 (Hybrid Key Exchange): X25519 + FIPS 203 ML-KEM-1024
• 复合签名 (Composite Signatures): Ed25519 + FIPS 204 ML-DSA-87 (用于握手身份校验与防 PITM)
• 对称加密与认证: AES-256-GCM (96-bit IV)
• 后量子混合双棘轮 (Hybrid Double Ratchet): 基于 HKDF-SHA256 ，每一轮 DH 棘轮均同时注入新的 ML-KEM 共享密钥，实现后量子级别的前向安全 (Forward Secrecy) 与 破入恢复 (Break-In Recovery)

🏗️ 架构特点

1. 纯前端 / 零后端 / 离线可用: 密钥对生成、会话状态与双棘轮链条全部存储在本地 IndexedDB，不依赖任何 API 服务器，彻底消除服务端攻击面。
2. 严格的 AAD 绑定: 针对 INIT / RESP / MSG 等不同 Packet 构造显式的 AAD (Authenticated Additional Data)，防范跨信道重放、报文篡改与身份误导。
3. 轻量与可验证性: 纯 TypeScript 编写，密码学底层基于 @noble 官方库，无复杂脚手架与不透明依赖，便于源码审计。

📦 开源与 Spec

协议规范、二进制 Wire 布局文档及完整代码均已开源，欢迎试用与 Code Review:

• GitHub 仓库: https://github.com/jamesliu96/ecp
• Online Demo: https://ecp.jamesliu.info/

非常欢迎社区里对密码学、安全或 TypeScript/WebCrypto 感兴趣的朋友提出改进意见、安全假设讨论或 Issue ！

[riceball]

这个麻烦的是目前没有标准的加密共享剪贴板协议，如果真想好用，最好要兼容 Apple Universal Clipboard ，KDE Connect, Clipshare ，等。还有在 readme 中描述的加密协议和剪贴板无关，让人困惑，为啥这个通用的加密数据包格式也要重新发明?
demo 感觉使用上还是麻烦,这个可以参考现成的使用，然后在使用上做到更简单化，否则。
最后，为啥不将编译后的 js 统一放到 dist 目录？在 git 不应该保存编译后的代码。

[jamesliu96]

@riceball 感谢反馈！你提的这几点都挺切中要害的，顺着你的问题我也分享一下当时设计时的一些考量：

1. 关于“协议与剪贴板的关系 / 重造轮子”
你说得很对，严格来说 ECP 的本质确实是一个应用层的 Payload 加密协议，剪贴板只是我选的一种 Out-of-Band 传输介质。文档里写“剪贴板协议”确实容易让人产生误解，后续我把 README 的架构图重新整理一下，把 Crypto Layer 和 Transport Layer 彻底解耦开。

之所以没有直接拿现成的协议来套，主要是想搞一个默认带 PQC 混合双棘轮的纯前端轻量实现。而且在没有服务器协调握手的情况下，INIT 报文需要把双方的 PQC 身份包、临时公钥和复合签名全部塞进一个定长的 Payload 里，现有的通用包格式很难直接套用。

2. 关于“使用体验麻烦 / 兼容 Universal Clipboard & KDE Connect”
体验这块确实是目前最大的痛点，复制粘贴一长串 Base64 体验不够傻瓜。

其实这个项目预期的传输管道就是大家日常用的各种 Chat App 、IM 软件、社交平台甚至邮件。之所以没做成 Apple 剪贴板或 KDE Connect 那种系统级同步，是因为它们基本都依赖局域网广播、后台常驻或者特定平台生态，破坏了“纯 Web 、无安装、离线可用”的前提。后续要怎么在不破坏零后端前提下把体验做得更流畅，我还在思考和探索，也欢迎大家提想法。

3. 关于“为什么把编译后的 JS 存到 Git 里”
这个其实是故意这么设计的。

因为这是一个主打安全和加密的项目，我希望任何拿到代码的人，哪怕本地完全不装 Node 环境、不跑 npm build ，也能直接打开 Git 里的产物进行完整性审计与校验。直接把 JS 留在仓库里，不仅方便静态托管部署，也能让代码的构建结果完全透明、随时可被 verify 。

再次感谢建议，欢迎继续讨论！