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

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

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

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


java encryption aes security jce
person Suby Lee    schedule 17.04.2012    source источник
comment
Обратите внимание, что ECB не защищен CPA, вместо этого используйте CBC (если вам просто нужна конфиденциальность хранимых данных).   -  person Maarten Bodewes    schedule 25.01.2015

Ответы (4)


arrow_upward
46
arrow_downward

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

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

person Community    schedule 17.04.2012
comment
Большое спасибо за ваш ответ. Тогда провайдер JCE не поддерживает PKCS7PADDING? - person Suby Lee; 17.04.2012
comment
Правильный. Это не так (ну, поскольку # 5 и # 7 - это одно и то же заполнение ... я думаю, вы могли бы сказать, что это так?). Пожалуйста. Не забудьте принять ответ, если он вас устраивает. :) - person ; 17.04.2012
comment
Этот ответ в порядке, но немного сбивает с толку, потому что вы действительно хотите использовать заполнение PKCS #7 для блочного шифра. Просто PKCS7Padding — это неправильное имя, согласно Стандартные имена алгоритмов. PKCS #7 использует эту схему заполнения для заполнения сообщений, зашифрованных блочными шифрами. Неважно, каков более широкий контекст. - person erickson; 17.04.2012
comment
И чтобы добавить путаницы, .NET вызывает точно такой же алгоритм заполнения заполнение PKCS7. - person President James K. Polk; 18.04.2012
comment
В то время как Java считает заполнение PKCS5 и PKCS7 одинаковым (и всегда следует использовать строку AES/CBC/PKCS5Padding, потому что AES/CBC/PKCS7Padding вызовет исключение NoSuchAlgorithmException при инициализации блочного шифра AES с использованием криптографического API Java), я считайте это грубым неправильным названием на платформе Java, потому что чисто технические определения этих дополнений не совпадают. PKCS5 явно определяет размер своего блока как строго 8 байтов, в то время как PKCS7 определяется для размеров блоков от 1 до 255 (с размером блока 8 байтов это то же самое, что и PKCS5). - person peabody; 04.09.2014
comment
Ответ вроде правильный, но объяснение точно нет. Если в спецификации указано какое-либо указание, то заполнение PKCS#5 следует использовать только для шифрования на основе пароля, поскольку именно это указывает PKCS#5. Чтобы запретить заполнение PKCS#7 в качестве общего заполнения для блочного шифра, потому что PKCS#7 в основном определяет синтаксис криптографического сообщения, это ерунда. Только последнее предложение имеет смысл (но, к счастью, это большая часть ответа) - person Maarten Bodewes; 25.01.2015
comment
Чтобы моя криптографическая библиотека на Java и .NET понимала друг друга, я должен использовать PKCS#5 (Java) ~ PKCS7 (.NET). Боже, спасибо за вызов... - person Hoàng Long; 09.03.2016
comment
2020: полезное в отношении расшифровки java6 для значения, зашифрованного с помощью java8, было сделано с общими кодами, что привело к исключению NoSuchMethodException, возможно, из-за общего кодека 1.2 в довольно старом пути к классам JBOSS - СПАСИБО :) - person Gunnar; 28.07.2020

arrow_upward
3
arrow_downward

если вы хотите использовать AES/ECB/PKCS7Padding, то надувной замок будет поддерживать http://www.bouncycastle.org /спецификации.html

person kapil das    schedule 15.10.2013
comment
Верно, но это тот же алгоритм заполнения внизу. - person Maarten Bodewes; 25.01.2015

arrow_upward
3
arrow_downward

Подробное объяснение проблемы, включающее текст криптографических стандартов 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".

person Maarten Bodewes    schedule 24.01.2015

arrow_upward
0
arrow_downward

Решение: Шаг 1. Добавьте bcprov-ext-jdk16-1.46.jar (https://mvnrepository.com/artifact/org.bouncycastle/bcprov-ext-jdk16/1.46) в свой проект

Шаг 2: добавьте строку «Security.addProvider (новый BouncyCastleProvider ());» установить общий шифр init

Затем запустите проект, OK, успешно расшифрован.

person Tran Hao    schedule 20.03.2020