浏览器加密能力：现代浏览器能做什么

现代浏览器内置的原生密码学能力可与专用安全库相媲美。Chrome、Firefox、Safari 和 Edge 全部暴露了 Web Crypto API（crypto.subtle），通过 HPKP 后继机制实现带证书锁定的 TLS 1.3，支持 WebAuthn/Passkeys 实现抗网络钓鱼认证，用 Site Isolation 将每个来源沙箱化，并通过 Windows 上的可信平台模块（TPM）和 macOS/iOS 上的 Secure Enclave 提供硬件级密钥存储。对于构建加密文件传输工具的开发者，这意味着 AES-256-GCM 加密、PBKDF2 密钥派生和 FIDO2 认证都可免费获得，无需任何外部库。以下是各主流浏览器在 2026 年实际能做什么。

Web Crypto API：共同基线

四大主流浏览器都支持 W3C Web 加密 API，接口几乎完全相同。核心算法包括：

对称加密：AES-GCM、AES-CBC、AES-CTR、AES-KW（128、192、256 位）
非对称加密：RSA-OAEP、RSA-PSS、RSASSA-PKCS1-v1_5（最高 4096 位），ECDSA 和 ECDH（P-256、P-384、P-521）
哈希：SHA-1、SHA-256、SHA-384、SHA-512
密钥派生：PBKDF2、HKDF
消息认证码：HMAC

尚不支持的算法：ChaCha20-Poly1305（所有浏览器均不支持）、Argon2（所有浏览器均不支持）、Ed25519/X25519（Safari 17+ 和 Firefox 129+ 已支持，Chrome 正在跟进）。这些算法仍需 libsodium.js 或 @noble/curves 等 JavaScript 或 WASM 库。

Chrome 和 Edge 共享相同的加密实现（通过 V8 的 BoringSSL）。Firefox 使用 NSS。Safari 使用 CoreCrypto，即 Apple 的 FIPS 验证库。性能有所差异：在同等硬件上，Firefox 的 PBKDF2 迭代速度比 Chrome 慢约 20%；在 Apple Silicon Mac 上，Safari 利用硬件加速的 AES-GCM 速度约是 Chrome 的 2 倍。

TLS 1.3 与证书透明度

所有主流浏览器在支持的服务器上默认使用 TLS 1.3，仅对旧版服务器回退至 1.2。Chrome 于 Chrome 84（2020 年 7 月）移除了 TLS 1.0 和 1.1 支持。Firefox 在 Firefox 78 中移除。Safari 在 macOS 11 / iOS 14 中弃用。

证书透明度（CT）强制执行：2018 年 4 月之后颁发的证书必须出现在至少两个 CT 日志中，否则 Chrome 和 Safari 将拒绝。这使 CA 错误颁发行为公开可审计，从而尽早发现 DigiNotar 式攻击。Mozilla 的 Firefox 从 Firefox 117（2023 年）开始强制执行 CT。

通过 HPKP 头实现的公钥锁定已被弃用（Chrome 72 移除了支持），因为它可能导致锁定攻击。Expect-CT 头具有相同的监控目的，自 CT 成为强制要求后也逐步淡出。需要锁定功能的企业可通过受管配置（macOS 上的 MDM、Chrome 企业策略）实现可信根锁定。

来源隔离与沙箱机制

Chrome 的 Site Isolation 自 2018 年（桌面）和 2019 年（Android）起将每个来源置于独立的操作系统进程中。Firefox 的 Fission 自 Firefox 94 起实现相同效果。Safari 使用 WebKit 的每进程模型。对加密的意义在于：恶意的跨来源脚本无法从兄弟标签页的内存中读取你的解密文件，因为兄弟标签页处于不同进程，拥有独立的堆内存。

Cross-Origin-Opener-Policy（COOP）、Cross-Origin-Embedder-Policy（COEP）和 Cross-Origin-Resource-Policy（CORP）允许页面选择更严格的隔离。设置 Cross-Origin-Opener-Policy: same-origin 和 Cross-Origin-Embedder-Policy: require-corp 可启用跨来源隔离，进而解锁 SharedArrayBuffer 和高精度计时器。这与加密相关，因为当攻击者无法在你的来源中打开 SAB 时，针对 AES 实现的 Spectre 类时序攻击的影响得到缓解。

WebAuthn 与 Passkeys 认证

FIDO2 WebAuthn 在 Chrome 67+、Firefox 60+、Safari 14+ 和 Edge 18+ 中均受支持。它允许应用通过硬件密钥（YubiKey、Titan）、平台认证器（Face ID、Windows Hello、Android 生物识别）或通过 iCloud 钥匙串、Google 密码管理器或 1Password 跨设备同步的 Passkeys 进行用户认证。

对于文件传输应用，WebAuthn 可替代密码作为保护存储共享链接访问的认证因素。关键在于 WebAuthn 可抵抗网络钓鱼：签名与来源绑定，因此仿冒域名无法捕获凭证。Chrome 和 Safari 均于 2023–2024 年迁移至默认 Passkeys 流程，大多数消费者使用场景不再需要物理密钥。

硬件级密钥存储

在 Windows 上，TPM 2.0 芯片（Windows 11 的强制要求）可通过 Windows CNG 桥存储以不可提取方式（extractable: false）生成的 Web Crypto 密钥。在 macOS 和 iOS 上，Secure Enclave 持有用于 Face ID、Touch ID 和 Passkeys 的密钥。在 Android 上，由 StrongBox（硬件）或 TEE（可信执行环境）支持的 Keystore 提供类似保护。

实际意义：在现代笔记本上以 extractable: false 通过 Web Crypto 生成的密钥可能存储在 TPM 或 Secure Enclave 中，而非主内存。即使是完全入侵浏览器并转储 JavaScript 内存的攻击也无法获得原始密钥字节。对于文件传输工具，这对长期接收者密钥最为有用；短暂的每文件 AES 密钥不需要此保护。

内容安全策略：加密的倍增器

如果恶意脚本在加密之前就能读取明文，那加密就毫无意义。内容安全策略（CSP）头允许网站声明哪些脚本可以运行。严格策略如：

Content-Security-Policy: default-src 'self'; script-src 'self' 'strict-dynamic' 'nonce-abc123';

会阻止内联脚本和第三方代码，不留任何注入窃密载荷的攻击面。所有主流浏览器均支持 CSP Level 3。对于文件传输应用，将 CSP 与任何外部脚本的子资源完整性（SRI）结合使用，确保即使是允许的第三方 JavaScript 也未被篡改。

文件系统访问与 OPFS

File System Access API（Chrome 86+、Edge 86+、通过 Origin Private File System 部分支持的 Safari 15.2+）允许 Web 应用在用户授权下读写本地文件。Origin Private File System 与加密尤为相关：它是每个来源独有的、由浏览器管理的私有文件系统，可用于在上传前暂存大型加密载荷，而无需将整个内容加载到内存中。

Firefox 对 FSA 的支持进展较慢，但自 Firefox 111 起支持 OPFS。Safari 全面支持 OPFS，但在更广泛的 File System Access API 上行为更为保守。

浏览器目前仍做不好的事情

仍存在一些空白：

Argon2 密钥派生在 Web Crypto 中缺失。对于高于 PBKDF2 级别的密码哈希，使用 WASM 库。
ChaCha20-Poly1305 未暴露。AES-GCM 满足大多数需求，但在没有 AES-NI 的设备（较老的 ARM）上 ChaCha 会更有帮助。
硬件级密钥证明受到限制。WebAuthn 提供证明；更广泛的 Web Crypto API 不提供。
流式 AEAD 尚未进入规范。大文件加密需要分块逻辑或 WASM。
后量子算法（Kyber、Dilithium）尚未进入浏览器。Google 已在 TLS 握手中部署 Kyber（Chrome 116+），但 JavaScript 暴露的后量子加密仍属于库的领域。

2026 年文件传输的推荐技术栈

2026 年可信赖的浏览器端文件传输技术栈：

通过 crypto.subtle.encrypt 实现文件内容的 AES-256-GCM
PBKDF2-SHA-256（60 万次迭代）用于密码派生密钥
crypto.getRandomValues() 用于盐值和 nonce（绝不使用 Math.random）
URL 片段（#key=...）在不暴露给服务器的情况下传递密钥
TLS 1.3 最低要求的 HTTPS，启用 HSTS，使用 COOP/COEP 进行隔离
CSP strict-dynamic，无内联脚本
WebAuthn Passkeys 用于任何账号存储功能
OPFS 用于 Chrome/Edge/Safari 16+ 上的大文件暂存

HexaTransfer 本质上运行这套技术栈。SwissTransfer、Tresorit Send、Cryptpad 和 Proton Drive Share 也是如此。这些原语已经成熟，在各浏览器间保持一致。

跨浏览器测试

务必在全部四款浏览器中测试。实际遇到的 bug 包括：Firefox 对 Chrome 静默接受的 PBKDF2 输入抛出 OperationError；Safari 的 FileReader 在 2 GB 以上文件时速度较慢；Chrome 的 OPFS 在某些版本中对 4 GB 以上的分块写入有特殊处理。WebAuthn 用户验证提示差异显著（Face ID vs Touch ID vs Windows Hello vs Android 生物识别）。使用 BrowserStack、Sauce Labs 或本地物理设备矩阵进行发布前测试。

浏览器已悄然成为最完整的加密平台之一。支撑银行应用、密码管理器和即时通讯客户端的同一套基于标准的原语，对任何构建加密文件传输工具的开发者来说，只需一行 JavaScript 调用即可使用。

在 hexatransfer.com 上试试 — 免费、无需注册、最多 10 GB。