java.security.NoSuchAlgorithmException:找不到任何支持AES / ECB / PKCS7PADDING的提供程序

我试图使用AES算法加密数据。 但是,发生了以下exception。

java.security.NoSuchAlgorithmException: Cannot find any provider supporting AES/ECB/PKCS7PADDING 

有人知道这个问题的解决方案吗? 我的JDK版本是1.7。

您不希望为块密码使用指定PKCS#7填充。 您想指定PKCS#5填充。 PKCS#5指定用于块密码,而PKCS#7则不用(它用于S / MIME等不同的地方)。 我将指出PKCS#5和PKCS#7实际上指定了完全相同类型的填充(它们是相同的!),但在此上下文中使用它时称为#5。 🙂

因此,您需要"AES/ECB/PKCS5PADDING"而不是"AES/ECB/PKCS5PADDING" 。 这是一个密码实现,需要Java平台的每个实现都支持。 有关更多详细信息,请参阅Cipher类的文档 。

有关包括PKCS#5和PKCS#7加密标准文本在内的问题的全面解释,请查看此处 。


PKCS#5填充意味着填充1到8个字节。 填充字节本身包含编码为字节的填充字节数。 为DES指定了PKCS#5填充,但它适用于块大小为8字节的任何块密码。

现在DES规范甚至基于密码的加密的PKCS#5规范都在Java和Java之前很长一段时间。 AES仅在2002年标准化,早在Java甚至Java 2推出之后很久。 因此,在AES出现之前,(三重)DES和PKCS#5填充已集成到Java中。

当Java – 或者更确切地说,Sun JCE提供程序 – 获得AESfunction时,它需要填充方法,块大小为16字节。 PKCS#7指定此填充方法与PKCS#5填充相同 ,不同之处在于它定义为2到255个字节的块大小(如果它编码基于零的无符号整数,则为字节的最大值)。 但是,填充方法已经存在; 它被命名为"PKCS5Padding" 。 因此,不再引入新名称, "PKCS5Padding"简单地重复使用"PKCS5Padding"

到目前为止,Sun提供商应该真正支持"PKCS7Padding"因为PKCS#5填充只是不正确。 它不仅仅是一个Java命名问题,对于任何试图实现加密协议或将其他应用程序移植到Java的开发人员来说都是一个问题。 但是现在,您应该使用"PKCS5Padding"而不是"PKCS7Padding"

如果你想使用AES / ECB / PKCS7Padding,那么bouncy castle将支持ht tp://www.bouncycastle.org/specifications.html