关于RSA加密/解密中OAEP填充模式和PKCS1-v1_5填充模式时对于原文数据的要求

在《RFC-8017 PKCS #1 RSA Cryptorgraphy Specification Version 2.2》规范的第7章节中规定了RSA算法在PKCS1填充和OAEP填充模式下，对于原文数据的约束。

本节内容主要起因于工作中遇到的一个问题，对于应用开发者来说，实际上并不需要我们去深度学习RSA算法实现，我们只要知道RSA算法加解密应用场景，不同场景下规范定义的数据封装格式，及签名/验签/加密/解密方案约束即可。

这里概括下本节主要内容，用于学习总结，手动翻译，个中存在错误纰漏欢迎批评指正。

RSA加密时，对于原文数据的要求：

• OAEP填充模式： 原文长度 <= 密钥模长 - (2 * 原文的摘要值长度) - 2字节 

        各摘要值长度：

                SHA-1:      20字节

                SHA-256:  32字节

                SHA-384:  48字节

                SHA-512:  64字节

• PKCA1-V1_5填充模式：原文长度 <= 密钥模长 - 11字节

---

7. 加密方案

在本文档中，加密方案由加密操作和解密操作组成，其中加密操作使用接收方的RSA公钥从消息中生成密文，解密操作使用接收方相应的RSA私钥从密文中恢复消息。

加密方案可用于多种应用。典型的应用是密钥建立协议，其中消息包含要从一方秘密传递给另一方的关键材料。例如，PKCS#7[RFC2315]使用这样的协议将内容加密密钥从发送方传递给接收方；这里定义的加密方案在这种情况下是合适的密钥加密算法。

本文件规定了两种加密方案：RSAES-OAEP和RSAES-PKCS1-v1_5。新应用需要支持RSAES-OAEP；RSAES-PKCS1-v1_5仅用于与现有应用程序兼容。

此处给出的加密方案遵循与IEEE 1363[IEEE1363]中使用的加密方案类似的通用模型，将加密和解密原语与加密的编码方法相结合。加密操作将消息编码操作应用于消息以生成编码消息，然后将其转换为整数消息表示。加密原语应用于消息代表以生成密文。相反，解密操作将解密原语应用于密文以恢复消息代表，然后将其转换为八进制字符串编码的消息。消息解码操作应用于编码消息，以恢复消息并验证解密的正确性。

为了避免与解码操作中错误处理方式相关的实现缺陷（参见[BLEICHENBACHER]和[MANGER]），RSAES-OAEP和RSAES-PKCS1-v1_5的编码和解码操作嵌入各自加密方案的规范中，而不是在单独的规范中定义。这两种加密方案都与PKCS#1 v2.1中的相应方案兼容。

---

7.1 RSAES-OAEP

RSAES-OAEP将RSAEP和RSADP原语（第5.1.1和5.1.2节）与EME-OAEP编码方法（第7.1.1节中的第2步和第7.1.2节中的步骤3）相结合。EME-OAEP基于Bellare和Rogaway的最优非对称加密方案[OAEP]。它与IEEE 1363[IEEE1363]中定义的整数分解加密方案（IFES）兼容，其中加密和解密原语为IFEP-RSA和IFDP-RSA，消息编码方法为EME-OAEP。RSAES-OAEP可以操作长度高达 k-2hLen-2 个八位字节的消息，其中hLen是底层哈希函数输出的长度，k是接收方RSA模的八位字节长度。

注意：对于RSA -OAEP时，要求的输入原文数据长度 <= RSA公钥模长 - (2 * 原文的摘要值长度) - 2字节

假设计算模n的第e个根是不可行的，并且RSAES-OAEP中的掩码生成函数具有适当的属性，则RSAES-AAEP在语义上是安全的，可以抵抗自适应选择密文攻击。这种保证是可以证明的，即破坏RSAES-OAEP的困难可能与转换RSA函数的困难直接相关，前提是掩码生成函数被视为黑盒或随机预言；有关进一步讨论，请参见[FOPS]和下面的注释。

RSAES-OAEP的加密和解密操作都将标签L的值作为输入。在此版本的PKCS#1中，L是空字符串；标签的其他用途不在本文档的范围内。有关ASN，请参见附录A.2.1。1语法。

RSAES-OAEP通过选择哈希函数和掩码生成函数进行参数化。对于给定的RSA密钥，应该修复此选项。附录B中给出了建议的哈希和掩码生成函数。

注：过去的结果有助于澄清OAEP编码方法[OAEP]的安全属性（大致如第7.1.1节步骤2所述）。背景如下。1994年，Bellare和Rogaway[OAEP]引入了一个安全概念，表示明文感知（PA94）。他们证明，如果没有私钥就很难反转确定性公钥加密原语（例如