企业官网建设流程全解析

1. 项目概述：为什么要在浏览器里搞端到端加密？

最近几年，数据泄露事件层出不穷，大家对自己的聊天记录、文件传输越来越不放心。传统的网络应用，数据从你的浏览器发到服务器，再从服务器发到对方，这中间的链路，服务端是能“看见”明文的。这意味着，理论上，服务提供方、甚至是攻破了服务器的攻击者，都能获取你的隐私内容。端到端加密就是为了解决这个问题：让数据在发送方加密，只有接收方才能解密，中间的服务器、网络链路拿到的只是一堆无法解读的乱码。

你可能听说过 Signal、WhatsApp 这些通讯软件用了端到端加密，但它们多是原生应用。而在 Web 领域，我们以前会觉得这很难实现，毕竟 JavaScript 运行在不受控的浏览器环境里。但现在情况不同了，现代浏览器普遍支持了Web Crypto API，这是一个划时代的原生接口，让我们能在前端直接进行高性能的加密解密操作，而无需依赖任何第三方插件或服务器中转密钥。

这个项目，就是要利用 Web Crypto API，在纯浏览器环境里，搭建一套完整的、可实操的端到端加密通信方案。它不只是一个概念演示，我会带你从密钥生成、交换、到消息的加密、解密、完整性验证，一步步实现，并分享在实际编码中踩过的坑和必须注意的安全细节。无论你是想为自己的在线协作工具增加隐私保护，还是好奇现代 Web 安全的前沿实现，这篇文章都能给你一套可以直接“抄作业”的代码和清晰的设计思路。

2. 核心设计：一套完整的端到端加密通信方案拆解

在动手写代码之前，我们必须把整个方案的骨架和设计思路理清楚。端到端加密不是简单调用一个encrypt函数，它是一套包含密钥管理、协商、协议设计的系统工程。

2.1 方案架构与协议选型

我们的目标是实现两个浏览器客户端之间的安全通信。假设有一个服务端，但它只负责转发加密后的消息（密文），而绝不接触任何解密密钥或明文。整个架构可以概括为：

1. 客户端 A和客户端 B各自在本地生成非对称密钥对（公钥和私钥）。
2. 双方通过一个可信的、或至少是可验证的渠道交换公钥。在实际项目中，这个渠道通常是通过服务端数据库存储并分发公钥，但核心是服务端不参与密钥生成。
3. A想给B发消息时，使用B 的公钥加密一个临时生成的对称密钥（会话密钥），再用这个会话密钥加密实际的消息内容。最后，将加密后的会话密钥和加密后的消息（密文）一起发送出去。
4. B收到后，先用自己的私钥解密出会话密钥，再用会话密钥解密出原始消息。

这里涉及两个关键的密码学概念：非对称加密和对称加密。非对称加密（如 RSA-OAEP, ECDH）用于安全地交换密钥，因为它用公钥加密的数据只能用对应的私钥解密，非常适合在不安全信道传递秘密。但它的计算开销大，不适合加密大量数据。对称加密（如 AES-GCM）速度快，适合加密实际的消息体，但前提是双方必须拥有同一个密钥。因此，常见的模式是“非对称加密传递对称密钥，对称加密处理业务数据”。

为什么选择AES-GCM作为对称加密算法？因为它同时提供了加密和认证功能。GCM 模式会在加密的同时生成一个认证标签，在解密时验证密文是否被篡改，这比单纯的加密模式（如 CBC）更安全、更高效。对于非对称加密，我们将使用RSA-OAEP用于密钥封装，因为它能抵抗选择密文攻击，是目前 Web Crypto API 中推荐的 RSA 加密模式。

2.2 密钥生命周期管理

密钥管理是安全系统的基石，也是最容易出错的地方。在我们的方案中，主要管理两类密钥：

1. 长期身份密钥对：每个用户客户端在初始化时生成一次并持久化存储。公钥上传到服务器供他人获取，私钥必须绝对保密地存储在客户端本地。私钥绝不能以任何形式发送到网络或服务器。
2. 临时会话密钥：每次发起新会话（或定期）时动态生成，用于加密本次通信的实际数据。使用完毕后即丢弃，实现前向保密——即使长期私钥未来泄露，过去的通信记录也无法被解密。

在浏览器端，我们使用crypto.subtle.generateKey来生成这些密钥。对于长期密钥，我们需要将其导出为某种格式（如jwk或spki/pkcs8）并安全存储。这里强烈建议使用浏览器的IndexedDB进行存储，而不是localStorage。localStorage是同步的，且存储空间有限，更重要的是它容易被同源下的 XSS 攻击窃取。而IndexedDB是异步的，容量更大，并且可以配合CryptoKey对象的非提取性属性，让密钥更安全地留在浏览器的加密上下文中。

注意：Web Crypto API 生成的CryptoKey对象本身是不透明的，你不能直接读取它的密钥材料。当你选择“导出”密钥时，务必使用crypto.subtle.exportKey()方法，并谨慎选择导出格式。导出后的密钥材料（如 JWK 字符串）就变成了明文秘密，存储时必须格外小心。

3. 实战演练：使用 Web Crypto API 一步步实现核心功能

理论讲完了，我们进入实战环节。我会用具体的代码示例展示每一个关键步骤，并解释每个参数的意义和选择它的原因。

3.1 环境准备与密钥生成

首先，确保你的页面通过HTTPS协议提供服务，或者在localhost本地开发。这是 Web Crypto APIcrypto.subtle能够使用的强制安全上下文要求。

第一步：生成用户的长期 RSA 密钥对。

async function generateUserKeyPair() { try { const keyPair = await window.crypto.subtle.generateKey( { name: "RSA-OAEP", modulusLength: 2048, // 密钥长度，2048位是当前安全的最低要求，4096更安全但更慢 publicExponent: new Uint8Array([0x01, 0x00, 0x01]), // 公共指数，通常就是65537 hash: "SHA-256", // 与OAEP填充方案配套使用的哈希函数 }, true, // 是否可导出。这里设为true，因为我们需要导出公钥进行交换。 ["encrypt", "decrypt"] // 密钥用途：公钥加密，私钥解密 ); console.log("RSA密钥对生成成功"); return keyPair; } catch (err) { console.error("生成RSA密钥对失败:", err); throw err; } }

这段代码生成了一个 2048 位的 RSA 密钥对。modulusLength是关键参数，直接关系到安全性。虽然 1024 位已被认为不安全，但 2048 位目前仍是主流。如果你需要更高的安全级别，可以考虑 4096 位，但请注意加解密性能会显著下降。

第二步：导出并存储公钥。生成密钥对后，我们需要将公钥导出为一种可以传输的格式（如 JWK 或 SPKI），发送到服务器。

async function exportPublicKey(publicKey) { const exported = await window.crypto.subtle.exportKey( "jwk", // 导出格式：JSON Web Key，易于JSON传输 publicKey ); // 删除 JWK 中的敏感字段（私钥才有），仅保留公钥部分 const publicKeyJwk = { kty: exported.kty, n: exported.n, e: exported.e, alg: exported.alg, ext: exported.ext, }; return publicKeyJwk; } // 假设我们将 publicKeyJwk 这个 JSON 对象发送到服务器保存

第三步：安全保存私钥。私钥绝不能离开客户端。我们将其导出为pkcs8格式或保持为CryptoKey对象，存入 IndexedDB。

async function savePrivateKeyToIndexedDB(privateKey, userId) { // 首先，将私钥导出为可存储的格式（这里用jwk示例，实际存储可加密） const exportedPrivateKey = await window.crypto.subtle.exportKey("jwk", privateKey); // 打开 IndexedDB 数据库 const request = indexedDB.open("E2EEncryptionDB", 1); request.onupgradeneeded = (event) => { const db = event.target.result; if (!db.objectStoreNames.contains("keys")) { db.createObjectStore("keys", { keyPath: "id" }); } }; request.onsuccess = (event) => { const db = event.target.result; const transaction = db.transaction("keys", "readwrite"); const store = transaction.objectStore("keys"); store.put({ id: `privateKey_${userId}`, key: exportedPrivateKey }); }; }

实操心得：在实际产品中，直接存储导出的 JWK 格式私钥仍然有风险。更安全的做法是，使用一个由用户密码派生的密钥（通过 PBKDF2）对导出的私钥材料进行二次加密，然后再存储。这样即使数据库泄露，攻击者没有用户密码也无法解密私钥。

3.2 会话建立与密钥交换

当用户 A 想要和用户 B 开始安全聊天时，需要建立一个共享的会话密钥。我们采用混合加密方式：

1. A 生成一个随机的 AES 会话密钥。
2. A 获取 B 的公钥（从服务器），并用它加密这个会话密钥。
3. A 将加密后的会话密钥发送给 B。
4. B 用自己的私钥解密，得到会话密钥。

第一步：生成 AES-GCM 会话密钥。

async function generateSessionKey() { return await window.crypto.subtle.generateKey( { name: "AES-GCM", length: 256, // AES-256，提供足够的安全强度 }, true, // 可导出，方便后续封装传输 ["encrypt", "decrypt"] // 用于加密和解密数据 ); }

第二步：使用 RSA-OAEP 封装（加密）会话密钥。假设我们已经从服务器拿到了 B 的公钥 JWK 对象bPublicKeyJwk，并已将其导入为CryptoKey对象bPublicKey。

async function encryptSessionKey(sessionKey, recipientPublicKey) { // 首先导出会话密钥的原始材料 const rawSessionKey = await window.crypto.subtle.exportKey("raw", sessionKey); // 使用接收方的公钥加密这个原始密钥材料 const encryptedKey = await window.crypto.subtle.encrypt( { name: "RSA-OAEP", }, recipientPublicKey, // B的公钥 rawSessionKey // 待加密的会话密钥材料 ); // encryptedKey 是一个 ArrayBuffer，需要转换为可传输的格式，如 Base64 return arrayBufferToBase64(encryptedKey); } // ArrayBuffer 转 Base64 的工具函数 function arrayBufferToBase64(buffer) { const bytes = new Uint8Array(buffer); let binary = ''; for (let i = 0; i < bytes.byteLength; i++) { binary += String.fromCharCode(bytes[i]); } return window.btoa(binary); }

第三步：B 端解密会话密钥。B 收到加密的会话密钥后，用自己的私钥解密。

async function decryptSessionKey(encryptedKeyBase64, myPrivateKey) { // 将 Base64 字符串转换回 ArrayBuffer const encryptedKeyBuffer = base64ToArrayBuffer(encryptedKeyBase64); // 使用自己的私钥解密 const rawSessionKey = await window.crypto.subtle.decrypt( { name: "RSA-OAEP", }, myPrivateKey, encryptedKeyBuffer ); // 将解密出的原始密钥材料导入为 CryptoKey 对象 return await window.crypto.subtle.importKey( "raw", rawSessionKey, { name: "AES-GCM", length: 256, }, true, ["encrypt", "decrypt"] ); } // Base64 转 ArrayBuffer 的工具函数 function base64ToArrayBuffer(base64) { const binaryString = window.atob(base64); const len = binaryString.length; const bytes = new Uint8Array(len); for (let i = 0; i < len; i++) { bytes[i] = binaryString.charCodeAt(i); } return bytes.buffer; }

至此，双方已经安全地共享了一个只有他们俩知道的 AES 会话密钥。这个密钥将用于后续所有消息的加密和解密。

3.3 消息的加密、传输与解密

有了共享的会话密钥，加密和解密消息就相对直接了。这里的关键是正确使用 AES-GCM 的初始化向量（IV）和认证。

加密一条文本消息：

async function encryptMessage(message, sessionKey) { // 1. 将文本编码为 Uint8Array const encoder = new TextEncoder(); const data = encoder.encode(message); // 2. 生成一个随机的 12 字节初始化向量 (IV)。对于 GCM 模式，每次加密都必须使用新的 IV，且绝对不能重复使用。 const iv = window.crypto.getRandomValues(new Uint8Array(12)); // 3. 执行加密 const encryptedContent = await window.crypto.subtle.encrypt( { name: "AES-GCM", iv: iv, // 传入 IV // 可以添加 additionalData（可选），用于认证但不加密的数据 // additionalData: encoder.encode("metadata"), }, sessionKey, data ); // 4. 将 IV 和加密后的密文组合在一起进行传输 // IV 本身不是秘密，可以明文传输，但必须和密文一起送达接收方。 const combined = new Uint8Array(iv.length + encryptedContent.byteLength); combined.set(iv, 0); combined.set(new Uint8Array(encryptedContent), iv.length); return arrayBufferToBase64(combined.buffer); }

重要安全提示：AES-GCM 的 IV 绝对不能重复使用！如果使用同一个(key, IV)组合加密两条不同的消息，会严重破坏安全性，可能导致密钥泄露。因此，每次加密都必须使用密码学安全的随机数生成器（如crypto.getRandomValues）生成全新的 IV。

解密消息：接收方收到 Base64 编码的组合数据后，需要先分离出 IV 和密文，然后解密。

async function decryptMessage(encryptedCombinedBase64, sessionKey) { // 1. 解码 Base64，得到组合的 ArrayBuffer const combinedBuffer = base64ToArrayBuffer(encryptedCombinedBase64); const combined = new Uint8Array(combinedBuffer); // 2. 分离 IV（前12字节）和密文 const iv = combined.slice(0, 12); const ciphertext = combined.slice(12); // 3. 执行解密 try { const decryptedData = await window.crypto.subtle.decrypt( { name: "AES-GCM", iv: iv, // 如果加密时有 additionalData，这里必须提供完全相同的值，否则解密会失败 // additionalData: encoder.encode("metadata"), }, sessionKey, ciphertext ); // 4. 将解密后的 ArrayBuffer 解码为文本 const decoder = new TextDecoder(); return decoder.decode(decryptedData); } catch (error) { console.error("解密失败:", error); // 解密失败可能原因：密钥错误、IV错误、密文被篡改、additionalData不匹配。 throw new Error("消息解密失败，可能已被篡改或密钥不正确。"); } }

AES-GCM 的解密过程同时完成了完整性验证。如果密文或 IV 在传输过程中被修改了一丁点，decrypt操作就会抛出异常。这为我们提供了消息认证，确保收到的消息就是对方发送的原始消息。

4. 系统集成与通信协议设计

现在我们已经有了所有密码学原语，需要将它们组装成一个可工作的通信系统。这涉及到客户端-服务端的交互协议设计。

4.1 消息信封格式设计

我们需要定义一种数据结构，来包裹加密后的消息以及必要的元数据，以便接收方能正确处理。一个典型的端到端加密消息信封可能包含以下字段：

{ "senderId": "user_a", "recipientId": "user_b", "timestamp": 1627891234567, "type": "session_init", // 或 "message" "payload": { "encryptedSessionKey": "Base64EncodedString...", // 仅type为session_init时需要 "encryptedMessage": "Base64EncodedString...", "algorithm": "AES-GCM", "keyEncryptionAlgorithm": "RSA-OAEP" } }

• type: "session_init"：表示这是一条初始化消息，其payload.encryptedSessionKey包含了用接收方公钥加密的 AES 会话密钥。接收方处理此类消息后，会在本地保存这个会话密钥，用于后续解密type: "message"的消息。
• type: "message"：表示这是一条常规聊天消息。接收方使用已协商好的会话密钥来解密payload.encryptedMessage。

服务端的角色非常“笨”，它只负责：

1. 验证用户身份（通过常规的登录 Token）。
2. 接收消息信封，根据recipientId将其存入对应收件人的消息队列或直接推送。
3. 不解析、不查看payload内的任何加密内容。

4.2 客户端状态管理与会话恢复

在实际聊天中，用户可能刷新页面或重新打开浏览器。我们需要设计会话恢复机制。

1. 长期密钥的持久化：用户的 RSA 私钥必须持久化存储在 IndexedDB 中，并在应用启动时尝试加载。
2. 会话密钥的缓存：与每个联系人的当前会话密钥可以临时存储在内存或sessionStorage中。页面刷新后，会话密钥丢失，需要重新发起session_init流程。为了改善体验，可以考虑将会话密钥也加密后存入 IndexedDB（用用户的主密钥加密），但这增加了复杂性。
3. 消息顺序与重放攻击：简单的实现可能无法抵御消息重放攻击。可以在消息信封中加入一个递增的序列号或使用时间戳，并在接收方进行校验，拒绝处理已经处理过或时间戳过旧的消息。

一个简单的会话管理逻辑示例：

class SecureMessenger { constructor(userId) { this.userId = userId; this.privateKey = null; this.sessionKeys = new Map(); // 联系人ID -> 会话密钥 } async initialize() { // 1. 尝试从 IndexedDB 加载私钥 this.privateKey = await this.loadPrivateKeyFromDB(); if (!this.privateKey) { // 2. 如果没有，则生成新的密钥对并保存 const keyPair = await generateUserKeyPair(); this.privateKey = keyPair.privateKey; await this.saveKeyPairToDB(keyPair); // 3. 上传公钥到服务器 const publicKeyJwk = await exportPublicKey(keyPair.publicKey); await api.uploadPublicKey(this.userId, publicKeyJwk); } } async startSessionWith(contactId) { // 1. 从服务器获取联系人的公钥 const contactPublicKeyJwk = await api.fetchPublicKey(contactId); const contactPublicKey = await importPublicKey(contactPublicKeyJwk); // 2. 生成新的会话密钥 const sessionKey = await generateSessionKey(); // 3. 用联系人的公钥加密会话密钥 const encryptedSessionKey = await encryptSessionKey(sessionKey, contactPublicKey); // 4. 构建 session_init 信封并发送 const envelope = { senderId: this.userId, recipientId: contactId, timestamp: Date.now(), type: "session_init", payload: { encryptedSessionKey: encryptedSessionKey, algorithm: "AES-GCM", keyEncryptionAlgorithm: "RSA-OAEP" } }; await api.sendMessage(envelope); // 5. 本地保存会话密钥 this.sessionKeys.set(contactId, sessionKey); console.log(`与 ${contactId} 的会话已初始化`); } async sendMessage(contactId, text) { const sessionKey = this.sessionKeys.get(contactId); if (!sessionKey) { throw new Error(`未找到与 ${contactId} 的会话密钥，请先初始化会话。`); } const encryptedMessage = await encryptMessage(text, sessionKey); const envelope = { senderId: this.userId, recipientId: contactId, timestamp: Date.now(), type: "message", payload: { encryptedMessage: encryptedMessage, algorithm: "AES-GCM" } }; await api.sendMessage(envelope); } async receiveMessage(envelope) { if (envelope.recipientId !== this.userId) return; switch (envelope.type) { case "session_init": // 用自己的私钥解密会话密钥 const sessionKey = await decryptSessionKey( envelope.payload.encryptedSessionKey, this.privateKey ); this.sessionKeys.set(envelope.senderId, sessionKey); console.log(`收到来自 ${envelope.senderId} 的会话初始化，密钥已保存。`); break; case "message": const sessionKeyForSender = this.sessionKeys.get(envelope.senderId); if (!sessionKeyForSender) { console.warn(`收到来自 ${envelope.senderId} 的消息，但无会话密钥。可能需要请求重发session_init。`); return; } try { const decryptedText = await decryptMessage( envelope.payload.encryptedMessage, sessionKeyForSender ); console.log(`来自 ${envelope.senderId} 的消息:`, decryptedText); // 触发UI更新... } catch (e) { console.error(`解密来自 ${envelope.senderId} 的消息失败:`, e); } break; } } }

5. 安全考量、常见陷阱与进阶优化

实现基本功能只是第一步，要构建一个真正安全的系统，必须深入考虑以下问题。

5.1 关键安全威胁与防御

1. 中间人攻击（MITM）：我们的方案假设公钥交换渠道是可信的。如果攻击者在用户 A 获取 B 的公钥时，用自己的公钥替换了 B 的公钥，那么他就能解密所有发给 B 的消息。防御方法：引入公钥指纹验证。在交换公钥后，双方通过另一个可信渠道（例如，已经在使用的、经过验证的通讯方式）比对公钥的指纹（如 SHA-256 哈希值）。许多安全通讯应用都采用这种方式，比如显示一串可读的单词或二维码让用户手动比对。

2. 前向保密（Forward Secrecy）：我们当前的方案，如果用户的长期 RSA 私钥泄露，攻击者可以用它解密所有之前截获的、用对应公钥加密的会话密钥，从而解密所有历史消息。优化方案：采用基于椭圆曲线的迪菲-赫尔曼密钥交换（ECDH）。每次会话时，双方临时生成一对 ECDH 密钥，交换公钥，然后通过对方的公钥和自己的私钥计算出一个共享秘密，再从中派生会话密钥。会话结束后，临时私钥立即销毁。这样，即使长期身份密钥泄露，过去的会话密钥也无法恢复。Web Crypto API 完全支持ECDH算法。

3. 密钥存储安全：如前所述，浏览器端的密钥存储是薄弱环节。XSS 攻击可以读取localStorage甚至可能窃取 IndexedDB 中的数据。最佳实践：

   • 使用HttpOnly、Secure、SameSite的 Cookie 来防御 XSS 窃取身份令牌。
   • 考虑使用Web Workers在独立线程中处理密钥操作，减少主线程被 XSS 攻击后直接访问密钥的风险。
   • 对于极高安全要求的场景，可以引导用户使用硬件安全模块（HSM）或平台提供的安全 enclave，但这在 Web 端支持有限。

5.2 性能优化与兼容性

1. 非对称加密的性能：RSA 2048 位加密解密在移动设备上可能成为性能瓶颈，尤其是频繁发送消息时。优化：

   • 会话建立后，应复用会话密钥一段时间（例如一小时），而不是每条消息都重新协商。
   • 考虑使用 ECDSA 进行签名和 ECDH 进行密钥交换，椭圆曲线算法在相同安全强度下比 RSA 速度快、密钥短。Web Crypto API 支持P-256（secp256r1）、P-384等曲线。

2. 兼容性：Web Crypto API 的crypto.subtle接口在现代浏览器中得到了广泛支持（Chrome 37+, Firefox 34+, Safari 11+）。但对于旧版浏览器或某些特殊环境，需要有降级方案或提示用户升级。务必在使用前进行特性检测：

   if (!window.crypto || !window.crypto.subtle) { alert("您的浏览器不支持 Web Crypto API，无法使用端到端加密功能。请使用 Chrome、Firefox、Safari 或 Edge 的最新版本。"); // 或者回退到不加密的通信模式（不推荐） }

3. 数据序列化：Web Crypto API 操作的数据多是ArrayBuffer。在与 JSON 格式的 API 交互时，需要频繁进行 Base64 或 Hex 编码转换。选择一种高效的编码库（如atob/btoa或Uint8Array转换）很重要，避免成为性能热点。

5.3 调试与问题排查实录

在实际开发中，你几乎一定会遇到各种错误。以下是一些常见问题及排查思路：

一个真实的踩坑记录：我曾遇到一个诡异的问题，在 Chrome 上一切正常，但在某版本 Firefox 上解密总是失败。最后发现，是因为在将 IV 和密文拼接成Uint8Array时，我错误地使用了ArrayBuffer的切片，导致内存视图错位。解决方案是统一使用Uint8Array进行操作，并在转换时格外小心ArrayBuffer和Uint8Array的差异。这提醒我们，涉及二进制数据操作时，务必在不同浏览器上进行测试。

6. 总结与展望

走完这一整套流程，你会发现，利用 Web Crypto API 在浏览器中实现端到端加密，虽然在细节上颇为繁琐，但路径是清晰可行的。我们从最基础的密钥生成、导出导入开始，到完成非对称加密交换对称密钥，再到使用 AES-GCM 对消息进行加密和认证，最后将这些模块整合成一个有状态、可管理的通信客户端。

这套方案的核心优势在于其“纯粹性”——所有加密解密操作都在用户浏览器内完成，服务端沦为纯粹的“哑管道”，从根本上消除了服务端数据泄露的风险。这对于构建需要高度隐私保护的 Web 应用，如在线医疗咨询、秘密投票、企业机密通信等场景，提供了强大的原生技术支撑。

当然，本文实现的还是一个简化模型。一个生产级的系统还需要考虑更多：如何优雅地处理用户设备丢失或密钥丢失后的恢复？如何实现群组聊天的端到端加密？如何将消息签名（用于不可否认性）也集成进来？这些都可以在现有基础上进行扩展。例如，集成Ed25519算法进行数字签名，使用X3DH协议改进双轨密钥交换等。

我个人在实现这类系统时最深的体会是：密码学工具是精密的乐高积木，但如何将它们正确、牢固地拼接在一起，才是安全工程真正的挑战。一个微小的失误，比如 IV 重用、错误的密钥用途设置，都可能让整个安全大厦轰然倒塌。因此，在编写每一行密码学相关代码时，都要抱有敬畏之心，充分测试，并尽可能参考和遵循像 Signal 协议这样的、经过时间检验的成熟设计。

最后，再分享一个小技巧：在开发调试阶段，可以尝试使用window.crypto.subtle的wrapKey和unwrapKey方法。它们可以模拟“加密一个密钥”的过程，并且能直接输出和输入CryptoKey对象，有时比手动处理exportKey->encrypt->decrypt->importKey的流程更直观，有助于你理解密钥封装的概念。但请注意，它们底层使用的仍然是本文介绍的这些加密原语。