RSA加密填充机制详解：PKCS#1 OAEP原理与跨语言实践

第一次在项目里正儿八经地用RSA，是在一个支付回调的联调任务里。我把 PKCS#1 OAEP 当成普通的填充参数，从老代码里复制过来改了改就往上贴。结果Java侧加密出来的一长串密文，Python侧怎么都解不开；日志里密钥对明明是同一份，但"decryption error"就像复读机一样刷屏。折腾了两天才翻明白PKCS#1规范，也才意识到OAEP这三个字母背后不是简单的补位，而是一套跟安全模型绑定的编码协议。

这篇内容主要讲清楚三件事：为什么RSA在加密时必须做填充、OAEP这套填充机制内部到底怎么运作、以及到了实际项目里参数配置和密钥格式最容易在哪些地方翻车。适合刚上手RSA加密的新人，也适合被跨语言解密失败折磨过、想搞清楚原理的工程师。看完你可以直接照着后面几张配置表去对齐两端参数。

1. 裸RSA的翻车现场：为什么非要有填充这一步

如果只看数学教材，RSA加密就一句话：把明文m转成整数，算 c = m^e mod n，解密就是 m = c^d mod n。很多新手第一次实现时就是这么干的，然后就会撞上一连串莫名其妙的问题。

1.1 三个看起来"没问题"却解不开的场景

第一个场景是明文长度稍微长一点就失败。比如2048位密钥，n是256字节，你拿一个200字节的字符串去加密，pow函数跑完，解密得到的往往是乱码。因为m一旦接近或超过n，模运算就把整数"卷"过去了，密文对应的整数就不再是原来的那个。很多人以为"只要小于256字节就行"，其实不是，RSA加密要求明文整数必须严格小于n，而且为了保证可逆性，最好与n互质。

第二个场景是同一个明文加密两次，密文完全一样。这个特性看起来无害，但在真实协议里很致命。比如你在登录请求里把密码用RSA公钥加密后发给服务器，攻击者只要截获两段密文，发现长度相等、内容相同，就能判断是同一用户、同一密码。更麻烦的是，加密结果的确定性和明文空间有限这两个条件叠加，给了攻击者离线穷举的空间：他可以把常用口令全部加密成密文，然后跟你发的密文比对，一次匹配就泄露了明文。

第三个场景容易被忽略，但真的会出事：裸RSA是同态的。也就是说，攻击者拿到你的密文c，不用知道私钥，就可以构造出另一个密文c'，它解密后对应的明文，等于原明文乘上某个攻击者选择的因子。在一些需要防篡改的协议里，这种性质会被利用来操纵消息内容。填充机制的核心目的之一，就是把这些数学结构给"打散"掉。

1.2 裸RSA的数学层面硬伤

从形式化安全模型的角度讲，裸RSA连最基础的"选择明文攻击下的不可区分性"（IND-CPA）都满足不了。简单说就是：攻击者选出两条明文m0和m1，挑战者只加密其中一条给你，攻击者只要把两条都自己加密一遍，跟挑战密文一比，立刻知道是哪条。这种"可以猜"的加密方式，在真实系统里是没法直接当加密方案用的。

另外还有一个细节：如果明文m太小，比如只有几个字节，那么m^e甚至可能小于n，这时密文就是明文的e次方，攻击者直接开e次方就能还原明文。这种情况听起来极端，但当你真去处理一些短字段、短口令时，确实存在。

所以，RSA需要一层"把明文变长、变随机、变不可预测"的处理。这层处理就是我们常说的填充（padding）。从PKCS#1 v1.5开始，官方规范就要求做填充，到了v2.0，OAEP作为新的填充方案被正式引入，也就是标题里的 PKCS#1 OAEP。

1.3 填充到底在填什么

填充不是单纯地把密文对齐到固定长度。它要解决的核心问题有两个：一是让同一明文在不同加密中产生不同密文，让攻击者没有判断依据；二是消除明文与被加密整数之间的直接对应关系，让任何微小改动都会引起整个密文雪崩式变化。OAEP正是围绕这两个目标，在用RSA模幂运算之前，给明文做了一次精心设计的"混淆"。

2. OAEP的核心思想：把确定性加密变成掷骰子加密

2.1 从哪里来：Bellare-Rogaway 1994

OAEP的全称是Optimal Asymmetric Encryption Padding，中文一般译作"最优非对称加密填充"。它由Mihir Bellare和Phillip Rogaway在1994年提出，随后被纳入PKCS#1标准，在v2.0里正式成为RSA推荐的加密填充方案，对应的标准名称是RSAES-OAEP。所谓"最优"，是指在随机预言模型下，这个填充方案能让RSA加密获得可证明的"选择密文攻击下不可区分"（IND-CCA）安全属性。这也是它从1994年提出后，至今依然是主流选择的原因。

2.2 三个关键词：哈希、掩码、Feistel网络

OAEP的构造不复杂，但第一次看规范的人通常会被一大串符号劝退。把它拆开来看，核心只有三个东西：

• 一个哈希函数H，通常用SHA-1或SHA-256。它在整个方案里承担"随机化"和"完整性校验"两个职责。
• 一个掩码生成函数MGF，PKCS#1标准里定义的是MGF1。它的作用是把任意长度的"种子"，扩展成任意长度的"伪随机字节串"，就像把一小撮盐均匀撒进一大锅汤。
• 一个Feistel网络结构，把明文和随机种子反复进行"异或+交叉"的变换。这也是DES等分组密码里用过的经典结构，优点是"混淆扩散"效果好，任何一个输入比特变化，都能扩散到输出的一大片比特。

可以这样理解：OAEP先掷一个骰子（生成随机种子），再用这个骰子对明文做两次"打码"，最后才把打码后的数据交给RSA做模幂。整个过程是可逆的，解密端只要拿到密文，就能反推出打码前的种子和明文。但攻击者看不到种子，也无法在不改动整个打码结果的情况下对密文做手脚。

2.3 为什么加一个随机种子就能打破确定性

RSA模幂本身是确定性的函数，同样输入必然得到同样输出。但加密协议要求的是：同一明文加密后，每次的密文都不同。这个"随机性"没法从模幂里来，只能从进入模幂之前的输入里来。

OAEP的做法是：每次加密时生成一个全新的随机种子seed，seed和明文一起参与变换，最终被掩盖在编码块里。所以即使明文完全一样，两次编码出来的EM也可能完全不同。经过RSA模幂后，两个密文看起来也没有任何统计规律上的关联。这一步就解决了裸RSA能猜、能比对的硬伤。

有些新人会问：随机种子不也一起加密了吗？解密端怎么区分哪部分是种子、哪部分是数据？答案是不需要"区分"。解密端不是去找种子，而是做逆推：先从编码块尾部还原出掩码后的DB，再通过DB和种子之间的交叉关系，反解出种子，然后重新生成掩码，把明文从DB里"挖"出来。整个过程靠的就是Feistel结构的可逆性。这个逆向流程，在下一章里我会一步步拆开讲。

2.4 MGF1到底是怎么"扩展"的

掩码生成函数MGF1是基于普通哈希函数构造的。它接收一个种子seed和一个期望的输出长度maskLen，然后循环执行：第一次调用哈希，输入是seed拼接上4字节的大端计数器0，把哈希输出拼到结果里；第二次换计数器1，再拼一次；如此往复，直到结果长度达到maskLen，最后按需截断。

换句话说，如果你要生成4000字节的掩码，MGF1会以"seed+0"、"seed+1"、"seed+2"这种方式调用哈希函数上百次，再把输出拼接起来。这样，任何一位种子发生变化，最终掩码的所有字节都会面目全非。真实标准里还会检查计数器的上界，但日常使用中我们几乎不会触及上限，知道它是"基于seed扩展出长随机串"就够了。

3. OAEP编码与解码的完整推演：从数据块到密文

这一章我按PKCS#1 v2.2（RFC 8017）的RSAES-OAEP定义来讲，把编码和解码的每个步骤都摆出来。

3.1 编码前的长度检查：为什么2048位RSA只能塞190字节

OAEP有明确的明文长度上限。先约定几个符号：

• k：RSA模数n的字节长度。2048位RSA对应k=256。
• hLen：哈希函数输出长度。SHA-256是32字节，SHA-1是20字节。
• mLen：要加密的明文长度。

加密前必须满足：mLen ≤ k - 2×hLen - 2。

原因在于编码块EM的布局是这样的：1字节的0x00开头，中间是hLen长度的随机种子maskedSeed，剩下的全部是maskedDB，而maskedDB里还要装：hLen的lHash、可选的零字节串PS、1字节的0x01分隔符、以及真正的明文M。减掉这些固定开销，剩下的才是明文可以用的空间。

以2048位RSA（k=256）搭配SHA-256（hLen=32）为例，明文上限 = 256 - 2×32 - 2 = 190字节。如果你换成SHA-1，上限会提升到214字节。很多项目第一次报"Message too long"，就是因为没算这个上限，拿RSA去直接加密几百字节的JSON。

超过了上限怎么办？规范做法是分层：先用AES等对称加密算法加密整个消息，再用RSA-OAEP加密这个AES会话密钥。这也是TLS等协议的标准做法。

3.2 编码五步走：从DB到EM

编码过程可以分成"组织数据块"和"两次掩码混淆"两个阶段。

第一步，组织数据块DB：

• 如果使用了标签L（label），先对L求哈希得到lHash；如果没使用标签，L就是空字符串，于是lHash = Hash("")。现实中绝大多数实现都不设置标签，默认就是空字符串的哈希。
• 根据明文长度和模数长度，计算填充段PS。PS由若干个0x00字节组成，长度是 k - mLen - 2×hLen - 2。
• DB = lHash || PS || 0x01 || M。这串字节就是"待打码的数据"。它保证了解密端能通过固定位置的lHash校验数据的完整性，通过0x01分隔符定位明文起点。

第二步，生成随机种子seed，长度hLen。这一步的随机性来源必须是系统安全随机源，比如Python的secrets、Java的SecureRandom、操作系统的/dev/urandom，不能用时间戳、进程ID这类可预测的东西。

第三步，计算 dbMask = MGF(seed, k - hLen - 1)，然后用 maskedDB = DB XOR dbMask。这一步是把"数据块"用随机种子扩展出的掩码"罩住"。

第四步，计算 seedMask = MGF(maskedDB, hLen)，然后用 maskedSeed = seed XOR seedMask。注意这里MGF的输入变成了maskedDB，输出长度只有hLen。这一步把随机种子也"罩住"了。

第五步，拼接得到最终编码块：

EM = 0x00 || maskedSeed || maskedDB

EM的总长度恰好是k字节。最后把EM当作一个大整数，做 c = EM^e mod n，得到密文。

这里有个容易忽略但值得提一句的细节：EM最前面的0x00字节是"硬编码"的。它的作用不只是对齐长度，更重要的是保证EM这个整数一定小于模数n，因为对于一个k字节的RSA模数，其最高字节的最高有效位通常是1，0x00开头能把EM的数值范围压到2^(8×(k-1))以下，从而避免"加密出来的整数大于等于n"这类边界问题。

3.3 解码与校验：每个0x01、每个哈希都要较真

解密端拿到密文c后，先做私钥模幂 mRaw = c^d mod n，得到一个大整数。如果它的字节数不足k，要在前面补0x00补齐到k字节；如果它大于等于n，直接判定错误。补位后的EM就是加密端EM的"还原版"。接下来：

• 检查EM[0]是否等于0x00，不等于就返回'decryption error'。
• 取出maskedSeed = EM[1 : 1+hLen]，maskedDB = EM[1+hLen : k]。
• 计算 seedMask = MGF(maskedDB, hLen)，还原 seed = maskedSeed XOR seedMask。
• 计算 dbMask = MGF(seed, k - hLen - 1)，还原 DB = maskedDB XOR dbMask。
• 从DB里取出前hLen字节，用它和Hash(标签)做比较。要注意：PKCS#1标准要求这种比较是"恒定时间"的，不能写成一个遇到第一个不相等字节就提前退出的循环，否则会给攻击者留出时序侧信道。
• 从lHash之后开始检查：在遇到第一个非零字节之前，所有字节都必须为0x00；第一个非零字节必须是0x01；0x01之后剩下的才是明文M。如果0x01的位置不对，或者提前碰到了别的字节，都要返回同样的'decryption error'。

为什么要同时检查这么多地方？因为每一个结构性的约束，都在压缩攻击者"猜测"的空间。假如解密端能区分"这里错了"和"那里错了"，攻击者就能利用这种区分逐渐逼近正确结果。所以任何异常都必须统一成一个错误，不露任何口风。

3.4 一个教学版的OAEP编码实现

理论讲再多，不如一行能跑的代码直观。下面是一个用Python写的教学简化版OAEP编码器，不依赖任何加密库，只为了展示核心流程：

import os import hashlib def i2osp(x, xlen): return x.to_bytes(xlen, 'big') def mgf1(seed, mask_len): h_len = hashlib.sha256(b'').digest_size full = b'' counter = 0 while len(full) < mask_len: full += hashlib.sha256(seed + i2osp(counter, 4)).digest() counter += 1 return full[:mask_len] def oaep_encode(message, k, label=b''): h_len = hashlib.sha256(b'').digest_size m_len = len(message) if m_len > k - 2 * h_len - 2: raise ValueError('message too long') l_hash = hashlib.sha256(label).digest() ps = b'\x00' * (k - m_len - 2 * h_len - 2) db = l_hash + ps + b'\x01' + message seed = os.urandom(h_len) db_mask = mgf1(seed, k - h_len - 1) masked_db = bytes(a ^ b for a, b in zip(db, db_mask)) seed_mask = mgf1(masked_db, h_len) masked_seed = bytes(a ^ b for a, b in zip(seed, seed_mask)) em = b'\x00' + masked_seed + masked_db return em

这段代码里的db_mask、masked_db、seed_mask、masked_seed完全对应上面五步。真正用到生产环境时，推荐直接用cryptography或OpenSSL这类成熟实现，不要在业务代码里自己维护这套算法。教学版的意义是帮你建立"每一步在干什么"的心智模型，以后排错的时候能快速定位数据流的哪一环出了问题。

4. 从Bleichenbacher攻击看OAEP为什么"更安全"

4.1 1998年的百万富翁攻击是怎么打穿PKCS#1 v1.5的

在OAEP出现之前，PKCS#1 v1.5填充（通常写作RSAES-PKCS1-v1_5）是RSA加密的主流。它的填充格式比较简单：0x00 0x02开头，跟一串非零随机字节，再加0x00分隔符，最后是明文。解密时服务器检查格式，如果格式不对，就返回"padding error"。

1998年，Daniel Bleichenbacher观察到：当服务器对"填充格式是否正确"给出不同响应时，攻击者可以把截获的密文反复改写并重新提交给服务器，根据服务器是否解密成功，判断自己的猜测是否正确。每次成功的查询都会让候选的明文区间缩小一半左右，几十万到百万次查询之后，攻击者就能恢复出完整的明文。这个攻击因此被称为"Million Message Attack"，百万富翁攻击。它在当时能够实际攻破SSL 3.0等早期协议里采用PKCS#1 v1.5的RSA加密。

这个案例给整个行业最重要的教训是：加密方案的安全性不只取决于数学难题，还取决于填充方案在"错误响应"下的信息泄露路径。你以为Oracles只在数据库里，实际上一个返回不同错误码的解密接口就是一个Oracle。

4.2 OAEP的随机化与不可延展性如何堵住这条路

OAEP之所以能对抗上述攻击，有几个层面：

• 解码端对EM、lHash、PS、0x01分隔符做全套校验，任何一个环节不满足都统一返回'decryption error'。攻击者得不到"哪一步错了"的细粒度反馈。
• 随机种子改变了整个编码块。攻击者改写密文的任何一个bit，解码后EM分布就会完全随机化，几乎不可能恰好构造出一个能通过全部校验的密文。
• OAEP的设计目标正是"不可延展性"：攻击者无法在不知道明文的情况下，通过修改密文得到另一个合法密文。这直接消灭了Bleichenbacher式攻击赖以存在的条件。

4.3 一个容易忽略的点：错误消息和时序照样能形成padding oracle

这里有个极其重要的工程细节：即使你用了OAEP，如果在实现里把"解密失败"和"填充校验失败"区分开返回，或者错误日志打印得过于详细，攻击者还是可以利用响应差异做类似攻击。更隐蔽的是时序：如果lHash比较不是恒定时间的，或者不同错误分支的返回速度不一样，攻击者可以通过统计响应时间来判断内部状态。

所以在生产代码里，我通常要求三件事：解密失败统一抛同一个错误；日志里不记录具体的填充失败原因；所有敏感比较尽量使用恒定时间实现。这个习惯比换一个更强的填充算法更能决定系统真实的安全等级。

5. 跨语言对齐指南：Java、Python、OpenSSL、PB里的OAEP

理论部分结束，回到最实际的问题：为什么同一个RSA密钥对，Java和Python互相解密总是失败？

5.1 参数不对的解密失败长什么样

OAEP实际使用时，有三个参数必须两端完全一致：

• 哈希算法（OAEP Digest）
• 掩码生成函数MGF1所用的哈希算法（MGF1 Digest）
• 标签Label（通常为空字符串，但必须明确设置）

这三个参数一旦有一项不一致，解密端就会在某个校验步骤挂掉，报错往往是"Decryption Error"或者"oaep decoding error"。最坑的是报错信息完全看不出是哪个参数错了，只能靠试。所以规范的做法是：在项目文档或配置里把这三个参数明确写死，做成常量，两端共用同一份文档。

5.2 Java：从Cipher.getInstance到OAEPParameterSpec

Java标准库处理OAEP最常用的写法是：

Cipher cipher = Cipher.getInstance("RSA/ECB/OAEPWithSHA-256AndMGF1Padding"); OAEPParameterSpec spec = new OAEPParameterSpec( "SHA-256", // 主哈希算法 "MGF1", // 掩码生成函数固定为MGF1 MGF1ParameterSpec.SHA256, // MGF1内部哈希算法 PSource.PSpecified.DEFAULT // 标签默认空字符串 ); cipher.init(Cipher.ENCRYPT_MODE, publicKey, spec); byte[] encrypted = cipher.doFinal(plainBytes);

注意这里有个很经典的坑：Cipher.getInstance字符串写作"RSA/ECB/OAEPWithSHA-256AndMGF1Padding"，它只指定了主哈希是SHA-256，没有指定MGF1用什么哈希。在新旧JDK版本里，MGF1的默认值可能不同，如果你没显式传OAEPParameterSpec，很可能出现"Java自己加密自己解密没问题，但和Python端对不上"的情况。所以只要涉及跨端联调，就把OAEPParameterSpec写全，不要依赖任何默认值。

5.3 Python：cryptography库的正确打开方式

Python生态里最推荐的是cryptography库，它的OAEP参数和Java完全对标：

from cryptography.hazmat.primitives.asymmetric import padding from cryptography.hazmat.primitives import hashes encrypted = public_key.encrypt( b"hello", padding.OAEP( mgf=padding.MGF1(algorithm=hashes.SHA256()), algorithm=hashes.SHA256(), label=None ) )

这个写法里，外层OAEP用SHA-256，MGF1也用SHA-256，label为空，和上面Java的OAEPParameterSpec完全一致。如果两端都用这套配置，跨语言解密就能一次通过。如果你用的是pycryptodome的PKCS1_OAEP，也要留意它默认的hashAlgo是SHA-1，需要显式改成SHA-256，并注意它的mgfunc参数默认依赖hashAlgo。

5.4 OpenSSL命令行里的默认值警告

用OpenSSL命令行做OAEP加解密时，容易踩的坑是默认参数。命令大概是：

# 加密 openssl pkeyutl -encrypt -pubin -inkey public.pem -in plain.txt -out cipher.bin \ -pkeyopt rsa_padding_mode:oaep \ -pkeyopt rsa_oaep_md:sha256 \ -pkeyopt rsa_mgf1_md:sha256 # 解密 openssl pkeyutl -decrypt -inkey private.pem -in cipher.bin -out plain.txt \ -pkeyopt rsa_padding_mode:oaep \ -pkeyopt rsa_oaep_md:sha256 \ -pkeyopt rsa_mgf1_md:sha256

如果你不显式写rsa_oaep_md和rsa_mgf1_md，OpenSSL在不同版本里的默认行为可能不同，低版本常用SHA-1。当你用OpenSSL生成的密文交给Java端解密，若两端的摘要参数不一致，就会看到那个令人头疼的"oaep decoding error"。

5.5 老平台接RSA：PB这类环境的可行路线

搜索热词里有"pb调用rsa加密算法"，这里顺带聊一下PowerBuilder这类老平台。PB本身没有内置RSA实现，我见过的可行方案大致有：

• 用PB调用封装好的C动态库，底层用OpenSSL编译DLL，PB通过外部函数声明调用。老项目里这个方案很常见，但要注意二进制数据的字节数组传参、内存释放、异常处理，维护成本比较高。
• 用PB的.NET桥接（PB 12.5+），直接调用System.Security.Cryptography中的RSA类。好处是不用额外造轮子，坏处是部署环境需要.NET运行时。
• 把RSA加解密独立成一个小服务，PB只用HTTP调接口，把公钥加密的需求转发出去。这是我现在最推荐的做法，因为密钥、算法、参数都收敛在服务端，PB端的改动最小，也不会把私钥暴露给客户端。

无论走哪条路，OAEP的三个参数依然要有一份统一的定义，别让PB端拿着一个只有"RSA"字样的简化封装去对接，否则迟早会踩参数不一致的坑。

5.6 顺手记住明文长度上限：混合加密才是长文本归宿

再强调一次长度上限：2048位RSA + SHA-256时，OAEP最多加密190字节。如果你要加密的对象是几百上千字节的JSON、XML、表单数据，千万别硬来。正确姿势是先随机生成一个AES密钥，用AES-GCM加密业务数据，再用RSA-OAEP加密这个AES密钥。这不仅是长度限制决定的，也是性能要求的必然选择——RSA模幂运算比对称加密慢几个数量级。

6. 那些年我们追过的报错：密钥格式与"公钥找不到"排查链路

6.1 "rsa public key not find"出现的几种真实场景

"rsa public key not find"这个报错，听起来像是算法库找不到公钥对象，实际上绝大多数情况是公钥文件或公钥字节流没有被正确解析。我遇到过的主要有三类：

• 公钥文件是二进制DER格式，但代码用文本方式读取，读进来是一堆乱码字符，解析必然失败。
• PEM文件头是BEGIN RSA PUBLIC KEY（PKCS#1格式），但代码或配置期望的是BEGIN PUBLIC KEY（PKCS#8格式），格式不匹配，解析器抛异常。
• 从KeyStore或配置中心取公钥时，别名写错了，或者键值对取出来是null，算法层拿不到PublicKey对象。

这类问题的坑点在于，报错通常出现在很后面的RSA初始化环节，让你误以为是算法参数问题，但其实从头到尾是密钥加载问题。

6.2 PEM、DER、PKCS#1、PKCS#8：看完就不糊涂

这几个词经常被混用，简单梳理如下：

DER是二进制编码，实际存储时就是一段字节流。PEM是先对DER做Base64编码，再加一行"-----BEGIN XXX-----"头、一行"-----END XXX-----"尾的文本格式。PKCS#1格式的公钥只包含RSA的两个大整数n和e；PKCS#8格式（准确说公钥叫SubjectPublicKeyInfo，出自X.509）除了n和e，还包含算法编号等元信息，这也是现代系统默认使用的格式。

大部分现代库和框架都推荐用PKCS#8格式的公钥、PKCS#8格式的私钥。如果你的代码里写的是"BEGIN RSA PUBLIC KEY"而对方给的是"BEGIN PUBLIC KEY"，直接解析会失败，需要在拿到密钥时先做一次格式转换。

OpenSSL转换公钥格式的命令很直接：

# 从PKCS#1格式转成PKCS#8/SPKI格式 openssl rsa -pubin -in rsa_pub_pkcs1.pem -RSAPublicKey_out -out rsa_pub_pkcs8.pem # 查看公钥详细信息，确认格式和N、E openssl pkey -pubin -in public.pem -text -noout

6.3 排查公钥解析问题的标准步骤

我自己的排查顺序是这样，基本每次都能用上：

1. 先看文件头。打开PEM文件，确认头是BEGIN PUBLIC KEY还是BEGIN RSA PUBLIC KEY，再根据目标语言支持的类型决定是否需要转换。
2. 如果是DER二进制，确认读取模式是二进制方式，别在Python里用open(path, 'r')读DER，否则一定乱码。
3. 用OpenSSL的pkey命令验证公钥能不能正常解析、能不能打印出模数和指数。如果命令行都解析不了，问题就在密钥文件本身。
4. 检查Base64解码后的字节长度。2048位RSA的PKCS#1公钥DER编码通常在270字节左右，SPKI格式通常在292字节左右。如果长度差得离谱，说明文件根本不是公钥，或者Base64字符串本身有问题。
5. 再看业务代码。Java里用X509EncodedKeySpec对应SPKI公钥，用RSAPublicKeySpec是需要你手动提供n和e的。你不想把n和e拆出来的话，就用X509EncodedKeySpec，前提是公钥是SPKI格式。

把上面五步走完，绝大多数"rsa public key not find"都能定位到根因。它和OAEP参数是两个维度的坑：密钥格式坑在于"文件根本加载不出来"，OAEP参数坑在于"文件加载出来了但解密对不上"。建议排查时先过密钥格式这一关，再去看填充参数。

7. 从填充往外看：RSA加密项目里的安全实践清单

7.1 公因子攻击：看似遥远的真实威胁

搜索热词里有"rsa公因子的网络攻击案例"，这里专门拎出来说一下。所谓公因子攻击，是指如果两个不同的RSA模数N1和N2共享了一个素数因子p，那么求两者最大公约数gcd(N1, N2) = p，然后就能分别分解这两个模数，把两个私钥都还原出来。

2012年，有学术团队扫描了互联网上的大量公共证书，结果真的发现了不少共享素因子的模数。问题根源不在RSA算法本身，而在部分老旧设备的随机数生成器熵不足：它们生成的素数集中在一个很小的集合里，碰撞概率远高于预期。也就是说，这些设备在"掷骰子"的时候掷出来的点数高度重复。

这对我们的启示是：填充解决的是加密过程中的语义安全问题，公因子攻击解决的是密钥生成过程中的随机源问题。两者都要管。在代码里使用操作系统级安全随机源（比如Python的secrets模块、Java的SecureRandom），不要用自研的伪随机算法去生成密钥，这是底线。有条件的话，可以在密钥或证书入库前做一次检测，检查是否存在与其他库存密钥共享因子的情况。

7.2 密钥长度与哈希算法的搭配

关于RSA密钥长度，当前的主流建议是至少2048位，新系统可以直接上3072或4096。更长的密钥带来更高的计算开销，在服务端高频解密时差异非常明显，所以具体选多少位要结合性能预算来权衡。

OAEP里哈希算法的选择，SHA-256是下限，不要再用SHA-1。虽然SHA-1在OAEP中并没有直接被找到碰撞利用，但SHA-1本身已经进入出局倒计时，没必要给审计人员留话柄。同时要记得：换了哈希算法，明文长度上限也要跟着重算。从SHA-1换成SHA-256，2048位密钥下最大明文从214字节掉到190字节，这个变化在系统设计时很容易被忽略。

7.3 我自己的RSA加密项目检查单

最后把我这些年踩坑总结出的检查单放出来，新项目直接照着过一遍，能省不少联调时间：

• 私钥只放在服务端，客户端只分发公钥。
• 公钥统一转成PKCS#8/PEM格式，私钥统一用PKCS#8加密存储。
• OAEP参数在项目文档里写死：主哈希、MGF1哈希、label，三个都写明，跨端统一。
• 长数据处理采用AES-GCM加密业务数据 + RSA-OAEP加密会话密钥的混合方案。
• 解密失败统一抛'decryption error'，日志不记录具体校验失败的原因。
• 敏感比较使用恒定时间函数，避免时序侧信道。
• 密钥生成使用系统安全随机源，不使用时间戳、进程ID等弱种子。
• 定期检查库存公钥是否存在重复素因子。
• 如果用了PB等老平台，优先把RSA逻辑收敛到服务端，避免客户端持有完整密钥材料。

这份清单里的每一条，背后都有真实项目踩坑的影子。OAEP本身只是RSA加密体系里的一小块，但它牵涉到的参数一致性问题、密钥格式问题、随机源问题、错误处理问题，才是实际交付时真正决定系统安全性的部分。

最后说点个人体会。刚开始做RSA对接的时候，我也以为填充只是"加几个零补齐长度"，直到有一天盯着解密耗时的日志，发现某些错误分支的响应明显快几十毫秒，才意识到这些细节在安全模型里有多大的分量。从那以后，每次做加密方案评审，我都会把填充参数和错误处理当成正式议题，而不是粘贴一段现成代码就收工。加密这里的坑，往往不在数学题本身，而在那些"看着能用"的默认值里。