1. 项目缘起为什么要在浏览器里搞RSA加密最近在做一个前后端分离的项目涉及到用户登录凭证的安全传输。大家都知道密码这种敏感信息如果明文在网络上裸奔那跟把银行卡密码写在明信片上寄出去没啥区别。最开始我们用的是常见的AES对称加密前端生成个密钥加密后传给后端后端再用同样的密钥解密。这方案听起来没问题但实操起来有个死结密钥怎么安全地传给后端你总不能在代码里把密钥写死吧那跟明文也没差多少了。这时候非对称加密RSA的价值就凸显出来了。它的核心思想是“公钥加密私钥解密”。前端可以光明正大地拿着后端给的公钥这玩意儿不怕泄露去加密数据而只有持有私钥的后端才能解开。这样一来密钥分发这个老大难问题就迎刃而解了。那么问题来了RSA算法计算复杂通常是在服务端比如Node.js用crypto模块来跑。但我们的需求是在用户的浏览器里完成加密总不能为了加密个密码就让用户下载个客户端吧这就需要找一个能在浏览器环境里稳定运行的RSA加密库。找了一圈JSEncrypt这个库进入了视野。它纯用JavaScript实现不依赖任何本地模块一个script标签或者一个npm包就能引入完美契合在浏览器端进行非对称加密的场景。简单说JSEncrypt就是为Web前端量身定制的RSA工具包。当你需要在不信任的客户端环境中向可信的服务端安全地传递敏感信息时它就是你该掏出来的那把锁。2. JSEncrypt的核心机制与典型应用场景拆解2.1 非对称加密RSA一把锁配两把钥匙在深入JSEncrypt之前得先掰扯清楚RSA到底是怎么一回事。你可以把它想象成一种特殊的密码锁但这把锁配了两把不同的钥匙一把叫公钥可以复制无数份发给任何人另一把叫私钥只有锁的主人自己藏着。它的工作流程非常直观任何人想给你寄送机密信件就用你公开派发的公钥这把钥匙把信件锁进保险箱。这个被公钥锁死的保险箱在传输途中即使被截获别人也打不开因为他们没有对应的私钥。保险箱安全送到你手上后你用自己独一无二的私钥才能打开箱子读到里面的原始信件。这个过程的关键在于用公钥加密的内容只能用对应的私钥解密反之亦然。在JSEncrypt的应用里我们通常只利用“公钥加密私钥解密”这一单向流程。服务端生成一对密钥把公钥暴露给前端自己牢牢握紧私钥。前端用公钥加密数据加密后的密文只有服务端的私钥能解从而保证了数据在传输通道上的机密性。2.2 JSEncrypt的适用场景与不适用场景理解了原理我们来看看JSEncrypt最适合在哪些场景下发光发热典型适用场景登录密码加密这是最经典的应用。用户在前端页面输入密码前端用后端下发的RSA公钥加密后再将密文传输给后端验证。全程密码明文不离开浏览器内存网络传输的也是无法破解的密文。关键表单数据加密例如注册时的手机号、身份证号支付时的银行卡CVV码等。对于这些极度敏感且短小的数据使用RSA加密是很好的选择。加密对称密钥在混合加密体系中可以用RSA来加密一个临时生成的、用于后续通信的AES对称密钥。前端用RSA公钥加密这个AES密钥并传给后端后续双方就用这个AES密钥进行快速高效的对称加密通信。不适用或需谨慎使用的场景大文件或长文本加密RSA算法本身非常慢而且有长度限制。比如一个1024位的RSA密钥最多只能加密117字节的原始数据。JSEncrypt也不例外用它加密超过限制的数据会直接报错。所以想用它加密整个文档或图片是行不通的。需要数字签名的场景JSEncrypt虽然名字带“Encrypt”但它主要专注于加密/解密功能。虽然其底层库如Tom Wu的RSA库可能支持但JSEncrypt自身对“私钥签名公钥验签”这套流程的API封装并不如加密/解密那么直观和主流。如果需要做身份认证和防篡改即数字签名建议使用更专业的库如node-forge或crypto-js配合RSA。极度追求性能的场景如前所述RSA运算开销大。如果每秒钟有成千上万的加密请求全部放在客户端用JSEncrypt完成可能会对低端设备的用户体验造成影响。需要权衡安全性与性能。注意JSEncrypt解决的是传输过程中的机密性问题即“别人看不到”。它不解决数据到达后端后被存储的安全性问题也不解决请求被重放攻击的问题。完整的方案还需要结合HTTPS、密码加盐哈希存储、Nonce防重放等手段。3. 从零开始在Node.js与浏览器环境中集成JSEncrypt理论说得再多不如动手跑一遍。下面我们分别看在Node.js后端生成密钥以及在浏览器前端使用JSEncrypt的完整流程。3.1 服务端Node.js密钥对的生成与格式化首先我们需要一个Node.js环境来生成RSA密钥对。确保你已经安装了Node.js可以从官网下载安装配置好环境变量。然后新建一个项目目录初始化并安装必要的库。# 创建一个新项目目录 mkdir rsa-demo cd rsa-demo # 初始化npm项目 npm init -y # 安装node-forge库它是一个非常强大的密码学工具库我们将用它来生成密钥 npm install node-forge接下来创建一个名为generateKeys.js的服务端脚本// generateKeys.js const forge require(node-forge); const fs require(fs); // 1. 生成RSA密钥对 // 参数1024表示密钥长度位。长度越长越安全但生成和使用也越慢。 // 生产环境建议至少使用2048位这里为演示使用1024位。 const keys forge.pki.rsa.generateKeyPair({bits: 1024}); // 2. 将密钥对转换为PEM格式 // PEM是一种常见的文本格式用于存储密钥和证书。 const publicKeyPem forge.pki.publicKeyToPem(keys.publicKey); const privateKeyPem forge.pki.privateKeyToPem(keys.privateKey); // 3. 打印到控制台并保存到文件 console.log( 公钥 (Public Key) \n); console.log(publicKeyPem); console.log(\n 私钥 (Private Key) \n); console.log(privateKeyPem); // 可选将密钥保存到文件方便后续使用 fs.writeFileSync(public.pem, publicKeyPem); fs.writeFileSync(private.pem, privateKeyPem); console.log(\n密钥已保存至 public.pem 和 private.pem 文件。); // 4. 提供一个简单的解密函数用于后续验证前端加密结果 function decryptWithPrivateKey(encryptedBase64) { const privateKey forge.pki.privateKeyFromPem(privateKeyPem); // JSEncrypt默认使用PKCS#1 v1.5填充方案进行加密这里需要对应解密 const decrypted privateKey.decrypt(forge.util.decode64(encryptedBase64), RSAES-PKCS1-V1_5); return decrypted; } // 导出解密函数和公钥方便其他模块使用 module.exports { publicKeyPem, decryptWithPrivateKey };运行这个脚本node generateKeys.js。你会在控制台看到两段以-----BEGIN PUBLIC KEY-----和-----BEGIN RSA PRIVATE KEY-----开头的文本这就是你的PEM格式密钥对。请务必妥善保管私钥文件private.pem绝不能泄露或提交到代码仓库。3.2 浏览器端引入JSEncrypt并执行加密前端部分我们有两种常用的引入方式直接通过CDN使用或者通过npm包管理。方式一CDN引入适合快速原型或简单页面在你的HTML文件中直接引入JSEncrypt的CDN链接!DOCTYPE html html langzh-CN head meta charsetUTF-8 titleJSEncrypt 前端RSA加密演示/title !-- 引入 JSEncrypt 库 -- script srchttps://cdnjs.cloudflare.com/ajax/libs/jsencrypt/3.3.2/jsencrypt.min.js/script /head body h2前端RSA加密演示/h2 input typepassword idpasswordInput placeholder请输入密码 button onclickencryptPassword()加密并输出/button p idencryptedResult/p script // 这里填入你从Node.js后端生成并获取的公钥字符串 // 注意需要将PEM格式的公钥内容包含-----BEGIN...和-----END...完整复制过来 const publicKeyPem -----BEGIN PUBLIC KEY----- MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlOJu6TyygqxfWT7Nf1XhJ7Q/6 ...此处是你的公钥内容通常有多行... -----END PUBLIC KEY-----; function encryptPassword() { const password document.getElementById(passwordInput).value; if (!password) { alert(请输入密码); return; } // 创建JSEncrypt实例 const encryptor new JSEncrypt(); // 设置公钥 encryptor.setPublicKey(publicKeyPem); // 执行加密。加密后的结果是Base64编码的字符串。 const encrypted encryptor.encrypt(password); if (encrypted) { document.getElementById(encryptedResult).textContent 加密结果 encrypted; console.log(加密后的密文(Base64), encrypted); // 在实际项目中这里会将encrypted通过Ajax/Fetch发送给后端 } else { alert(加密失败请检查公钥格式或控制台错误。); } } /script /body /html方式二NPM包引入适合Vue/React等现代前端工程在你的前端项目如Vite、Webpack构建的项目中通过npm安装npm install jsencrypt # 或者 yarn add jsencrypt然后在你的组件或模块中使用// 在你的Vue组件或React组件中 import JSEncrypt from jsencrypt; // 同样的公钥 const publicKeyPem -----BEGIN PUBLIC KEY----- ...你的公钥... -----END PUBLIC KEY-----; export function encryptData(data) { const encryptor new JSEncrypt(); encryptor.setPublicKey(publicKeyPem); const encrypted encryptor.encrypt(data); if (!encrypted) { throw new Error(RSA加密失败); } return encrypted; // 返回Base64密文 } // 调用示例 const password mySecretPassword123; const encryptedPassword encryptData(password); console.log(加密结果, encryptedPassword); // 随后可以将 encryptedPassword 通过axios、fetch等发送给后端API3.3 联调验证完成加密-解密闭环前端加密后我们需要验证后端是否能正确解密。修改一下之前的generateKeys.js或者新建一个server.js文件创建一个简单的HTTP服务来模拟后端接口。// server.js const http require(http); const url require(url); const { publicKeyPem, decryptWithPrivateKey } require(./generateKeys.js); const server http.createServer((req, res) { const parsedUrl url.parse(req.url, true); res.setHeader(Content-Type, application/json); // 提供一个接口返回公钥 if (parsedUrl.pathname /api/public-key) { res.end(JSON.stringify({ publicKey: publicKeyPem })); return; } // 提供一个接口接收加密数据并解密 if (parsedUrl.pathname /api/decrypt req.method POST) { let body ; req.on(data, chunk body chunk); req.on(end, () { try { const { encryptedData } JSON.parse(body); if (!encryptedData) { res.statusCode 400; res.end(JSON.stringify({ error: 缺少 encryptedData 参数 })); return; } // 使用私钥解密 const decryptedData decryptWithPrivateKey(encryptedData); console.log(后端解密成功原文是${decryptedData}); res.end(JSON.stringify({ success: true, decryptedData })); } catch (error) { console.error(解密失败, error); res.statusCode 500; res.end(JSON.stringify({ error: 解密失败请检查数据格式或私钥 })); } }); return; } res.statusCode 404; res.end(JSON.stringify({ error: Not Found })); }); server.listen(3000, () { console.log(后端服务运行在 http://localhost:3000); console.log(获取公钥GET /api/public-key); console.log(提交解密POST /api/decrypt (Body: { encryptedData: Base64String })); });运行后端服务node server.js。然后你可以修改前端代码通过Fetch API动态获取公钥并提交加密数据!-- 在前端HTML的script标签内增加以下函数 -- script async function fetchPublicKeyAndEncrypt() { // 1. 动态从后端获取公钥 const keyResponse await fetch(http://localhost:3000/api/public-key); const { publicKey } await keyResponse.json(); const password document.getElementById(passwordInput).value; const encryptor new JSEncrypt(); encryptor.setPublicKey(publicKey); const encrypted encryptor.encrypt(password); if (encrypted) { // 2. 将加密后的数据发送给后端解密 const decryptResponse await fetch(http://localhost:3000/api/decrypt, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ encryptedData: encrypted }) }); const result await decryptResponse.json(); if (result.success) { console.log(后端解密返回的原文, result.decryptedData); alert(加密解密成功后端解密的原文是${result.decryptedData}); } else { alert(解密失败 result.error); } } } // 将按钮的onclick事件改为调用这个新函数 /script通过这个完整的流程你就搭建了一个从前端RSA加密到后端解密验证的迷你系统理解了JSEncrypt在整个数据安全传输链路中的位置和作用。4. 深水区JSEncrypt的配置、局限与实战避坑指南把Demo跑通只是第一步真正在项目里用起来你会遇到各种稀奇古怪的问题。下面这些坑都是我实打实踩过的。4.1 密钥格式PEM里的“门派之争”JSEncrypt主要支持两种PEM格式的密钥PKCS#1和PKCS#8。它们的开头标识不同格式类型私钥起始标识公钥起始标识说明PKCS#1-----BEGIN RSA PRIVATE KEY----------BEGIN RSA PUBLIC KEY-----传统格式JSEncrypt对其支持最稳定。PKCS#8-----BEGIN PRIVATE KEY----------BEGIN PUBLIC KEY-----更通用的格式通常由openssl genpkey命令生成。踩坑实录1格式不匹配导致“setPublicKey/ setPrivateKey”无效最常见的问题就是你兴冲冲地把一个PKCS#8格式的公钥塞给JSEncrypt它却不声不响地失败了encrypt方法返回false控制台也不一定报错。这是因为JSEncrypt内部解析器可能对格式比较挑剔。解决方案统一使用PKCS#1格式在服务端生成密钥时就指定生成PKCS#1格式。使用node-forge时它默认生成的就是PKCS#1所以问题不大。如果你用OpenSSL命令行可以这样生成# 生成PKCS#1格式的私钥传统格式 openssl genrsa -out private_pkcs1.pem 2048 # 从私钥提取PKCS#1格式的公钥 openssl rsa -in private_pkcs1.pem -pubout -out public_pkcs1.pem格式转换如果你拿到的是PKCS#8格式的密钥可以尝试用OpenSSL转换# PKCS#8 转 PKCS#1 (私钥) openssl rsa -in private_pkcs8.pem -out private_pkcs1.pem # 公钥通常无需转换但JSEncrypt对 PKCS#1 格式的公钥兼容性更好实操心得在项目初期就和后端同学约定好使用PKCS#1格式的PEM密钥进行交换能省去后面一大堆兼容性调试的麻烦。拿到密钥后先肉眼检查一下开头和结尾的标识符是否正确。4.2 加密长度限制117字节的“紧箍咒”这是RSA算法本身的限制不是JSEncrypt的bug。对于一个1024位的RSA密钥其能加密的原始数据最大长度是密钥位数/8 - 填充开销。对于PKCS#1 v1.5填充这个开销是11字节所以1024/8 - 11 117字节。对于2048位密钥则是2048/8 - 11 245字节。踩坑实录2加密长字符串时报错“Message too long”当你尝试加密一个超过限制的字符串比如一段JSON或一个长句子时浏览器控制台会抛出错误。解决方案内容压缩对于文本数据先进行压缩例如使用pako库进行gzip压缩再加密压缩后的二进制数据需要先转成Base64字符串。这能有效减少数据体积。混合加密推荐这是处理长数据的标准做法。前端随机生成一个强壮的AES密钥比如32字节的随机字符串。前端用这个AES密钥通过CryptoJS或Web Crypto API加密你的长数据。前端用JSEncrypt和RSA公钥加密上一步生成的AES密钥本身。前端将RSA加密后的AES密钥和AES加密后的长数据密文一起发送给后端。后端用RSA私钥解密出AES密钥再用这个AES密钥解密出原始长数据。 这样做既利用了RSA的安全密钥交换又利用了AES的高效大数据加密。分块加密不推荐将长数据按117字节分块每块单独用RSA加密然后拼接。这种方法效率极低且密文会膨胀很多倍只在极端特殊场景下考虑。4.3 填充方案默认的PKCS#1 v1.5与潜在风险JSEncrypt默认使用并且主要支持的是PKCS#1 v1.5填充方案。这是一种历史悠久的填充方式但它在理论上存在一些选择密文攻击的风险虽然在实际中很难利用。更现代的填充方案是OAEP。踩坑实录3与使用OAEP填充的后端服务无法互通如果你的后端服务比如用JavaCipher.getInstance(RSA/ECB/OAEPWithSHA-256AndMGF1Padding)使用了OAEP填充而前端JSEncrypt默认使用PKCS#1 v1.5那么后端将无法解密前端发来的数据。解决方案与权衡方案A前端改JSEncrypt的encrypt方法可以接受第二个参数用于指定哈希函数但这实际上是为OAEP填充准备的。然而JSEncrypt对OAEP的支持可能不完整或存在兼容性问题。尝试使用encryptor.encrypt(data, SHA-256)可能会在某些版本下工作但这需要和后端严格对齐哈希算法和MGF1参数调试成本高。方案B后端改协调后端使用PKCS#1 v1.5填充。在Node.js的crypto模块中使用crypto.privateDecrypt({ key: privateKey, padding: crypto.constants.RSA_PKCS1_PADDING }, encryptedBuffer)。这是与JSEncrypt兼容性最好的方式。方案C换库如果项目对安全性要求极高必须使用OAEP可以考虑在前端使用其他对OAEP支持更好的库如node-forge的浏览器版本或Web Crypto API。但请注意Web Crypto API是原生浏览器API功能强大但API较为底层且IE兼容性差。个人建议对于绝大多数Web登录、表单提交场景使用JSEncryptPKCS#1 v1.52048位以上密钥的组合安全性已经足够。优先保证前后端的互通性和开发效率。如果安全审计有强制要求再考虑升级到OAEP方案并做好全面的兼容性测试。4.4 性能考量与异常处理性能在浏览器中执行RSA加密是CPU密集型操作。加密一个短字符串如密码感觉不到延迟但如果页面上有大量加密操作或者在低端移动设备上可能会引起界面卡顿。优化建议节流与防抖对频繁触发的事件如输入框实时加密使用防抖。Web Worker将加密操作放到Web Worker中执行避免阻塞主线程。缓存公钥公钥一旦从后端获取就存储在内存或sessionStorage中避免重复请求。健壮的异常处理JSEncrypt.encrypt()方法在失败时会返回false或null而不是抛出异常。因此你的代码必须进行检查。function safeEncrypt(data, publicKey) { const encryptor new JSEncrypt(); encryptor.setPublicKey(publicKey); const encrypted encryptor.encrypt(data); if (encrypted false || encrypted null) { // 加密失败可能的原因 // 1. 公钥格式错误 // 2. 数据超长 // 3. 库加载异常 console.error(JSEncrypt加密失败。请检查); console.error(1. 公钥格式是否正确PEM格式包含头尾标识); console.error(2. 待加密数据是否过长); console.error(3. JSEncrypt库是否成功加载); // 在实际项目中这里应该触发一个用户友好的错误提示并可能降级到非加密提交需结合HTTPS throw new Error(数据加密失败请重试或联系管理员。); } return encrypted; }5. 超越JSEncrypt浏览器端RSA的其他选择与未来虽然JSEncrypt是当前最流行、最易用的前端RSA库但了解其他选项能让你在特定场景下做出更优选择。5.1 Web Crypto API浏览器的原生之力Web Crypto API是现代浏览器提供的原生加密API功能强大性能通常优于纯JavaScript实现的库并且支持OAEP等更安全的填充方案。// 使用 Web Crypto API 进行RSA-OAEP加密 (示例) async function encryptWithWebCrypto(plaintext, publicKeyPem) { // 1. 将PEM格式的公钥转换为CryptoKey对象这是一个复杂的过程需要解析PEM并导入 // 此处省略PEM解析和importKey的详细代码它比JSEncrypt.setPublicKey复杂得多。 // 2. 执行加密 const encoder new TextEncoder(); const data encoder.encode(plaintext); const encrypted await window.crypto.subtle.encrypt( { name: RSA-OAEP, // 可以指定哈希算法如SHA-256 }, publicKeyCryptoKey, // 导入后的CryptoKey对象 data ); // 3. 将ArrayBuffer结果转为Base64 return btoa(String.fromCharCode(...new Uint8Array(encrypted))); }优缺点对比优点原生支持、性能好、支持OAEP、更安全。缺点API复杂尤其是密钥导入、IE浏览器完全不支持、需要处理ArrayBuffer等二进制数据。5.2 node-forge的浏览器版本功能全面的瑞士军刀node-forge是一个功能极其丰富的JavaScript密码学库。它也有浏览器版本通过script标签引入或打包工具引入。script srchttps://cdnjs.cloudflare.com/ajax/libs/node-forge/1.3.1/forge.min.js/script script const publicKey forge.pki.publicKeyFromPem(publicKeyPemString); const encrypted publicKey.encrypt(forge.util.encodeUtf8(plaintext), RSA-OAEP, { md: forge.md.sha256.create() }); const encryptedBase64 forge.util.encode64(encrypted); /script优缺点对比优点功能全面支持RSA、AES、SHA、TLS等、同时支持PKCS#1和OAEP填充、与Node.js后端node-forge完美配对。缺点库体积比JSEncrypt大很多、API也更复杂。5.3 如何选择场景推荐方案理由快速实现前端密码加密JSEncryptAPI极其简单文档丰富社区支持好能满足大部分场景。需要OAEP填充等高安全特性Web Crypto API或node-forgeJSEncrypt对OAEP支持有限。如果必须用且不考虑IE选Web Crypto如果需要兼容性或功能集选node-forge。项目已大量使用node-forgenode-forge保持技术栈统一前后端密钥处理逻辑一致。加密非常频繁注重性能Web Crypto API原生API性能最优。我个人在大多数中后台管理系统、登录注册场景中依然首选JSEncrypt。它的简单可靠经过了无数项目的验证。只有当安全规范明确要求OAEP或者需要处理更复杂的密码学操作时我才会考虑引入node-forge或深入研究Web Crypto API。最后记住一点前端加密只是安全链条中的一环。务必全程使用HTTPS防止中间人攻击替换你的公钥或窃听密文。同时后端在解密后对密码等敏感信息的存储一定要使用加盐哈希如bcrypt、scrypt、Argon2切勿可逆存储。