JavaScript怎么实现RSA非对称加密传输

前端通过 JavaScript 实现 RSA 非对称加密传输的核心逻辑是：由业务服务端生成公私钥对并将公钥下发至浏览器，前端使用该公钥对敏感明文（如登录密码、身份证号或对称密钥）执行加密运算并编码为 Base64 字符串，随 HTTP 请求提交给后端；由于公钥仅具备加密能力，数据在公网传输过程中即使被拦截也无法倒推还原，最终只能由持有私钥的服务端在受保护的内存环境中解密出明文。在实现上，现代浏览器优先推荐使用原生的 window.crypto.subtle（Web Crypto API），老旧项目或特定兼容场景则可选用轻量库 jsencrypt。

全景概览：客户端公钥加密、公网密文传输与服务端私钥解密的完整链路架构

一、RSA 非对称加密传输的核心机制

对称加密（如 AES、DES）在前后端通信中存在天然的“密钥分发困境”：如果前端使用固定的密钥加密，密钥就必须打包在 JavaScript 源码中，攻击者通过浏览器开发者工具或反编译即可轻松窃取密钥并解密所有通信内容；而动态协商对称密钥的过程本身如果未受保护，同样容易被中间人嗅探。

RSA 非对称加密通过数学上的陷门单向函数（大素数乘积分解难题）彻底分化了加密与解密权限。公钥（Public Key）与私钥（Private Key）成对生成：

• 公钥完全公开：公钥可以无条件提供给前端页面、公开接口或第三方终端，其唯一用途是对明文进行单向数学变换。任何人获得公钥都只能加密，无法利用公钥执行逆运算。
• 私钥物理隔离：私钥始终存放在后端服务器的安全环境（如 KMS 或进程环境变量）中，严禁下发给客户端，专门用于对收到的密文进行解密还原。
• 传输防窃听：数据在客户端加密完成后变为随机分布的无序字节串，即使通信链路经过不可信代理或公共 Wi-Fi，监听者获得密文也无法获知密码或明文信息。

图1：RSA非对称加密传输体系结构与密钥交互时序

二、方案一：使用原生 Web Crypto API 实现（无依赖推荐）

W3C 标准的 Web Crypto API（挂载在 window.crypto.subtle 上）在现代浏览器中均已原生内置。与社区第三方 JavaScript 纯算法实现相比，Web Crypto 具备以下显著优势：

• 硬件加速与高执行效率：加密计算由浏览器底层的 C++ 原生引擎及操作系统安全模块执行，性能比纯 JS 大数运算快数倍至数十倍。
• 零外部包安全风险：不需要通过 npm 安装任何外部第三方库，彻底避免了供应链投毒、代码体积冗余以及版本维护风险。
• 原生支持工业级填充：直接支持抗选择密文攻击的 RSA-OAEP 填充模式，默认搭配 SHA-256 哈希。

图2：Web Crypto API 密钥导入与数据加密步骤流水线

1. 辅助函数：PEM 格式转 SPKI ArrayBuffer

服务端生成的 RSA 公钥通常为 PEM 文本格式（带有 -----BEGIN PUBLIC KEY----- 标头和换行）。Web Crypto API 的 importKey 接口需要接收原始二进制的 ArrayBuffer，因此需要先进行清洗和 Base64 解码：

/**
 * 将 PEM 格式的公钥字符串转换为 ArrayBuffer (SPKI 二进制)
 * @param {string} pemKey 
 * @returns {ArrayBuffer}
 */
function pemToArrayBuffer(pemKey) {
  // 1. 去除 PEM 标头、标尾与各种换行回车符
  const cleanBase64 = pemKey
    .replace(/-----BEGIN [A-Z ]+-----/g, '')
    .replace(/-----END [A-Z ]+-----/g, '')
    .replace(/\s+/g, '');

  // 2. 将 Base64 还原为原始二进制字符串
  const binaryString = window.atob(cleanBase64);
  const bytes = new Uint8Array(binaryString.length);
  for (let i = 0; i < binaryString.length; i++) {
    bytes[i] = binaryString.charCodeAt(i);
  }
  return bytes.buffer;
}

2. 原生 RSA-OAEP 加密完整封装

以下是可以直接在项目中调用的异步加密函数。该函数导入公钥后，使用 UTF-8 编码明文字符串，执行 RSA-OAEP 算法，并将输出的二进制密文安全编码为可跨 HTTP 请求传输的 Base64 格式：

/**
 * 使用原生 Web Crypto API 实现 RSA-OAEP 公钥加密
 * @param {string} plainText 需要加密的明文敏感数据（如密码）
 * @param {string} pemPublicKey 服务端下发的 PEM 格式 RSA 公钥
 * @returns {Promise<string>} Base64 编码的密文字符串
 */
async function rsaEncryptWithWebCrypto(plainText, pemPublicKey) {
  // 1. 转换公钥为二进制 SPKI Buffer
  const spkiBuffer = pemToArrayBuffer(pemPublicKey);

  // 2. 导入公钥为 Web Crypto Key 实例（采用 RSA-OAEP 与 SHA-256）
  const cryptoKey = await window.crypto.subtle.importKey(
    'spki',
    spkiBuffer,
    {
      name: 'RSA-OAEP',
      hash: { name: 'SHA-256' }
    },
    false,       // 密钥不可导出
    ['encrypt']  // 用途仅限加密
  );

  // 3. 将待加密字符串按 UTF-8 编码为字节数组
  const encoder = new TextEncoder();
  const dataBuffer = encoder.encode(plainText);

  // 4. 调用原生底层执行加密运算
  const cipherBuffer = await window.crypto.subtle.encrypt(
    { name: 'RSA-OAEP' },
    cryptoKey,
    dataBuffer
  );

  // 5. 将密文 ArrayBuffer 转换为 Base64 字符串
  const cipherBytes = new Uint8Array(cipherBuffer);
  let binaryString = '';
  for (let i = 0; i < cipherBytes.length; i++) {
    binaryString += String.fromCharCode(cipherBytes[i]);
  }
  return window.btoa(binaryString);
}

三、方案二：使用 JSEncrypt 库快速对接（兼容方案）

jsencrypt 是前端社区中使用极广的轻量级 RSA 加密库。它内部封装了大数运算并能直接解析标准的 PEM 格式公钥字符串，非常适合需要快速对接、或需要兼容不支持 Web Crypto API 的遗留老旧运行环境（如老旧 WebView、特殊嵌合浏览器等）。

1. 引入方式

在工程化项目中，可以通过 npm 安装；在原生静态页面中，也可以直接引入脚本：

// npm / yarn / pnpm 引入
npm install jsencrypt

// 代码中导入
import JSEncrypt from 'jsencrypt';

2. 加密调用实现代码

/**
 * 使用 JSEncrypt 执行公钥加密
 * @param {string} plainText 待加密明文
 * @param {string} pemPublicKey PEM 格式公钥
 * @returns {string} Base64 密文字符串
 */
function rsaEncryptWithJSEncrypt(plainText, pemPublicKey) {
  const encryptor = new JSEncrypt();
  
  // 设置公钥（JSEncrypt 内部会自动去除头尾和格式化）
  encryptor.setPublicKey(pemPublicKey);

  // 执行加密，内部默认输出即为 Base64 格式字符串
  const encryptedBase64 = encryptor.encrypt(plainText);

  if (!encryptedBase64) {
    throw new Error('RSA 加密失败：明文长度可能超出密钥承载限制或公钥格式不正确。');
  }

  return encryptedBase64;
}

四、核心限制与进阶：明文长度上限与混合加密实现

初学者在前端实现 RSA 加密时最常遭遇的错误就是：“为什么加密一段短密码正常，一旦加密长 JSON 或提交表单就会抛出异常或者返回 false？”

这是由于 RSA 算法的数学原理决定的：RSA 只能加密长度小于其密钥模数长度的数据块。为了抵御统计攻击，每次加密还必须加入特定格式的填充字节（Padding Overhead）。因此，单次加密允许的最大明文字节数由以下数学关系严格确定：

图3：RSA 明文长度硬限制机制与混合加密传输架构对比

工业级方案：RSA + AES 混合加密（Hybrid Encryption）

如果业务需求是加密传输整个用户资料表单、大段富文本或整包 JSON 请求，直接使用 RSA 分段加密不仅代码复杂，且效率极其低下。现代安全通信协议（包括 TLS/HTTPS、PGP）的标准解法均为混合加密（Envelope Encryption / 数字信封模型）：

1. 前端在本地通过密码学安全的随机发生器（crypto.getRandomValues）生成一个全新的 256 位对称密钥（如 AES-GCM Key）和 IV 向量。
2. 前端使用高效的 AES 算法对业务大数据进行加密，产出密文 ciphertext 和认证标签 authTag。AES 具备近乎无限的数据承载能力且计算极快。
3. 前端使用服务端下发的 RSA 公钥，仅对这枚 32 字节长度的 AES 随机密钥执行 RSA-OAEP 加密，生成加密密钥信封 encryptedKey。
4. 将 { encryptedKey, iv, authTag, ciphertext } 打包发给服务端。服务端先用 RSA 私钥解出 32 字节的 AES 密钥，再用该密钥瞬间解开业务数据主体。

五、服务端配套解密与前后端联调示例

为了让加密传输形成闭环，以下提供一个基于 Node.js 原生 crypto 模块的服务端解密验证代码。代码严格对齐现代规范所采用的 RSA-OAEP 填充与 SHA-256 哈希：

// server_decrypt_node.js
const crypto = require('crypto');
const fs = require('fs');

// 1. 读取受保护的私钥文件（严禁暴露至公网）
const privateKeyPem = fs.readFileSync('private_key.pem', 'utf8');

/**
 * 解密来自前端 Web Crypto API 发送的 Base64 密文字符串
 * @param {string} base64Ciphertext 前端传输过来的密文
 * @returns {string} 还原后的原始明文
 */
function decryptClientData(base64Ciphertext) {
  const cipherBuffer = Buffer.from(base64Ciphertext, 'base64');

  // 调用 Node.js 原生底层非对称解密
  const decryptedBuffer = crypto.privateDecrypt(
    {
      key: privateKeyPem,
      padding: crypto.constants.RSA_PKCS1_OAEP_PADDING, // 对齐 RSA-OAEP
      oaepHash: 'sha256'                               // 对齐 SHA-256 哈希
    },
    cipherBuffer
  );

  return decryptedBuffer.toString('utf8');
}

// 联调示例：接收到前端请求体
// const plaintext = decryptClientData(req.body.encryptedPassword);
// console.log('解密成功还原明文：', plaintext);

联调三大高频排错指南

• 报错 ERR_OSSL_RSA_PADDING_CHECK_FAILED： 这是最常见的错误，100% 由前后端填充参数不一致引起。例如前端使用了 jsencrypt（PKCS#1 v1.5），而服务端解密代码配置了 RSA_PKCS1_OAEP_PADDING；或者虽然双方都用了 OAEP，但前端是 SHA-256 而服务端默认采用了 SHA-1。必须确认双方的 padding 和 oaepHash 逐字一致。
• Base64 URL 安全编码截断： 标准 Base64 包含字符 + 和 /。如果在通过 GET 请求 Query 参数传输时未进行 encodeURIComponent()，空格可能会替换掉 + 导致密文损坏。传输密文必须使用 POST 请求体以 JSON 字符串传输。
• 中文乱码或字节截断： 在明文含有中文或 Emoji 时，如果使用 charCodeAt 单字节读取，高位字节会被截断。前端必须使用规范的 new TextEncoder().encode() 产出 UTF-8 二进制流后再进行加密。

图4：JavaScript RSA 加密传输落地要点与安全自查矩阵

六、生产环境安全实施规范与注意事项

将 RSA 加密引入项目工程中时，必须树立正确的纵深防御意识，避免产生“只要加了 RSA 就能高枕无忧”的错误认知。在实际投产前，务必逐项核对以下关键原则：

1. 前端 RSA 不能替代传输层 HTTPS

前端 RSA 加密最大的前提是：前端获取到的公钥必须是真实合法的服务端公钥。如果网站部署在未加密的普通 HTTP 链路上，攻击者可以通过中间人攻击（MITM）在通信链路中劫持并拦截公钥下发请求，将其替换为攻击者自己伪造的公钥；随后前端用伪造的公钥加密，攻击者截获密文后用自己的私钥解密窃取明文，再用真公钥加密发回后端。因此，必须在全局强制开启严格的 HTTPS，利用 TLS 证书链机制防篡改，RSA 则是作为针对内网代理、审计日志脱敏和深层防御的第二道安全锁。

2. 严防重放攻击（Replay Attack）

非对称加密本身只保证了明文内容的保密性，并不天然具备时效性。假设攻击者无法破解密文，但他通过网络抓包录制了用户登录时发送的一串密文 q3A9...xY==，并直接原样重发给后端登录接口，后端如果毫无防备，依旧会顺利解密出正确密码并允许登录。

防御规范：在前端准备加密数据时，不要只加密单纯的密码字符串，应组装包含时效因子的对象：

// 组装业务数据与防重放因子
const payload = JSON.stringify({
  password: userPassword,
  timestamp: Date.now(),                          // 客户端发起毫秒时间戳
  nonce: crypto.randomUUID ? crypto.randomUUID() : Math.random().toString(36).slice(2) // 随机单次串
});

// 执行加密发送
const encryptedBody = await rsaEncryptWithWebCrypto(payload, serverPublicKey);

服务端解密后，首先比对 Math.abs(Date.now() - payload.timestamp) < 60000（只允许 60 秒内的有效请求），并在 Redis 等高速缓存中利用 SETNX 记录 nonce 键名；一旦发现已存在的 nonce 或过期时间戳，立即拒绝服务，从源头彻底杜绝重放风险。

3. 选用合理的落地选型

在技术选型上，如果是现代前端应用（Vue 3、React、Svelte 等现代 SPA 或现代移动端混合应用），优先选用原生的 Web Crypto API，既符合标准规范又拥有最高的硬件加速执行性能；对于单纯的登录密码字段（通常在 16~64 字符以内），直接采用 RSA-OAEP (SHA-256) 单次加密即可；若涉及大批量敏感信息同步或文件载荷，则应无条件采用 RSA + AES-GCM 混合加密 模型，从而在性能与安全性之间取得最优平衡。