Может ли PKCS5Padding работать в режиме AES/GCM?

Какой режим заполнения для AES/GCM? Я понял, что это может быть NoPadding, так как в режиме ECB это может быть PKCS5Padding, а как насчет режима GCM? в интерфейсе JCE нам нужно предоставить «алгоритм/режим/заполнение» (Ссылка).

Поэтому я использовал следующий код для получения экземпляра, и он работает в JDK, но не работает в IBM SDK, который говорит:

не могу найти провайдера для поддержки AES/GCM/PKCS5Padding

 Cipher.getInstance("AES/GCM/PKCS5Padding");

Каков реальный вариант использования заполнения?


person C.c    schedule 06.07.2015    source источник
comment
Заполнение описывает, как блоки в цепочке выравниваются и заполняются, чтобы соответствовать ожидаемому размеру блока. JRE может работать с другим поставщиком безопасности. Oracle SDK включает в себя собственный поставщик безопасности Oracle Security Provider с очень низким уровнем безопасности. Я не знаю, какой Security Prodiver используется по умолчанию в IBM SDK. Лучше всего включать своего собственного поставщика безопасности при работе с различными поставщиками JRE, такими как BouncyCastle. Или используйте поставщика безопасности целевой системы в системе разработки, например, при разработке для Android, где поставщиком безопасности OpenSSl является значение по умолчанию. надеюсь, это поможет   -  person Rene M.    schedule 06.07.2015
comment
Это лучший поставщик безопасности, который я знаю: bouncycastle.org/java.html   -  person Rene M.    schedule 06.07.2015
comment
Спасибо за ответ, мне не нужно вводить третьи библиотеки. поэтому мне нужно использовать встроенный поставщик JDK. как SUNJCE, но в IBM sdk, я думаю, он предоставляет своего собственного провайдера, но, тем не менее, мой вопрос в том, является ли AES/GCM/PKCS5Padding законным значением? Я не нашел ни одного примера использования PKCS5Padding в GCM и даже isaacyang1988.googlecode.com/svn/trunk/Crypt/src/org/ в этой статье есть тестовый пример, подобный тому, что это неправильный шаблон   -  person C.c    schedule 06.07.2015
comment
Посмотрите на ответ от Артёма. В противном случае напишите программу, которая проверяет поставщика безопасности по умолчанию для вашего jre и распечатывает возможные значения для желаемого алгоритма. Выберите значения, которые существуют с обеих сторон, и все в порядке   -  person Rene M.    schedule 06.07.2015


Ответы (1)


GCM — это потоковый режим, который означает, что длина зашифрованного текста равна длине открытого текста (без тега аутентификации). GCM не требует заполнения. Это означает, что версия PKCS5Padding на самом деле является лишь синонимом NoPadding для удобства при программировании. У некоторых провайдеров нет этого странного режима.

Это случаи, когда заполнение открытого текста имеет смысл. Например, вы можете скрыть длину фактического открытого текста, добавив случайную длину PKCS5Padding.

person Artjom B.    schedule 06.07.2015
comment
Спасибо, это говорит о том, что нам нужно исправить Cipher.getInstance(AES/GCM/NoPadding); Правильно? - person C.c; 06.07.2015
comment
Да, Cipher.getInstance("AES/GCM/NoPadding"); правильный путь. Вероятно, это то же самое, что и с Cipher.getInstance("RSA/ECB/PKCS1Padding");, который на самом деле всего лишь Cipher.getInstance("RSA/None/PKCS1Padding");. - person Artjom B.; 06.07.2015
comment
Понятно. Большое спасибо. - person C.c; 06.07.2015
comment
У меня нет поставщика IBM, но вы можете проверить, совместимы ли они оба. С помощью (1) шифрования с дополнением и дешифрования без заполнения и (2) шифрования без заполнения и дешифрования с дополнением. - person Artjom B.; 06.07.2015
comment
Привет, @ArtjomB., ты мне очень помог с моими вопросами по криптографии. Я использую алгоритм PBKDF2WithHmacSHA256 для хеширования паролей. Он работает на живом сервере. Но я, кажется, не работаю с Java 7, а только с Java 8. Могу ли я каким-либо образом использовать этот алгоритм в Java 7? - person The Coder; 06.07.2015
comment
@user1354678 user1354678 Я точно не знаю, но думаю, что у меня это сработало в Java 7. Вы можете попробовать добавить поставщика BouncyCastle, который, вероятно, обеспечивает это. - person Artjom B.; 06.07.2015
comment
@ArtjomB. Любая идея, почему SonarQube дает мне Убедитесь, что шифрование данных безопасно здесь для Cipher.getInstance("RSA/ECB/PKCS1Padding"); и Cipher.getInstance("AES/GCM/NoPadding");. Они больше не в безопасности? В документации (rules.sonarsource.com/java/RSPEC-4787) говорится что Режим Галуа/Счетчик (GCM) без заполнения следует предпочесть следующим незащищенным комбинациям. Но все равно выдает ошибку... - person Dionis Beqiraj; 12.09.2019
comment
@DionisBeqiraj Случай RSA должен быть ясен, поскольку OAEP не используется. GCM сам по себе неплох, но имеет некоторые режимы отказа, когда одноразовый номер никогда не должен повторяться под одним и тем же ключом. Было бы лучше использовать двухпроходный режим, такой как AES-SIV, но это требует больших вычислительных ресурсов, а шифрование/дешифрование не может выполняться в потоковом режиме. Я не знаю точно, но это догадка. Это также может быть ошибка в наборе правил SonarQube. - person Artjom B.; 13.09.2019
comment
@ArtjomB. Да, правильно, для RSA случая я должен реализовать OAEP, как было предложено. Но для AES это странно... ? - person Dionis Beqiraj; 13.09.2019