根据Bouncy Castle FIPS Java API guide，版本：0.1
在4.2节中，指定了一些填充机制与公钥算法（ELGAMAL / RSA）一起使用：
如何配置哪种填充机制将与公钥算法一起使用？对于客户和客户而言服务器通信。
特别是我对RSA在TLS中用作密钥交换机制的情况感兴趣。
答案 0 :(得分：0)
当RSA用于TLS plain-RSA密钥交换中的密钥传输时，它总是使用PKCS1-v1_5填充;请参阅rfc5246 4.7和7.4.7.1或相应的早期版本（当它简称为块类型2时，因为OAEP尚未存在）。您无法配置任何其他内容，其他任何内容都无法互操作。 （在TLS1.3中，因为目前提出的RSA密钥传输将不再存在。）
当RSA用于TLS中的服务器或客户端身份验证时，作为密钥交换的一部分，如DHE_RSA和ECDHE_RSA，在1.0和1.1中，签名算法被修复为PKCS1-v1_5的修改（使用串联的MD5和SHA1哈希，没有ASN） .1 DigestInfo）;见rfc4346 4.7或rfc2246。在1.2中，签名算法从对等方提供的算法中选择（在服务器的ClientHello扩展中，在客户端的CertReq字段中），但唯一的RSA选项是标准PKCS1-v1_5，MD5 SHA-1或SHA-2哈希，许多（如果不是全部）实现（包括Java的最新更新）现在禁止MD5; AFAICT JSSE中没有配置可以在允许的哈希值中进行选择。 （1.3建议在协议中更改为PSS，PKCS1-v1_5签名仅允许用于证书。）
如果您关注美国政府应用程序的FIPS-140合规性，请参阅SP800-135，其仅在TLS中使用时批准TLS KDF ，尽管它们通常不被批准用于FIPS-140。另请注意，除了加密原语外，SP800-52还有其他TLS部分的强制性指导。