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

20

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

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

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

Обратите внимание, что ECB не является безопасным CPA, вместо этого используйте CBC (если вы просто хотите сохранить конфиденциальность хранимых данных). Maarten Bodewes

Ваш Ответ

3   ответа
34

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

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

И чтобы добавить к путанице, .NET вызвать точно такой же алгоритм заполненияPKCS7 padding.
Этот ответ хорошо, но немного сбивает с толку, потому что выdo хочу использовать заполнение PKCS # 7 для блочного шифра. Это просто такPKCS7Padding неправильное имя, согласноStandard Algorithm Names. PKCS # 7 использует эту схему дополнения для дополнения сообщений, зашифрованных блочными шифрами. Не имеет значения, что представляет собой более широкий контекст.
Правильный. Это не так (ну, так как # 5 и # 7 - это одно и то же дополнение ... Я думаю, вы могли бы сказать, что это так?). И добро пожаловать. Не забудьте принять ответ, если вы довольны им. :)
В то время как Java считает, что отступы PKCS5 и PKCS7 являются "одинаковыми" (и всегда следует использовать строку «AES / CBC / PKCS5Padding», потому что «AES / CBC / PKCS7Padding» вызовет исключение NoSuchAlgorithmException при инициализации блочного шифра AES с использованием API-интерфейса шифрования Java), я считаю это грубым неправильным назначением в платформе Java, потому что чисто технические определения этих отступов не совпадают. PKCS5 явно определяет размер своего блока как строго 8 байтов, в то время как PKCS7 определен для размеров блоков от 1 до 255 (с размерами блоков 8 байтов то же самое, что и PKCS5).
Ответ вроде верный, но объяснения точно нет. Если спецификация является какой-либо индикацией, то заполнение PKCS # 5 следует использовать только для шифрования на основе пароля, поскольку именно это определяет PKCS # 5. Запретить заполнение PKCS # 7 в качестве общего дополнения для блочного шифра, поскольку PKCS # 7 в основном определяет синтаксис криптографических сообщений, поэтому является двухъярусным. Только последнее предложение имеет смысл (но, к счастью, это большая часть ответа)
3

включающее текст стандартов шифрования PKCS # 5 и PKCS # 7, пожалуйста, посмотритеВот.

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

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

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

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

1

то bouncy castle будет поддерживать htф: //www.bouncycastle.org/specifications.html

Верно, но это тот же алгоритм заполнения снизу.

Похожие вопросы