我阅读了 W3C 文章 (https://www.w3.org/TR/WebCryptoAPI/#protected-document) 中关于 Web Cryptography API 的一节。事情是这样的，
受保护的文档交换： Web 应用程序可能希望限制以下文档的查看率 包含敏感或个人信息，即使这些文件 已被安全接收，例如通过 TLS。
使用 Web Cryptography API，应用程序可以通过 使用密钥加密文档，然后包装该密钥 使用与授权查看器相关联的公钥。当一个 用户代理导航到这样的 Web 应用程序，该应用程序将 发送文件的加密形式。然后用户代理是 指示使用用户的私钥解开加密密钥， 然后解密并显示文档。
我想知道，为什么要先用秘密密钥加密文档，然后用用户的公钥包装秘密密钥的双重步骤？不只是用用户的公钥加密文档并发送足够多吗？或者，这样做是否只是为了获得不必为每个用户单独加密文档的性能优势？
与对称密码系统相比，公钥密码系统速度较慢。因此我们更喜欢 the hybrid approach;与公钥密码系统和数据的密钥交换使用交换的密钥进行加密。这里有一些方法；
使用 Diffie-Hellman 密钥交换 (DHKE) 来派生会话密钥。使用像 HKDF 这样的 KDF 来派生所需的密钥，并使用具有良好操作模式的对称算法进行加密，例如 AES-GCM 和 ChaCha20-1204（均在 TLS 1.3 中）。
有了这个，您将拥有 DHKE 的前向保密性以及 AES-GCM 和 ChaCha20-Poly1305 的机密性、完整性和身份验证。
最好使用椭圆曲线版本的DHKE命名ECDH。
使用 RSA-KEM 进行密钥封装。取模数范围内的一个随机数，再次使用HKDF导出密钥，再次使用AES-GCM或ChaCha20-Poly1305加密，用RSA加密发送密钥，密文一起发送。
这是密钥封装机制 (KEM) 和数据封装机制 (DEM) 的要点。