RSA前后端加密解密实战：jsencrypt与Java密钥格式避坑

简介：这份源码面向需要在浏览器端保护敏感参数的前后端开发者，围绕 jsencrypt 公钥加密与 Java 私钥解密搭建了一套可直接参考的 RSA 安全通信示例，适用于登录口令、表单字段等不宜明文传输的场景。压缩包共 4 个文件，由 2 个 JavaScript 脚本、1 个 HTML 页面和 1 个 Java 类组成，整体约 54KB，分别承担前端加密依赖、交互演示与后端解密逻辑。目前已有 3168 人学习下载，说明该实现具备一定的参考覆盖面。读者可据此快速理清公钥与私钥的 Base64、PEM 格式处理，RSA/ECB/PKCS1Padding 的加解密匹配，以及前端请求到后端解密的完整链路，并在此基础上接入现有项目；源码短小，也便于对照排查填充方式、密钥长度和跨语言编码不一致等常见问题。

1. 登录框里那串明文密码，是这个项目存在的理由

抓包工具一打开，登录请求体里password=123456明晃晃地躺着——很多后台管理系统第一次做安全整改，都是从看到这一幕开始的。这个源码包干的就是这件事：前端用 jsencrypt 拿 RSA 公钥把敏感字段加密成 Base64 密文，后端 Java 用私钥还原出明文，中间不需要额外的加密机，也不依赖特定框架。它适合谁？做后台管理、做表单提交、做小程序或 H5 登录的开发者，尤其是那种已经上了 HTTPS、但业务方仍然要求“密码不能以明文出现在请求体里”的场景。先说明白一件事：RSA 加密不是 HTTPS 的替代品，它挡的是日志留痕、抓包截图、中间层记录这类问题。想直接跑通一份前后端能对上的实现，这里面的密钥格式、分段规则、填充模式，恰恰是最容易翻车的地方。

2. 密钥对与格式约定：先用十分钟把 PKCS#1 和 PKCS#8 分清楚

我在项目里见过太多“代码没错、就是解不开”的案例，最后查下来八成是密钥格式不对。RSA 的密钥文件有好几种壳，PEM 只是最外面那层 Base64 文本，里面的 ASN.1 结构才是决定谁能读的关键。前端 jsencrypt 和后端 Java 的KeyFactory对格式的胃口并不完全一样，所以在写任何一行加密代码之前，先把密钥生成和格式转换这一步做干净。

2.1 生成一对 2048 位密钥，别再用 1024

1024 位 RSA 现在属于“能跑但不该用”的范畴，公钥分解成本已经低到不具备实际防护意义。这个源码包默认走 2048 位，生成的密文长度是 256 字节，Base64 之后 344 个字符，网络传输完全扛得住。命令行用 OpenSSL 三步走：

# 1. 生成 2048 位私钥，OpenSSL 默认输出 PKCS#1 格式（BEGIN RSA PRIVATE KEY） openssl genrsa -out private_pkcs1.pem 2048 # 2. 转成 Java 的 PKCS8EncodedKeySpec 能直接吃的 PKCS#8 格式 openssl pkcs8 -topk8 -inform PEM -in private_pkcs1.pem \ -outform PEM -nocrypt -out private_pkcs8.pem # 3. 从私钥导出公钥，输出 SubjectPublicKeyInfo 结构（BEGIN PUBLIC KEY） openssl rsa -in private_pkcs1.pem -pubout -out public.pem

第一条命令的-nocrypt在第三条里不存在，是因为导出公钥本来就没有加密的概念。第二条的-nocrypt很重要，它表示私钥不带密码保护，Java 侧直接 Base64 解码就能用；如果加了密码，PKCS8EncodedKeySpec会解析失败，报InvalidKeySpecException，而这个异常信息非常笼统，排查起来就是黑匣子。

生成完之后，两个文件的内容长这样：

-----BEGIN PRIVATE KEY----- MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQ... -----END PRIVATE KEY-----

-----BEGIN PUBLIC KEY----- MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA... -----END PUBLIC KEY-----

前端只拿公钥，私钥永远不出后端进程，这是这套方案的基本纪律。我在实际项目里会把私钥放到配置中心或者环境变量里，代码仓库里只留一个占位符，谁要是把私钥提交上去，代码评审直接打回。

2.2 前端能认的公钥只有一种壳

jsencrypt 内部会把 PEM 字符串去掉头尾、做 Base64 解码，然后按 ASN.1 去解析 SubjectPublicKeyInfo 结构。这意味着它只认-----BEGIN PUBLIC KEY-----这种 PKCS#8 公钥。如果拿到的是-----BEGIN RSA PUBLIC KEY-----（PKCS#1 公钥），setPublicKey不会报错，但encrypt会安静地返回false，这个设计很坑，后面避坑章节会专门讲。

格式差异整理成一张表，联调时对着看最快：

如果手上只有 PKCS#1 公钥，转一下就行：

openssl rsa -RSAPublicKey_in -in public_pkcs1.pem -pubout -out public_pkcs8.pem

2.3 密钥放哪：别硬编码在 Vue 组件里

公钥硬编码在.vue文件里最省事，但也最难受——换密钥要重新构建发版。这个源码包的做法是把公钥塞进构建期环境变量，运行时拼成完整 PEM：

# .env.production VITE_RSA_PUBLIC_KEY=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...

// src/utils/rsa.js // 环境变量里只存 Base64 主体，避免换行符在 .env 里被转义吃掉 const rawKey = import.meta.env.VITE_RSA_PUBLIC_KEY export const PUBLIC_KEY = [ '-----BEGIN PUBLIC KEY-----', rawKey, '-----END PUBLIC KEY-----' ].join('\n')

这里用数组 join 而不是模板字符串，是为了避免构建工具对\n的处理差异。我一般还会在后端暴露一个/api/crypto/publicKey接口，返回当前生效的公钥和一个keyVersion，前端拿到之后缓存到 sessionStorage，这样密钥轮换时不用等前端发版。代价是多一次请求，但对内部管理系统来说完全值得。

再确认一个参数：密钥长度。2048 位是当前默认选择，3072 位安全余量更大但加密耗时明显上升，前端一次分段加密会感知到卡顿。这个项目用 2048，够用且兼容性最好。

3. 前端 jsencrypt 加密链路：从 setPublicKey 到能过网关的密文

前端这一段看着简单，new JSEncrypt()加encrypt()两行就完事，但真正上线时会碰到三个问题：公钥格式、明文长度、传输编码。这三个点分别对应下面的三节，每一节都有可以直接抄的封装代码。

3.1 装包与初始化：JSEncrypt 实例不适合全局复用

先装依赖，这个库很轻，没有额外依赖：

npm install jsencrypt

封装一个独立的加密模块，别在组件里到处 new：

// src/utils/rsa.js import JSEncrypt from 'jsencrypt' import { PUBLIC_KEY } from './publicKey' /** * 单段 RSA 加密 * @param {string} plainText 明文，业务上是密码、手机号这类短字段 * @returns {string} Base64 密文 */ export function rsaEncrypt(plainText) { const encryptor = new JSEncrypt() encryptor.setPublicKey(PUBLIC_KEY) const cipher = encryptor.encrypt(plainText) // encrypt 失败会返回 false，不抛异常，必须显式判断 if (cipher === false) { throw new Error('RSA 加密失败，检查公钥是否为 PKCS#8 格式') } return cipher }

setPublicKey的入参是完整 PEM 字符串，带不带换行都行，库内部会replace掉头尾和空白字符。encrypt的返回值类型是string | false，这个false是万恶之源——它不告诉你为什么失败，只会让你在后面的解密环节看到一个莫名其妙的BadPaddingException。

每次都 new 一个实例而不是全局单例，是因为 JSEncrypt 实例内部维护了key状态，某些版本在并发调用时会出现填充数据串位的问题。加密本来就是毫秒级操作，实例创建开销可以忽略，稳妥优先。

3.2 长度上限：2048 位密钥一次只能吃 245 个字节

RSA 有个硬性限制，PKCS#1 v1.5 填充会占用 11 个字节，所以单次能加密的明文上限是密钥字节数 - 11。2048 位密钥就是 256 - 11 = 245 字节。听起来不少，但中文 UTF-8 编码下一个汉字占 3 个字节，245 字节只够 81 个汉字。密码字段够用，但如果是加密整段 JSON 或者带中文的地址信息，直接加密会静默截断。

分段加密的标准写法：

// 单段最大字符数，保守取 100 // 为什么不用 245：jsencrypt 内部按字符长度做 UTF-8 转换， // 100 个汉字转完约 300 字节，仍然会超；所以这个值要按业务字符集调 const CHUNK_SIZE = 80 const SEPARATOR = '|' /** * 长文本分段加密 * @param {string} plainText 任意长度的明文 * @returns {string} 多段 Base64 密文，用分隔符拼接 */ export function rsaEncryptLong(plainText) { const encryptor = new JSEncrypt() encryptor.setPublicKey(PUBLIC_KEY) const chunks = [] for (let i = 0; i < plainText.length; i += CHUNK_SIZE) { const part = plainText.substring(i, i + CHUNK_SIZE) const cipher = encryptor.encrypt(part) if (cipher === false) { throw new Error(`第 ${chunks.length + 1} 段加密失败`) } chunks.push(cipher) } return chunks.join(SEPARATOR) }

CHUNK_SIZE取 80 是我踩过坑之后的经验值。理论值 245 字节，纯 ASCII 下可以取到 200 多，但业务里一旦混进 emoji（4 字节）或者生僻字，就会踩线。80 这个值对密码、手机号、身份证号这些短字段完全够用，对长文本也只是多分几段，encrypt本身是同步的，几十段的耗时也就几毫秒。

分隔符选|而不是逗号或分号，是因为 Base64 的字符集是A-Z a-z 0-9 + / =，不包含竖线，不会产生歧义。前后端必须约定同一个分隔符，这个约定要写进接口文档，不然换个人接手就重新踩一遍。另一个方案是把分段密文放进 JSON 数组传输，结构更清晰，但会让接口字段类型从 string 变成 array，老接口改造时不太方便。

3.3 传输层：Base64 里的加号会被表单编码吃掉

这是我认为最隐蔽的一个坑。Base64 密文里会出现+和/，如果请求用application/x-www-form-urlencoded提交，服务端解码时会把+还原成空格，后端拿到密文去做 Base64 解码，直接抛Illegal base64 character 20（20 是空格的 ASCII 码）。现象就是“有时候能解开，有时候报错”，非常有玄学感。

解决办法有两个，我推荐第二个：

// 方案一：对密文做 URL 编码，后端需要先 URL 解码 const cipher = encodeURIComponent(rsaEncryptLong(password)) // 方案二：改用 JSON body，Base64 字符在 JSON 字符串里原样保留，不经过表单编码 const response = await fetch('/api/login', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ username, password: rsaEncryptLong(password) }) })

方案二更干净，因为绝大多数现代后端接口本来就用@RequestBody接收 JSON。如果被迫走表单提交，除了encodeURIComponent，还可以在后端统一把密文里的空格替换回+，但这属于打补丁，能不用就不用。

还有一个细节：如果接口网关对请求体做了日志打印，密文会被完整记录下来。这不是问题，因为密文离开私钥就是一堆随机字节，但要注意别让日志系统把私钥也打出来。

4. 后端 Java 解密链路：私钥加载、Cipher 初始化和分段拼接

后端这边的主要工作是把 PEM 私钥变成PrivateKey对象，初始化Cipher，然后按前端的分段规则逐段解密、按 UTF-8 拼接。看似线性，但每一环都有版本兼容和编码陷阱。

4.1 私钥加载：PKCS8EncodedKeySpec 与 BouncyCastle 兼容

标准 JDK 自带的能力只能读 PKCS#8 私钥，代码很短：

import java.security.KeyFactory; import java.security.PrivateKey; import java.security.spec.PKCS8EncodedKeySpec; import java.util.Base64; public final class KeyLoader { private KeyLoader() {} /** * 加载 PKCS#8 格式的 RSA 私钥 * @param pem 完整 PEM 字符串，含头尾 */ public static PrivateKey loadPkcs8PrivateKey(String pem) throws Exception { // 1. 去掉 PEM 头尾 String normalized = pem .replace("-----BEGIN PRIVATE KEY-----", "") .replace("-----END PRIVATE KEY-----", "") // 2. 去掉所有空白字符，包括换行、制表、空格 .replaceAll("\\s+", ""); // 3. Base64 解码得到 DER 字节 byte[] der = Base64.getDecoder().decode(normalized); // 4. 按 PKCS#8 规范生成私钥 KeyFactory factory = KeyFactory.getInstance("RSA"); return factory.generatePrivate(new PKCS8EncodedKeySpec(der)); } }

replaceAll("\\s+", "")这一步不能省。PEM 文件从 Windows 拷贝到 Linux、从配置文件读到字符串，换行符可能是\r\n也可能是\n，Base64.getDecoder()对\r非常敏感，会直接抛Illegal base64 character 0d。统一清洗掉最省事。

如果手上只有 PKCS#1 私钥，标准 JDK 读不了，得靠 BouncyCastle。Maven 里加依赖：

<dependency> <groupId>org.bouncycastle</groupId> <artifactId>bcprov-jdk18on</artifactId> <version>1.78.1</version> </dependency>

然后这样读：

import org.bouncycastle.openssl.PEMKeyPair; import org.bouncycastle.openssl.PEMParser; public static PrivateKey loadPkcs1PrivateKey(String pem) throws Exception { try (PEMParser parser = new PEMParser(new StringReader(pem))) { Object obj = parser.readObject(); // BEGIN RSA PRIVATE KEY 解析出来是 PEMKeyPair PEMKeyPair pair = (PEMKeyPair) obj; byte[] der = pair.getPrivateKeyInfo().getEncoded(); KeyFactory factory = KeyFactory.getInstance("RSA"); return factory.generatePrivate(new PKCS8EncodedKeySpec(der)); } }

PEMParser.readObject()返回的类型取决于 PEM 头：BEGIN RSA PRIVATE KEY返回PEMKeyPair，BEGIN PRIVATE KEY返回PrivateKeyInfo，BEGIN PUBLIC KEY返回SubjectPublicKeyInfo。用之前一定要instanceof判断，不然就是ClassCastException。我一般会写一个统一入口，根据头字段分流，代码长一点但以后换密钥格式不用动业务。

4.2 Cipher 初始化：填充模式必须两端对齐

解密方法要显式指定算法全称：

import javax.crypto.Cipher; import java.nio.charset.StandardCharsets; private static final String TRANSFORMATION = "RSA/ECB/PKCS1Padding"; private static final String SEPARATOR = "\\|"; public static String decryptLong(String cipherText, PrivateKey privateKey) throws Exception { Cipher cipher = Cipher.getInstance(TRANSFORMATION); cipher.init(Cipher.DECRYPT_MODE, privateKey); String[] parts = cipherText.split(SEPARATOR); StringBuilder result = new StringBuilder(); for (String part : parts) { byte[] encoded = Base64.getDecoder().decode(part); byte[] plain = cipher.doFinal(encoded); // 必须显式指定 UTF-8，不能用 new String(plain) result.append(new String(plain, StandardCharsets.UTF_8)); } return result.toString(); }

Cipher.getInstance("RSA")在很多 JDK 实现里等价于RSA/ECB/PKCS1Padding，但不同厂商的 Provider 默认值不一定一致，写全称是最稳的。中间的ECB对 RSA 来说没有实际意义，因为 RSA 加解密是单块操作，这个位置只是 API 要求的占位符。

cipher.doFinal在 PKCS#1 填充模式下可以在同一个Cipher实例上连续调用，不需要每段重新init。但如果你把填充换成了 OAEP，某些 Provider 会要求每次重新初始化，所以更保险的写法是在循环内init，代价是性能略降。短字段场景下这点开销可以忽略。

new String(plain, StandardCharsets.UTF_8)这一行是血泪经验。不指定字符集时会用 JVM 默认编码，Linux 上通常是 UTF-8 没问题，Windows 开发机上默认是 GBK，同一个密文在两边解出来一个是正常中文一个是问号。这种问题在本地永远复现不了，一上测试环境就炸。

4.3 Controller 层：解密失败的兜底与限流

解密方法写好后，接到接口上还要考虑失败路径：

@PostMapping("/login") public Result login(@RequestBody LoginDTO dto) { String cipherText = dto.getPassword(); // 粗粒度长度校验，防止超大报文打满 CPU if (cipherText == null || cipherText.length() > 4096) { return Result.fail("参数异常"); } String plainPassword; try { plainPassword = RsaUtils.decryptLong(cipherText, privateKey); } catch (BadPaddingException e) { // 密文被篡改、公私钥不配对、填充模式不一致都会落到这里 log.warn("RSA 解密失败，密文长度={}", cipherText.length()); return Result.fail("解密失败，请刷新页面重试"); } catch (Exception e) { log.error("RSA 解密异常", e); return Result.fail("参数异常"); } return authService.login(dto.getUsername(), plainPassword); }

BadPaddingException单独捕获并只记日志，是因为这个异常信息会暴露“填充校验失败”这一事实，攻击者可以据此做填充预言攻击。返回给前端的永远是模糊提示，细节留在服务端日志里。

另外，RSA 解密比加密慢，2048 位私钥解密大约在 1 到 2 毫秒量级，虽然不高，但接口必须限流。这个项目用的是注解加 Redis 计数，同一个 IP 每分钟超过 30 次直接拒绝，防止有人拿密文刷接口做资源消耗。

5. 联调避坑：五个高频翻车现场与一份自检清单

加密解密这类功能有个特点：代码写完之后，第一次联调大概率不通，而且报错信息指向性很弱。下面这五条是我在不同项目里反复遇到的，按“现象 → 原因 → 解决”整理，对着排查基本能覆盖九成问题。

5.1 五个高频翻车现场

现象一：前端encrypt返回false，控制台没有任何报错。原因：公钥格式不对。最常见的是拿了BEGIN RSA PUBLIC KEY（PKCS#1），jsencrypt 解析 ASN.1 失败但不抛异常。 解决：确认公钥头是BEGIN PUBLIC KEY，不是的话用openssl rsa -RSAPublicKey_in -in xxx.pem -pubout转一次。另外检查环境变量里的 Base64 有没有被换行截断。

现象二：后端抛javax.crypto.BadPaddingException: Decryption error。原因：三种可能——公私钥不配对、填充模式不一致、密文在传输中被改动。填充模式不一致最常见，比如前端 jsencrypt 固定用 PKCS#1 v1.5，后端有人手写成了RSA/ECB/OAEPWithSHA-256AndMGF1Padding。 解决：后端统一用RSA/ECB/PKCS1Padding。验证公私钥是否配对，可以用openssl rsa -in private.pem -pubout导出公钥，和前端用的公钥做字符串比对。

现象三：解密成功，但中文变成乱码或者问号。原因：new String(byte[])用了 JVM 默认编码，Windows 开发机是 GBK，Linux 服务器是 UTF-8，两端表现不一致。 解决：所有字节转字符串的地方显式写StandardCharsets.UTF_8，前端TextEncoder默认也是 UTF-8，两端对齐。

现象四：后端报IllegalArgumentException: Illegal base64 character 20。原因：密文里的+在application/x-www-form-urlencoded提交时被解码成了空格（ASCII 32，十六进制 20）。 解决：改用 JSON body 提交，或者前端encodeURIComponent加后端 URL 解码。排查时可以先把收到的密文打出来，看里面有没有空格。

现象五：短密码能解开，长文本只解出前面一段。原因：前端没做分段，超长明文被 jsencrypt 静默截断；或者前端分了段但后端没按分隔符切，把整串当一段解。 解决：两端约定同一个SEPARATOR和同一套切分规则，接口文档里写清楚。测试用例里放一条超过 80 个汉字的数据，这是最容易被遗漏的边界。

5.2 上线前必过的自检清单

这份清单我一般会贴到发布检查单里，逐条打勾：

• 私钥是否只存在后端进程可读的位置，代码仓库和前端产物里搜一遍确认没有
• 前端公钥是否通过环境变量或接口下发，没有写死在组件里
• 加解密方法是否有单元测试，覆盖空串、超长中文、含 emoji 三种输入
• 解密接口是否有频率限制和请求体长度上限
• 生产环境是否仍然启用 HTTPS，RSA 加密只是额外一层，不能替代传输层安全
• 密钥轮换流程是否演练过，前端缓存里的旧公钥会不会导致解密失败

最后一条容易被忽略。前端把公钥缓存在 sessionStorage 里，后端换了密钥之后，老会话里的页面还在用旧公钥加密，后端用新私钥解不开，用户看到的就是“登录失败请重试”，刷新页面才好。解决办法是在公钥接口返回里带keyVersion，解密失败时前端清缓存并拉一次新公钥重试，这个逻辑在后端加个版本号字段就能支撑。

6. 二次开发：从单字段加密到混合加密的改造路径

这份源码跑通之后，最常见的二次开发诉求是“整段报文都要加密”。直接对 JSON 字符串做 RSA 分段加密能跑，但密文体积会膨胀到原文的 10 倍以上，接口体大、解密慢，不划算。我一般会改成 AES + RSA 混合：前端随机生成一个 16 字节的 AES 密钥，用 AES-GCM 加密业务报文，再用 RSA 公钥加密这个 AES 密钥，两个字段一起传给后端。后端先用私钥解出 AES 密钥，再解报文。改动集中在两个工具类，业务代码不用动。

// 混合加密骨架：AES 加密正文，RSA 加密密钥 export async function hybridEncrypt(payload) { const aesKey = crypto.getRandomValues(new Uint8Array(16)) const iv = crypto.getRandomValues(new Uint8Array(12)) const cryptoKey = await crypto.subtle.importKey( 'raw', aesKey, { name: 'AES-GCM' }, false, ['encrypt'] ) const body = await crypto.subtle.encrypt( { name: 'AES-GCM', iv }, cryptoKey, new TextEncoder().encode(JSON.stringify(payload)) ) return { // AES 密钥只有 16 字节，单段 RSA 就能装下，不需要分段 key: rsaEncrypt(String.fromCharCode(...aesKey)), iv: btoa(String.fromCharCode(...iv)), data: btoa(String.fromCharCode(...new Uint8Array(body))) } }

这里String.fromCharCode(...aesKey)把二进制密钥转成字符串再走 RSA，后端解出来之后按同样的字符编码还原成字节数组。注意不能用btoa处理密钥，因为 RSA 加密的输入必须是字符串，多一层 Base64 反而会让长度校验变复杂。

改造时有两个验证点必须做。一是回归测试里保留一份“纯 RSA 单字段加密”的用例，确保老接口没被改坏；二是加一条篡改测试，把密文最后一个字符改掉，断言后端抛BadPaddingException且返回统一错误码，而不是 500。这条测试我最初没写，结果有一次上线后发现异常没被捕获，错误堆栈直接返给了前端，被人截图发到群里，场面很难看。

换填充模式也是常见需求，有些安全规范要求用 OAEP。改的时候前端 jsencrypt 不支持 OAEP，得换jsrsasign或者node-forge，后端Cipher的 transformation 同步改成RSA/ECB/OAEPWithSHA-256AndMGF1Padding，两端必须一起改、一起发版。我的习惯是先在测试环境用一组固定的密钥对跑通加解密，确认无误再动生产配置，绝不直接在线上调试填充参数。从那以后我每次碰密钥和填充相关的改动，都强制走一遍“前端 encrypt、后端 decrypt、篡改一个字符确认抛异常”这三步，一步都不能少。希望帮到你。

本文还有配套的精品资源，点击获取