PBEKeySpec, на что влияют параметры iterationCount и keyLength? - PullRequest
Новая
       60

PBEKeySpec, на что влияют параметры iterationCount и keyLength?

19 голосов
/ 25 мая 2011

Погружаясь в мир шифрования и хеширования Java, я вижу примеры конструктора для класса PBEKeySpec с различными значениями для параметров iterationCount и keyLength. Кажется, ничто не объясняет, что эти параметры влияют или значат.

Я предполагаю, что keyLength - это длина ключа, поэтому 32-битное шифрование будет принимать значение 32 для длины ключа, но это предположение кажется неверным. Я предполагаю, что iterationCount - это число раз, когда каждый символ шифруется, опять же не чувствуя любви в этом предположении.

Ссылки на информацию или объяснения приветствуются.

1 Ответ

32 голосов
/ 26 мая 2011

Количество итераций - это количество раз, которое пароль хэшируется во время получения симметричного ключа. Чем больше число, тем сложнее проверить правильность пароля и затем получить правильный ключ. Он используется вместе с солью, которая используется для предотвращения атак с использованием радужных столов. Количество итераций должно быть как можно выше, не слишком сильно замедляя работу вашей системы. Более общий термин для подсчета итераций: коэффициент работы .

Длина ключа - это длина в битах производного симметричного ключа. Ключ DESede может иметь длину 128 или 192 бита, включая биты четности. Ключ AES может иметь длину 128, 192 или 256 бит. Проблема заключается в том, что API не указывает, какая длина ключа (биты / байты, с четностью или без нее) имеется в виду; для PBEKeySpec размер ключа - биты, включая биты четности, как показано в этом разделе.

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

Примечания:

  • Для получения дополнительной информации, пожалуйста, посмотрите стандарт , стандарты PKCS, как правило, относительно легко читаются.
  • Соль просто должна быть уникальной; обычно это достигается путем создания 64–255-битной полностью случайной соли с использованием безопасного генератора случайных чисел (что для Java означает использование new SecureRandom(), а затем nextBytes(int amount)). Соль может быть общедоступной и храниться с зашифрованным текстом или паролем.
  • Указание любого значения, превышающего размер вывода хэша (по умолчанию это SHA-1, размер вывода 160 бит) для размера ключа, может дать сбой (для PBKDF1) или привести к дополнительному замедлению (для PBKDF2). Не рекомендуется; просто используйте хеш-функцию, такую ​​как SHA-256, SHA-512 в спецификации алгоритма.
  • SHA-1 (иногда просто называемый SHA, поскольку SHA-0 никогда не использовался) и даже MD5 по-прежнему полностью безопасны для такого рода функций (поскольку они не зависят от сопротивления столкновению), но вы следует по-прежнему выбирать более безопасный вариант, например SHA-256 или SHA-512 для новых протоколов.
...