为什么E2EMail把OpenPGP运算全部放进Web WorkerIndexedDB密钥环与消息传递设计深度剖析【免费下载链接】e2emailE2EMail is a simple Chrome application - a Gmail client that exchanges OpenPGP mail.项目地址: https://gitcode.com/gh_mirrors/e2/e2emailE2EMail 是一款基于 Chrome 应用的 Gmail 加密邮件客户端用 OpenPGP 协议实现端到端加密收发。它的核心设计值得每个前端工程师细看所有 OpenPGP 加密运算生成密钥、加解密、签名验证都被放进一个独立的 Web Worker 执行密钥环keyring则通过 IndexedDB 在 Worker 内部持久化主线程只通过 postMessage 消息通道与 Worker 通信。本文带你看懂这套架构的三个关键问题为什么要隔离、密钥环怎么存、消息怎么传。一、UI 线程的冻结难题为什么加密运算不能在主线程跑先理解 E2EMail 要解决的问题让用户在 Gmail 上收发只有自己能读的加密邮件加密内容在浏览器本地完成连邮件服务商都无法读取正文。这套交互背后是实打实的计算量生成 ECC 密钥对ECDSA 签名 ECDH 加密均为 256 位曲线需要椭圆曲线标量乘法解密收件箱时每封邮件都要做 ECDH 密钥恢复 解密 签名验证主线程同时还要跑 Angular 界面、渲染邮件列表、响应滚动和点击。如果把运算放主线程界面就会在密钥生成、批量解密收件箱时明显卡顿甚至假死。Web Worker 提供了一个独立线程加密在后台跑UI 保持丝滑——这是 E2EMail 选择它的最直接原因但远不是全部。二、构建即隔离主线程与 Worker 编译成两个独立产物E2EMail 用 Closure Compiler 把同一套源码编译成两个互不包含的 JS 包逻辑就写在构建脚本 do.sh 里./do.sh build ├── worker_binary.js ← 入口 e2email.worker.bootstrapWorker 侧 └── e2email_binary.js ← 入口 e2email.application.module主线程侧两个值得注意的细节主线程产物显式排除 Worker 源码--js!chrome/worker/**.js保证加密封装逻辑不会意外混入 UI 代码关键常量在编译期注入主线程通过--define注入 Worker 的二进制路径WORKER_BINARY_PATHWorker 侧注入密钥服务器地址源码里不留死值。运行时主线程的 openpgp-service.js 用new e2e.async.Worker(WORKER_BINARY_PATH)启动 Worker 实例之后所有加密操作都不再本地执行而是远程调用。三、Worker 启动三步骤从 IndexedDB 密钥环到 OpenPGP 上下文Worker 侧的启动入口只有 bootstrap.js 短短十几行但它串联了整条链路打开密钥环存储new IndexedDbStorage(keyring, ...)—— 创建或加载以keyring为键的密钥环对象构造 OpenPGP 上下文把存储交给e2e.openpgp.ContextImpl它在此之上管理密钥搜索、生成、加解密上线服务new e2e.async.WorkerSelf()绑定当前 Worker 的消息端ContextService.launch(peer, contextPromise)宣告本 Worker 已就绪开始处理请求。主线程侧则是镜像动作e2e.openpgp.WorkerContextImpl.launch(peer)拿到一个远端上下文代理再依次执行解锁initializeKeyRing(password)和设置 ASCII 装甲头setArmorHeader。四、IndexedDB 密钥环一次加载进内存每次变更即持久化密钥环的持久化在 indexeddbstorage.js 中实现设计非常克制要素取值说明数据库名e2email.worker.IndexedDbStorage整个 Worker 共用一个库对象仓库store单一 key-value 结构存储键keyring整个密钥环作为一个大对象存这一条记录工作流程见 indexeddbstorage.js启动时一次性读入内存load_get(keyring)把密钥环整体加载到storage_这个内存 Map 中读写走内存get/set操作的是内存对象零 I/O 延迟变更即落盘persist_每次set或remove后把整个对象以读事务写回 IndexedDB。为什么把密钥环放在 Worker 的 IndexedDB而不是主线程这是安全考量的关键一步私钥材料只在 Worker 的堆内存和 Worker 专属的 IndexedDB 中出现。主线程的 JS 上下文、Angular 的模型里根本看不见私钥——它拿到的永远是加密结果密文或解密后的正文。主线程另有自己的 IndexedDB 封装storage-service.js用于存联系人等普通数据两者物理隔离。此外私钥丢失也不是死局应用会基于 128 位种子生成一个恢复码用户可用它在任意设备重建密钥对——密钥可再生但种子始终留在本地。五、消息传递设计一次调用如何跨线程往返主线程与 Worker 之间没有共享内存一切靠 postMessage 序列化。E2EMail 用了 end-to-end 库的peer对等端 Result结果机制把跨线程调用包装成了 Promise主线程 Worker ────── ────── context_.encryptSign(明文, 密钥) │ postMessage(方法名, 参数) ├─────────────────────────────────────▶ ContextService 分发 │ ContextImpl.encryptSign() 执行 │ ◀──────────────────────────────────── postMessage(结果/错误) ▼ $q.Promise 携带密文 resolve对应到 openpgp-service.js 的真实代码模式每个方法都是同一个套路——创建 Angular 的$q.defer()调用this.context_远端代理上的方法它返回一个异步 Result把 Result 的成功/失败回调接到 Promise 上返回给上层控制器。这样 UI 控制器写出来的代码和调用本地服务几乎没区别openpgpService.encryptSign(...).then(...)异步边界被完全隐藏。而且由于每次跨线程调用都是异步的多个加解密请求可以自然排队不会互相阻塞。六、这套架构的 4 个可复用设计点CPU 密集运算一律进 Worker加密、解析、压缩类库代码与 UI 天然解耦构建层面就排除交叉引用杜绝不小心在主线程算敏感数据归属权跟着计算走私钥只在 Worker 的内存 IndexedDB 中存在主线程只传递密文与正文攻击面最小化peer Result 把 postMessage 变成异步 RPC调用方拿 Promise被调方收 Result协议简单、易测试项目里配套了完整的 karma 单元测试内存缓存 变更即落盘的存储策略把 IndexedDB 的高延迟操作压缩到启动一次和写路径上读操作零成本。如果你正在做带密码学运算的前端应用E2EMail 的 chrome/worker/ 目录不足百行加上一份清晰的构建分离脚本就是一份可直接参考的最小样板。【免费下载链接】e2emailE2EMail is a simple Chrome application - a Gmail client that exchanges OpenPGP mail.项目地址: https://gitcode.com/gh_mirrors/e2/e2email创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考