浏览器中的后量子加密：信任与局限

浏览器无需安装原生消息应用，也能在本地执行端到端加密，包括后量子密钥建立。难题不是这些数学运算能否在标签页中运行，而是所交付的应用、密钥处理方式和更新路径，是否值得给予这段对话所要求的信任。

无法安装应用时，通过网页访问可能很方便。但这并不会让应用免受审查、托管环境失陷、恶意扩展或设备失陷的影响。

浏览器的密码学基础组件

WebCrypto 提供加密、密钥派生、签名和密钥管理的底层操作。常见实现提供 AES-GCM 和 ECDH 等基础算法。这些操作只是构建组件，并非完整的经过认证的消息协议。

在所需原生 API 不可用时，网页应用可以通过 JavaScript 或 WebAssembly 加入经过审查的 ML-KEM 实现。浏览器支持情况会变化，因此开发者应对确切的目标版本进行功能检测，而不是假定所有浏览器提供相同算法。

混合流程的概念示意如下：

1. 使用密码学安全的随机性生成适当的密钥。
2. 利用协议的身份机制认证对方的密钥材料。
3. 获取传统和后量子的共享秘密贡献。
4. 按照指定的密钥调度方案和对话上下文将它们组合起来。
5. 使用派生密钥进行认证加密，并正确处理 nonce 和状态。

这只是解释性概要，不是实现配方。FIPS 203 将 ML-KEM 标准化；它并不为特定浏览器应用提供认证，也没有定义聊天协议的每个步骤。

HTTPS 交付是信任模型的一部分

处理明文的 JavaScript 和 WebAssembly 通常由服务器提供。即使密码库使用可靠的算法，遭恶意修改的应用仍可在加密前或解密后读取消息。

HTTPS 有助于认证交付来源，并保护交付过程免受网络干扰。它不能证明源站运营者、其部署系统或依赖项未被攻破。普通 HTTPS 网页也不会自动成为经过独立签名的应用软件包。

W3C WebCrypto 安全注意事项 讨论了脚本注入以及保护应用完整性的必要性。内容安全策略、谨慎的依赖管理和其他网页安全控制可以降低风险，但它们都无法把任意同源脚本变成无法触及应用数据的不受信任观察者。

WebAssembly 同样处于应用的安全边界内。其沙箱通过明确定义的接口限制对宿主的访问，但不会让调用它的页面变得可信。将 C 编译为 Wasm，也不会让源语言具备内存安全性。

密钥不一定只存在于 RAM 中

浏览器消息应用可能持久化保存密钥或加密状态，使用户能够恢复使用同一身份。它也可能提供设备关联或加密恢复。这些行为必须有文档说明，不能想当然地认为它们不存在。

值得提出的问题包括：

• 哪些密钥会被持久化保存，存在哪种浏览器存储中？
• 清除站点数据或结束隐私浏览会话后，会发生什么？
• 不可导出的密钥，是否仍可被在应用上下文中运行的恶意代码使用？
• 新交付的更新能否访问旧的本地状态？
• 恢复功能恢复的是身份、消息历史，还是两者？

不可导出的 WebCrypto 密钥限制的是通过 API 导出。它本身并不能阻止恶意应用代码请求允许的操作或收集明文。

网页客户端和原生客户端各有取舍

关注点	浏览器客户端	原生客户端
分发	源站、托管环境和网页更新流程	应用商店或软件包分发及签名流程
本地持久化	浏览器存储和用户配置文件行为	操作系统应用存储和应用生命周期
暴露面	同源脚本、扩展和浏览器漏洞	应用依赖项及操作系统／应用漏洞
可用性	可访问的域名及所需网络服务	已安装的应用仍需要其必需的网络服务

不检查具体实现，任何一列都不能证明哪种方案胜出。网页应用在被应用商店下架后可能仍可访问，但域名被封锁或缺少网络路由，仍可能阻止访问。

测量性能，而不是承诺性能

按照 FIPS 203，ML-KEM-768 使用 1,184 字节的封装密钥和 1,088 字节的密文。这些大小有助于解释为何协议可能安排 KEM 更新，而不是给每条短消息附加新的材料。它们并不是整个应用带宽或速度的测量结果。

有用的基准测试应说明浏览器、设备、构建版本、预热方法、所测操作以及耗时分布。还应包含页面启动、模块加载、内存使用、低端设备和网络开销。“所有现代手机上都低于两毫秒”之类的说法需要公开测量数据；本文并未提供这些数据。

将这些原则应用于 Livara

Livara 的安全概览 说明了 LVR1 及其恢复边界。Proof Lab 演示部分本地 P-256、HKDF 和 AES-GCM 操作；页面明确指出，完整的 LVR1/LGS1 组合不在该测试台范围内。因此，演示通过并不能证明所有已交付网页代码的安全性。

在浏览器中进行敏感对话前，应使用真实且持续维护的客户端，阅读当前威胁模型，保护浏览器配置文件，并通过支持的密钥检查流程验证对方。只要网页交付边界始终纳入评估，便利性和有用的密码技术就可以共存。