跳到正文
返回文章列表

Crypto Toolkit 的密码学设计:从密钥派生到流式加密

解析Crypto Toolkit的密码学构造以及为什么它们必须全部在浏览器沙箱内完成。

2026年8月23日 18 min #密码学#网络安全#工具#Web 密码学

Crypto Toolkit 是一套开源的纯前端密码学工具箱:支持任意大小的文件流式加密、端到端公钥密钥分发、加密私聊以及多哈希算法文件完整性校验。

该工具不存在后端服务、没有用户系统、也不设遥测收集数据。所有的密码学计算均在浏览器的本地沙箱中完成,服务器仅作为静态web资产分发。


威胁模型:为什么必须「零网络」?

在现代密码学工程中,最大的弱点往往不是数学算法的脆弱,而是信任边界。正如人之于网络安全是最脆弱的一环。

传统云端工具
用户明文 / 主口令
网络传输 / TLS 边界
云端服务器
内存可见 · 潜在审查 · 日志泄露
本地沙箱模式
用户明文 / 主口令
浏览器 Worker 内存
加密产物
0 网络请求

一旦将口令或明文通过网络发送给后端,无论声明了多么严苛的隐私协议,用户都必须无条件信任服务端的内存隔离、日志策略与运维安全性。

为了将信任边界收缩至最低限度,Crypto Toolkit 确立了三项不可妥协的设计原则:

  1. 绝对零网络:密钥、口令、明文及临时计算状态均不可触发任何网络 I/O
  2. 原生密码学实现:所有核心运算通过 libsodium-wrappers(libsodium 官方编译的 WebAssembly 构建)与 @noble/hashes 执行,规避纯 JavaScript 实现中的侧信道风险;
  3. 恒定内存流式处理:针对GB级别的大文件,利用 Web Worker 与 Streams / File System Access API 实现分块流水线,防止浏览器内存溢出(OOM)。

第一层:口令硬化与密钥派生(Argon2id)

在对称加密大文件时,人类可记忆的密钥口令往往熵值有限。直接使用 SHA-256 派生密钥会导致口令在 GPU/ASIC 阵列面前瞬间被暴力破解(如现代 RTX 4090/5090 显卡每秒可尝试百亿次快速哈希)。

本工具采用 Argon2id,Password Hashing 竞赛的优胜算法,作为密钥派生函数(KDF):

口令 Password + 随机盐 Salt(16 字节)
Argon2id Memory-Hard Function
  • 内存成本:64MB ~ 256MB
  • 时间迭代:如 t = 3
  • 并行通道:如 p = 4
256-bit 高强度对称主密钥

核心防御优势

  1. 内存硬化:算法强制在 RAM 中开辟密集读写的内存空间。显卡及定制 ASIC 芯片虽然计算单元极多,但其片上 SRAM/显存带宽极易被耗尽,从而抹平了专用硬件对通用 CPU 的并行算力代差。
  2. Argon2id 混合模式:结合了抵抗侧信道攻击的 Argon2i(数据访问与口令独立)与抵抗时间-内存权衡攻击(TMTO)的 Argon2d(数据访问依赖运算状态),是通用密码学环境的最佳实践。
  3. 唯一随机盐:每次加密均由 CSPRNG(密码学安全伪随机数生成器)生成 16 字节随机盐,以明文形式固化在密文头部。它确保了即使口令相同,派生出的对称密钥与密文也绝对随机,彻底免疫彩虹表预计算。

第二层:认证加密(AEAD)

在现代应用密码学中,仅有机密性是不够的,必须同时保证完整性与真实性。Crypto Toolkit 全面采用 AEAD 模式,杜绝填充预言机与密文延展性攻击。

工具支持并对比了两种主流方案:

评估维度AES-256-GCMXChaCha20-Poly1305
底层架构分组密码(Block Cipher,SPN 网络)流密码(Stream Cipher,ARX 结构)
Nonce 长度96-bit192-bit(扩展 Nonce)
Nonce 冲突容限极低(同密钥下重用即灾难性崩溃)极高(大数随机生成,冲突概率可忽略)
无硬件加速环境较慢(纯软件易受缓存定时攻击)极快(纯软件恒定时间,天然免疫定时侧信道)
推荐使用场景具备硬件 AES-NI 加速的系统WebAssembly

潜在弱点?

在 AES-GCM 中,96 位的 Nonce 受生日悖论限制:在生成约 $2^{32} \sim 2^{48}$ 个消息后,随机生成 Nonce 的碰撞概率将突破性增加。一旦在相同密钥下发生 Nonce 重用,攻击者即可通过异或计算恢复明文差分,并借助 GHASH 线性特征伪造认证标签。


第三层:CRYPTA 流式容器格式

若要安全加密数GB的大文件,不能一次性将整卷数据读入内存,必须做流式分块。但简单的「分块独立加密」易遭受块重排、块丢弃与块拼接攻击

Crypto Toolkit 实现了自定义的 CRYPTA 流式容器(参考了 crypto_secretstream 的状态演进思路):

容器头部 · Header
魔数 CRYPTA版本号KDF 参数Salt · 16B根 Nonce · 24B算法标识
加密元数据包 · 独立 AEAD 认证
原始文件名MIME 类型原始字节数修改时间戳
链式加密分块流 · Stream Chunks
分块 0密文数据Auth Tag · 16B
Key Ratchet ↓
分块 1密文数据Auth Tag · 16B
Key Ratchet ↓
最终分块 n密文数据Auth Tag · 16BFINAL_TAG

关键架构

  1. 状态棘轮演进: 加密并非使用单一固定密钥。每个分块的认证标签与当前状态机混合,向下派生出下一个分块的临时上下文。任何一个分块被篡改、调换顺序,后续所有分块将立刻无法通过认证。
  2. 抗截断设计: 容器协议在最终分块上附带 FINAL_TAG 状态标识。如果攻击者恶意中断传输导致文件尾部丢失,解密器在读到流结尾时若未收到最终标志,会抛出致命错误并废弃解密文件。
  3. 文件子密钥隔离: 主密钥并不直接接触数据流。系统利用 HKDF(RFC 5869)混淆随机 Salt 派生出专属文件子密钥,确保同一个主口令加密的多个文件之间形成彻底的密码学隔离。
  4. 恒定内存写盘: 搭配 Web Streams API 与 File System Access API(showSaveFilePicker),浏览器按块读取源文件、在 Worker 中计算后直接写回磁盘,无论文件是 100MB 还是 20GB,内存占用始终恒定在数十MB以内。

第四层:非对称密钥分发(X25519 密钥封装)

对称加密解决了单机存储问题,但无法解决跨信任边界的密钥共享问题。工具采用 X25519 椭圆曲线 Diffie-Hellman(ECDH)实现了非交互式的密钥封装机制(KEM):

发送方
  1. 生成临时密钥对 eph_sk / eph_pk
  2. SharedSecret = X25519(eph_sk, Receiver_pk)
  3. WrapKey = HKDF-SHA256(SharedSecret)
  4. EncryptedKey = AEAD(WrapKey, FileKey)
接收方公钥
CRYPTA KEY 包
eph_pk + EncryptedKey
接收方
  1. SharedSecret = X25519(Receiver_sk, eph_pk)
  2. WrapKey = HKDF-SHA256(SharedSecret)
  3. FileKey = AEAD-Decrypt(WrapKey, EncryptedKey)
  • 恒定时间阶梯计算:X25519 基于 Montgomery 曲线,其标量乘法通过固定时序的 Montgomery Ladder 实现,从算法层杜绝了时序侧信道攻击;
  • 高安全强度:255 位的曲线参数提供了大约 128 位的经典密码学安全强度,与 256 位对称加密方案(AES-256 / XChaCha20)在安全级别上严密契合;
  • 身份私钥离线托管:接收方可在前端生成私钥,并通过上一层的「Argon2id + AEAD」用口令加密后导出为受保护的 .key 备份文件,全程无明文私钥。

第五层:多算法完整性校验体系

在数据归档与传输验证中,高频的核心诉求是:「如何验证目标介质中的数据与原始文件完全一致,没有发生静默损坏或恶意篡改?」

待校验大文件
分块读取流 · 64KB ~ 1MB
BLAKE3
BLAKE2b-512
SHA3-512
SHA-256 / SHA-1 / MD5
聚合校验结果清单
JSON · BSD · Linux Sum

特性与工程优化

  1. 单次 I/O 推进多哈希: 支持并发计算包括 BLAKE3、BLAKE2b-512、SHA3-256、SHA3-512、SHA-256、SHA-1、MD5 在内的多种摘要。通过在 Worker 中复用分块字节流,多算法同时消费同一批 Buffer,避免重复读取磁盘导致 I/O 瓶颈。
  2. 现代哈希性能标杆(BLAKE3): 默认推荐使用 BLAKE3。它在内部引入了 Merkle Tree 树状结构,天然支持强悍的内部并行度与 SIMD 加速,其计算吞吐量远超传统 SHA-256,且保有极高的抗碰撞安全性。
  3. 旧格式完全兼容: 系统解析器向下兼容 md5sumsha256sumb2sum 及 BSD 标签格式校验清单,可自动化进行「一致(MATCH)、损坏(MISMATCH)、缺失(MISSING)」三态比对。

整体工程架构总览

将上述密码学组件整合进现代浏览器环境,整体工程架构如下:

浏览器主线程 · UI Thread
DOM 渲染 / 进度展示
File System Access API 句柄维护
MessageChannel · Transferable ArrayBuffer
Web Worker 运行时 · 沙箱隔离 / 后台并发
stream.worker.js libsodium.wasm Argon2id 内存分配 CRYPTA 状态棘轮流式读写
integrity.worker.js @noble/hashes BLAKE3 / SHA-3 并发流计算 清单校验与比对引擎
  • 零主线程阻塞:重算力与 I/O 操作均被隔绝在独立 Worker 中,保证加密 50GB 文件时 UI 依然达到 60 FPS 流畅度;
  • 零内存拷贝损耗:数据块通过 postMessageTransferable Objects 机制传递,直接移交内存指针所有权,避免垃圾回收(GC)造成界面卡顿。

结语

使用密码学工具不应去信任某一家闭源商业公司,应构建无需信任的确定性体系

  • 拒绝私有黑盒算法
  • 代码可审计
  • 数据不出沙箱

“Cryptography is typical of systems that require high security. You don’t get security by just throwing in cryptographic algorithms, you have to design the whole system to be secure.” —— Bruce Schneier

评论区

无需注册,选择任意昵称参与讨论

正在载入讨论…