前端RSA解密实战：如何改造jsencrypt实现公钥解密（附完整代码）

前端RSA解密实战如何改造jsencrypt实现公钥解密附完整代码最近在做一个与第三方服务集成的项目时遇到了一个挺有意思的挑战。对方系统采用RSA非对称加密但他们的数据流设计有些特殊服务端用私钥加密前端需要用公钥来解密。这和我们通常理解的“公钥加密、私钥解密”模式正好相反。我第一时间想到的是前端常用的jsencrypt库结果一查文档发现它原生并不支持公钥解密。网上相关的完整解决方案不多大多语焉不详。经过一番源码级的探索和调试我成功改造了jsencrypt让它能胜任这个任务。这篇文章我就把整个改造思路、关键步骤、踩过的坑以及完整的代码分享出来希望能帮到遇到类似场景的你。1. 理解RSA与jsencrypt的常规工作流在动手改造之前我们得先理清几个基本概念。RSA是一种非对称加密算法它有一对密钥公钥和私钥。公钥可以公开给任何人私钥则必须严格保密。最常见的两种应用模式是加密与解密用公钥加密数据只有对应的私钥才能解密。这确保了数据的机密性常用于传输敏感信息。签名与验签用私钥对数据生成签名任何人都可以用公钥验证签名。这确保了数据的完整性和来源真实性。jsencrypt这个库在前端社区非常流行它封装了RSA的加密和签名功能让开发者能方便地调用。然而它的API设计主要围绕上述第一种模式公钥加密、私钥解密和第二种模式私钥签名、公钥验签。当你调用encryptor.decrypt(encryptedData)时库内部默认会使用你之前通过setPrivateKey()设置的私钥去执行解密操作。那么问题来了为什么会有“公钥解密”这种需求这通常出现在一些特定的交互协议或遗留系统中。例如某些服务端可能将“私钥加密”作为一种轻量的身份验证或令牌生成机制前端需要持有公钥来验证并解密这个令牌。虽然这不是RSA的标准安全实践因为公钥是公开的任何人都能解密失去了机密性但在某些特定上下文如验证数据确实来自持有私钥的服务端中它确实存在。注意使用“公钥解密”通常不是为了保密而是为了验证数据来源。在考虑采用此方案前请务必评估其安全性和是否符合你的业务场景。为了更清晰地对比常规用法与我们的改造目标可以参考下表操作常规jsencrypt流程本文改造后的目标数据加密使用setPublicKey()设置公钥然后调用encrypt()。保持不变。数据解密使用setPrivateKey()设置私钥然后调用decrypt()。使用setPublicKey()设置公钥然后调用decrypt()。典型场景前端加密数据传给后端后端用私钥解密。后端用私钥加密数据传给前端前端用公钥解密验证。2. 深入jsencrypt源码定位关键方法要实现公钥解密我们不能停留在库的API表面必须深入到它的内部实现。我的方法是先将jsencrypt的源码文件通常是一个单独的jsencrypt.js复制一份到我们项目的工具目录例如/utils/下然后在这个副本上进行修改。打开源码文件我们需要找到两个核心函数RSAKey.prototype.decrypt这是执行解密操作的主入口。pkcs1unpad2这是一个内部工具函数负责在解密后对数据进行“反填充”unpadding。RSA加密在实际操作前会对原始数据进行一种叫做PKCS#1 v1.5的填充以增强安全性。解密后需要去掉这些填充字节才能得到原始数据。让我们先看看decrypt方法的原始样貌。通过搜索你可能会找到类似下面的代码块// 原始 jsencrypt.js 中的 decrypt 方法 (简化示意) RSAKey.prototype.decrypt function (ctext) { var c parseBigInt(ctext, 16); // 关键点这里调用了 doPrivate意味着使用私钥进行解密运算 var m this.doPrivate(c); if (m null) { return null; } // 解密后的数据需要经过反填充处理 return pkcs1unpad2(m, (this.n.bitLength() 7) 3); };代码非常清晰。this.doPrivate(c)是执行RSA解密计算的核心。doPrivate这个方法名已经揭示了它的本质——使用私钥(Private)进行计算。我们的目标就是把它改成使用公钥进行计算的方法即this.doPublic(c)。但是事情并没有这么简单。仅仅修改这一处你很可能会发现解密出来的是一堆乱码或者直接返回null。这是因为doPublic和doPrivate内部处理的数学结构和预期可能不同而后续的pkcs1unpad2函数是专门为doPrivate解密后的数据格式设计的。因此我们还需要调整这个反填充函数。3. 核心改造解密方法与反填充逻辑改造的第一步是直接的将doPrivate替换为doPublic。// 修改后的 decrypt 方法 RSAKey.prototype.decrypt function (ctext) { var c parseBigInt(ctext, 16); // 修改点将 doPrivate 改为 doPublic var m this.doPublic(c); if (m null) { return null; } return pkcs1unpad2(m, (this.n.bitLength() 7) 3); };接下来是重头戏修改pkcs1unpad2函数。原始的pkcs1unpad2函数期望解密后的数据符合PKCS#1 v1.5为私钥解密设计的填充结构通常以0x00 0x02开头。而公钥解密后的数据格式可能有所不同例如可能以0x00 0x01开头代表不同的填充模式或直接没有标准填充。经过调试和分析我发现当使用doPublic进行解密运算后得到的大整数BigInt转换成的字节数组ByteArray其结构可能与doPrivate的结果存在差异。特别是开头的填充标识字节。原始的pkcs1unpad2包含了一段严格的检查// 原始 pkcs1unpad2 中的检查逻辑 if (b.length - i ! n - 1 || b[i] ! 2) { return null; }这段代码检查1) 去掉前导零后的数据长度是否符合预期2) 第一个非零字节是否等于2这是私钥解密填充的标识。对于公钥解密的结果这个检查很可能失败导致函数直接返回null。因此我们需要一个更通用、或者说更“宽容”的反填充逻辑。我们的目标是跳过所有前导零然后一直寻找到分隔符0x00之后的数据就是我们的有效负载明文。同时我们需要正确处理这些有效负载字节将其转换为字符串假设原始数据是字符串。下面是经过修改的pkcs1unpad2函数function pkcs1unpad2(d, n) { var b d.toByteArray(); var i 0; // 跳过所有的前导零字节 while (i b.length b[i] 0) { i; } // **关键修改注释掉或删除原有的严格格式检查** // if (b.length - i ! n - 1 || b[i] ! 2) { // return null; // } // i; // 原逻辑会跳过标识字节例如 0x02 // 直接开始寻找分隔符 0x00 // 注意此时 b[i] 可能是填充内容如 0x01 或 0x02我们不管它直接找0x00 while (b[i] ! 0) { if (i b.length) { return null; // 没找到分隔符数据格式错误 } } // 跳过分隔符 0x00 i; // 从分隔符之后开始将字节解码为UTF-8字符串 var ret ; while (i b.length) { var c b[i] 255; if (c 128) { // ASCII字符 ret String.fromCharCode(c); } else if (c 191 c 224) { // 双字节UTF-8字符 if (i 1 b.length) return null; ret String.fromCharCode(((c 31) 6) | (b[i 1] 63)); i 1; } else { // 三字节UTF-8字符 if (i 2 b.length) return null; ret String.fromCharCode(((c 15) 12) | ((b[i 1] 63) 6) | (b[i 2] 63)); i 2; } i; } return ret; }这个修改后的版本核心思想是不关心具体的填充模式标识符只做最基础的操作——跳过前导零寻找分隔符0x00然后提取并解码后面的有效数据。这种方法的通用性更强能适应公钥解密后可能出现的不同数据格式。4. 实战应用与完整代码示例改造完源码后我们就可以在项目中像使用原版jsencrypt一样使用它了只不过现在它多了一个“公钥解密”的超能力。首先确保你已经将修改后的jsencrypt.js文件放在了项目合适的位置例如src/utils/jsencrypt.js。接下来我们来看一个完整的应用示例。假设后端提供了一个用私钥加密的字符串data以及对应的公钥publicKey。// 在你的业务组件或工具文件中 // 1. 导入我们改造后的 JSEncrypt import JSEncrypt from /utils/jsencrypt; // 注意路径指向你修改后的文件 // 2. 准备数据 // 这是服务端用私钥加密后的数据Base64格式 const encryptedData fGrPg4EOup/nopw4f8XCqNenVsPE2Ujr70TvjDvrfUDFFiYcx7ewLG7tM76x7N0nKiO7/QiWZU0GAEhrMBr4oNmzGCiCnMGeLaPUM0KOnYgN6kimFsMOIerd/25S3qdqj4qED84bTaT7VBni1L3APo8JOKVcWIk4kJPKK1nJUNwsQxJvbrD2nOdrWjRuq3WIftdcEHBiVGycaij8QUrVTKcTmYFjCWwC7JFRQjYv26pmCbq3rs3CT24xazc4CLDkxy98Hmy7zZkVTI675kHpYlZbQfBkiHvLtCHUOEiRDXhGNi9GO2DVTBVnAP173BV2VyFFYj85qeD/Qw; // 这是对应的公钥字符串PEM格式 const publicKey -----BEGIN PUBLIC KEY----- MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3IHVdOJgnqaZGKc9wXJ KUqwI95F/qCvPQoDyf0cDZzebbAGEOs4m7LAQwfa6Aq6cRhBHtDYco6cv7wufmi qJ9U7yVFnvha1wi3jkXn1AxUAvUwbLtrhjZg/akxAukXX7fsOdCPbk8AitlnaH1 2S5Np0Ugxx/rNLOkkxwAOIzu/z1SvGLoPGFDHW/7mna8txs3SwlpG3TDGOXOsEu 4vcXbRKmLApUlrluhny7GTGGVi8TqrmviyrfcAj/098AI5aRzv/Y0TchsJVOtoaz CsHjjp/Cf4RnSuLKyBio7wGlRIyy/ywpMUiae3vJb3qd0Wx8824SbgClTIA1f4 HwIDAQAB -----END PUBLIC KEY-----; // 3. 使用公钥进行解密 const decryptWithPublicKey (encryptedStr, publicKeyStr) { try { const encryptor new JSEncrypt(); // 关键设置的是公钥而非私钥 encryptor.setPublicKey(publicKeyStr); // 调用 decrypt 方法。注意此时内部使用的是我们修改过的、调用 doPublic 的逻辑。 const decryptedText encryptor.decrypt(encryptedStr); return decryptedText; } catch (error) { console.error(公钥解密失败:, error); return null; } }; // 4. 执行解密并查看结果 const result decryptWithPublicKey(encryptedData, publicKey); console.log(解密结果:, result); // 预期输出应该是后端加密前的原始明文字符串这段代码清晰地展示了使用流程初始化一个JSEncrypt实例。使用setPublicKey方法传入公钥。直接调用decrypt方法并传入密文。得到解密后的明文。整个过程和用私钥解密的API调用方式一模一样但背后的逻辑已经被我们彻底改变了。5. 常见问题排查与进阶思考在实际集成过程中你可能会遇到一些问题。这里我总结几个常见的坑和排查思路解密返回null或乱码检查一公钥格式。确保公钥是标准的PEM格式包含正确的-----BEGIN PUBLIC KEY-----和-----END PUBLIC KEY-----头尾并且字符串中的换行符\n正确处理了。很多问题都出在密钥字符串的格式不对或传输过程中格式被破坏。检查二密文格式。确认后端传过来的密文是Base64编码的字符串。jsencrypt的decrypt方法默认期望接收Base64编码的密文。如果后端传的是Hex或其他格式需要先进行转换。检查三填充方案。我们修改的pkcs1unpad2采用了通用策略。但如果后端使用的不是PKCS#1 v1.5填充或者填充方式非常特殊可能需要进一步调整反填充逻辑。可以尝试在while (b[i] ! 0)循环前打印出b数组的内容观察解密后的原始字节结构。性能与数据长度限制RSA算法本身不适合加密大数据。它通常用于加密对称密钥如AES密钥或进行签名。如果你需要解密的数据很大可能需要确认后端是否采用了“RSA加密AES密钥AES加密实际数据”的混合加密模式。前端需要先用RSA公钥解密出AES密钥再用AES密钥解密主体数据。安全性考量再次强调公钥解密的场景通常用于验证而非保密。请与后端同事明确此方案的安全边界。确保私钥的保管绝对安全因为一旦私钥泄露攻击者就可以伪造任何能被公钥解密的数据。替代方案探索如果项目允许引入新库也可以考虑其他支持更灵活操作的RSA库例如node-forge在浏览器中也可用或crypto-js配合Web Crypto API。这些库可能提供更底层的接口让你直接指定使用公钥进行解密操作无需修改源码。但jsencrypt的轻量与普及度仍是其巨大优势。最后把修改好的jsencrypt.js文件妥善保管。你可以将其作为项目的一个定制工具库并在文档中说明其增强的功能。我自己的项目在应用此方案后与第三方服务的令牌验证流程一直运行稳定。记住解决这类非标准需求的关键在于耐心调试和理解底层原理而不是盲目搜索复制代码。希望这份详细的改造指南能让你在下次遇到类似需求时更加游刃有余。