Подтвердить что ты не робот

Java.security.NoSuchAlgorithmException: не удается найти поставщика, поддерживающего AES/ECB/PKCS7PADDING

Я пытался шифровать данные с использованием алгоритма AES. Однако со следующим исключением.

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

Кто-нибудь знает решение этой проблемы? Моя версия JDK - 1,7.

4b9b3361

Ответ 1

Вы не хотите указывать заполнение PKCS # 7 для использования блочного шифрования. Вы хотите указать дополнение PKCS # 5. PKCS # 5 указан для использования с блочными шифрами, в то время как PKCS # 7 - нет (используется для разных мест, например, S/MIME). Я укажу, что PKCS # 5 и PKCS # 7 фактически указывают точно такой же тип заполнения (они одинаковы!), Но он называется # 5, когда используется в этом контексте.:)

Итак, вместо "AES/ECB/PKCS7PADDING" вы хотите "AES/ECB/PKCS5PADDING". Это реализация шифрования, для поддержки каждой реализации платформы Java. Подробнее см. Документацию класса Cipher.

Ответ 2

Для очень подробного объяснения проблемы, которая включает в себя текст криптографических стандартов PKCS # 5 и PKCS # 7, пожалуйста, посмотрите здесь.


PKCS # 5 padding означает отступы от 1 до 8 байтов. Сами байты заполнения содержат количество байтов заполнения, закодированных в виде байта. Для DES было задано дополнение PKCS # 5, но оно было бы подходящим для любого блочного шифрования с размером блока 8 байтов.

Теперь спецификации DES и даже спецификация PKCS # 5 для шифрования с паролем предшествуют и Java довольно долгое время. AES была стандартизирована только в 2002 году, после Java и даже Java 2. Таким образом (тройной) DES и PKCS # 5 padding был интегрирован в Java до появления AES.

Когда Java - или, точнее, поставщик Sun JCE - получил функциональность AES, ему потребовался метод заполнения для размера блока 16 байт. PKCS # 7 указывает этот метод заполнения, который идентичен дополнению PKCS # 5, за исключением того, что он определен для размеров блоков от 2 до 255 байтов (максимальное значение байта если он кодирует целое число без знака на основе нуля). Однако метод заполнения уже существует; он был назван "PKCS5Padding". Поэтому вместо того, чтобы вводить новое имя, "PKCS5Padding" просто повторно использовался.

Теперь поставщик Sun должен действительно поддерживать "PKCS7Padding", поскольку дополнение PKCS # 5 просто неверно. Это не просто проблема именования Java, это проблема для любого разработчика, который пытается реализовать криптографические протоколы или переносить другие приложения на Java. На данный момент, однако, вы должны использовать "PKCS5Padding" вместо "PKCS7Padding".