写在前面，其实分析这个业务之前做了大量理论查询和论证，以及参考了大量钱包作为对比，然后算是一篇总结性的理论吧。
除了前端的架构就是浏览器框架插件那块，单拎一个签名验证出来来分析下业务， 其实熟悉了也还行，就是刚开始的时候需要一些理解。
这是我们定好的通讯协议内容 密钥协商 X25519 对称加密 AES-256GCM
很简短对吧，X25519 需要俩端自己独立计算，由插件端计算完成后， 使用 AES-256GCM 协议加密传输到后端，后端相对的拿到加密串进行解密验证
业务完成。
上面是用最简短的人话说了上面的业务，只是业务刨除什么浏览器框架那一套以及前端框架那些，这篇只暂时针对这个业务以及业务完成闭环逻辑。至于 X25519 和 AES-256GCM 这俩协议包要研究那算是另外的课题了。
好，回到整体业务， 前端插件需要实现的协议要求： 密钥协商：X25519（用于建立共享密钥） 对称加密：AES-256-GCM（用于加密实际消息）
翻译成现实应用就是： 用 X25519 生成一个 双方都能推导出的会话密钥（shared key）， 再从这个 shared key 派生出一个 256-bit 对称密钥， 用 AES-256-GCM 加密所有通信。
其实细化来说， 当然是想到哪儿说哪儿 x25519 推导会话密钥， AES-256-GCM 进行加密，当然涉及到许多问题， 简单来说，在当前会话的所有消息都会采用上述加解密，当然会有一些性能问题，但是安全需要做这种端对端的加密，当然派生问题也不少其实。
比如会话密钥的使用时机
- 保存 AES-GCM session key（只保存在内存）
- 所有请求 → 用 AES-GCM 加密
- 所有响应 ← 用 AES-GCM 解密 会话流程解决的是： 身份认证 加密通信 数据完整性 中间代理不可信 防止 replay 防止伪造请求 防止内部系统泄露明文 会话建立只是“安全通道建立的第一步”。 建立好之后，你要“使用”这个通道来收发数据。
解决的主要问题还是当前会话session建立之后，我们一直使用这个会话，直到页面刷新或者时间过期当然这个都是业务层面商定的。
其实聊到主流钱包到底需不需要这种端对端通信加密的这个业务， 就举例walletconnect肯定是需要的， 因为它们的通信路径是 跨设备，例如： 网页 ↔ 手机钱包 手机 ↔ 桌面应用 DApp ↔ Relay Server ↔ Wallet 不同设备之间不共享内存 有可能经过第三方中继服务器 网络可被监听 中继服务器不可信
只要过三方中继器，那么就需要加密机制，私钥泄漏这个很严重的，而且也有第三方不可信的这么这个问题。分享的事共享密钥，第三方拿到没有对应的机制也没有办法进行加密解密，这个要配合双方私钥对应使用的。
而 metaMask 不做的理由是， 因为： MetaMask 是本地注入，不经过网络 网页本身在浏览器沙箱内 origin 校验足够做身份认证 没有跨设备通信，也不存在中间人攻击 所有 sensitive 操作会弹 UI（用户确认） 所以 MetaMask 设计上不需要额外的 ECDH 加密层。 其实链上授权本身和这种加密通讯就是俩码事儿，根据业务选择可以做可以不做。
说白还是多签钱包的初步起始阶段，通讯内容最终使用AES-GCM-256进行一个加密流程。
┌────────────────────────────┐ ┌─────────────────────────────┐ │ 插件钱包 (Extension) │ │ 后端服务 / DApp Host │ │ - curve25519-js (X25519) │ │ - X25519 / curve25519 实现 │ │ - AES-256-GCM │ │ - AES-256-GCM │ └────────────┬───────────────┘ └─────────────┬──────────────┘ │ │ │ ① 生成本地密钥对（只在本地） │ │──────────────────────────────────────────────────▶│ │ pubWallet = generateKeyPair().public │ │ privWallet = generateKeyPair().private │ │ │ │ ② 发送自己的公钥 pubWallet │ ├──────────────────────────────────────────────────▶│ │ （例如通过 postMessage / HTTP / WebSocket） │ │ │ │ │ ③ 生成对端密钥对 │ │ pubRemote, privRemote │ │ │ ④ 返回 pubRemote │ │◀───────────────────────────────────────────────────┤ │ │ │ ⑤ 双方本地各自计算 sharedKey（同一个值） │ │ 插件： │ │ sharedKey = X25519(privWallet, pubRemote) │ │ │ │ │ 服务端： │ │ sharedKey = X25519(privRemote, pubWallet) │ │ │ ⑥ 各自在本地做 KDF，派生对称密钥 aesKey │ │ aesKey = SHA-256(sharedKey)[0:32] │ │ │ │ │ 同样： │ │ aesKey = SHA-256(sharedKey)[0:32] │ │ │ ⑦ 之后通信都走 AES-256-GCM │ │ （插件这边） │ │ - 生成随机 iv │ │ - ciphertext = AES-GCM-Encrypt(aesKey, iv, msg) │ │ - 发送 { iv, ciphertext } │ ├──────────────────────────────────────────────────▶│ │ │ │ │ ⑧ 服务端用同一个 aesKey 解密： │ │ msg = AES-GCM-Decrypt(aesKey, iv, ciphertext) │ │ │ │ ⑨ 服务端回复时同样用 aesKey + AES-GCM 加密 │◀───────────────────────────────────────────────────┤ │ │ ▼ ▼ ❗ 私钥始终在插件本地 ❗ 私钥始终在服务端本地
- privWallet 不发给任何网页 - privRemote 不发给插件
- 助记词 / 钱包私钥也只在插件内部 - 只对等持有各自私钥
上面就是走的一个完整的流程图