Вопрос-ответ

InvalidKeyException Illegal key size

InvalidKeyException Недопустимый размер ключа

У меня есть тест, который отлично работает на моем MacBook Pro для разработки, но не запускается на сервере TeamCity непрерывной интеграции.

Ошибка заключается в следующем:

java.security.InvalidKeyException: Illegal key size
    at javax.crypto.Cipher.a(DashoA13*..)
    at javax.crypto.Cipher.init(DashoA13*..)
    at javax.crypto.Cipher.init(DashoA13*..)

И development box, и TeamCity используют Java 1.6, а я использую библиотеку BouncyCastle для необходимости специального шифрования AES.

Код следующий:

private byte[] aesEncryptedInfo(String info) throws UnsupportedEncodingException, IllegalBlockSizeException, BadPaddingException, InvalidKeyException, NoSuchAlgorithmException, NoSuchPaddingException, InvalidParameterSpecException, InvalidAlgorithmParameterException, NoSuchProviderException {
    Security.addProvider(new BouncyCastleProvider());
    SecretKey secret = new SecretKeySpec(CUSTOMLONGSECRETKEY.substring(0, 32).getBytes(), "AES");
    Cipher cipher = Cipher.getInstance("AES/CBC/PKCS7Padding", "BC");
    cipher.init(Cipher.ENCRYPT_MODE, secret, new IvParameterSpec(VECTOR_SECRET_KEY.getBytes()));
    return cipher.doFinal(info.getBytes("UTF-8"));
}

Обновить

Похоже, что в соответствии с выбранным ответом я должен что-то изменить в своей установке TeamCity, и это, возможно, повлияет на установки некоторых пользователей - так что это не лучший выбор, я должен переключиться на другую криптографическую библиотеку, чтобы сделать это без ограничений. Так что, вероятно, bouncy castle поможет.

ОБНОВЛЕНИЕ 2

На самом деле я перешел на использование BouncyCastle, чтобы избежать этого ограничения. Обратите внимание, это работает, только если вы используете собственные классы BC напрямую, а не поставщика BC.

Переведено автоматически
Ответ 1

Эта ошибка означает, что ваша виртуальная машина Java использует политику, которая допускает только ограниченный размер ключа шифрования из-за законов США об экспорте.

Java 9 и выше

Файлы политики юрисдикции с неограниченной надежностью включены в Java 9 и используются по умолчанию (см. Обновления безопасности в Руководстве по миграции Java 9).

Если вы получаете эту ошибку в Java 9, это может означать, что конфигурация политики была изменена на более ограничительную политику (limited), смотрите инструкции из руководства по миграции:


Файл политики юрисдикции JCE по умолчанию неограничен


Если вашему приложению ранее требовались файлы политики неограниченной надежности Java Cryptography Extension (JCE), то вам больше не нужно их загружать или устанавливать. Они включены в JDK и активированы по умолчанию.


Если для вашей страны или использования требуется более строгая политика, ограниченные файлы криптографической политики Java по-прежнему доступны.


Если у вас есть требования, которым не соответствует ни один из файлов политики, предоставляемых по умолчанию, то вы можете настроить эти файлы политики в соответствии с вашими потребностями.


Смотрите crypto.policy Свойство безопасности в <java-home>/conf/security/java.security файле или конфигурацию криптографической надежности в Java Platform, Standard Edition Security Developer's Guide.


Java 8 и более ранние версии

Обновление Java 8 161 и выше

Начиная с обновления 161 Java 8, в Java 8 по умолчанию используется политика неограниченной юрисдикции. Если вы получаете эту ошибку, это может указывать на изменение конфигурации на limited. Смотрите инструкции в следующем разделе Обновления 151 Java 8 или предыдущем разделе Java 9, чтобы изменить это значение обратно на unlimited.

Обновление Java 8 151 и выше

Начиная с обновления 151 Java 8, политика неограниченной юрисдикции включена в Java 8, но не используется по умолчанию. Чтобы включить его, вам необходимо отредактировать java.security файл в <java_home>/jre/lib/security (для JDK) или <java_home>/lib/security (для JRE). Раскомментируйте (или включите) строку

crypto.policy=unlimited

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

Изменение политики вступает в силу только после перезапуска JVM (это особенно важно для длительно работающих серверных процессов, таких как Tomcat).

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

До обновления Java 8 151

Для Java 8 Обновления 144 и более ранних версий необходимо установить Java Cryptography Extension (JCE) Unlimited Strength Juridity Policy Files (доступно на Oracle).

Чтобы установить эти файлы (из README.txt при загрузке):



  1. Загрузите файлы политики JCE с неограниченной надежностью.


  2. Распакуйте и извлеките загруженный файл.


    В результате будет создан подкаталог с именем jce. Этот каталог содержит следующие файлы:


    README.txt                   This file
    local_policy.jar             Unlimited strength local policy file
    US_export_policy.jar         Unlimited strength US export policy file

  3. Установите JAR-файлы политики неограниченной надежности.


    На случай, если позже вы решите вернуться к исходным "сильным", но ограниченным версиям политики, сначала создайте копию исходных файлов политики JCE (US_export_policy.jar и local_policy.jar). Затем замените файлы строгой политики версиями с неограниченной надежностью, извлеченными на предыдущем шаге.


    Стандартным местом для файлов JAR политики юрисдикции JCE является:


    <java-home>/lib/security           [Unix]
    <java-home>\lib\security           [Windows]


Обратите внимание, что для JDK он находится в jre / lib / security.

Новый файл политики вступает в силу только после перезапуска JVM (это особенно важно для длительно работающих серверных процессов, таких как Tomcat).

Ответ 2

У меня была похожая проблема, но в моем случае произошла ошибка пути.

JAVA_HOME был jdk1.6.0_18 , поэтому я поместил две банки в jdk1.6.0_18/lib/security, но внутри jdk1.6.0_18 находится jre каталог. Оба файла должны были быть помещены в jdk1.6.0_18/jre/lib/security.

Ответ 3

В дополнение к установке файлов политики, также убедитесь, что CUSTOMLONGSECRETKEY...getBytes() действительно создает массив из 32 байт. Я бы использовал CUSTOMLONGSECRETKEY.getBytes(some encoding) и получил из него первые 32 байта. А еще лучше, используйте весь секретный ключ для получения ключей для AES нужного вам размера.

Ответ 4

Я столкнулся с такой же проблемой для jdk 1.8.0_151-

Для этой и более ранних версий вам не нужно загружать файлы jar, связанные с безопасностью.Потому что, local_policy.jar и US_export_policy.jar уже включено в эти версии по пути- \jre \ lib \security \policy (JAVA_HOME ссылается на вашу текущую папку установки java) Единственная проверка, которую вам нужно сделать, находится в файле java.security, который присутствует в /jre/ lib/security - раскомментируйте строку - crypto.policy=неограниченно

2023-10-14 06:57 java