Значение для итерации: случайное число не должно быть случайным числом. Это количество итераций, которое определяет стоимость PBKDF2. Предполагается, что в приложении он должен быть установлен настолько высоким, насколько это допустимо, и защита, обеспечиваемая PBKDF2 от перебора пароля, возрастает примерно линейно с этим параметром. Далее я предполагаю высокую итерации (скажем, базовый уровень сто тысяч), и что соль как-то сохраняется. Я также предполагаю, что используется HMAC-SHA-1 (по умолчанию) или HMAC-SHA-256 (также распространено).
Насколько нам известно, основным недостатком описанного является то, что можно проверить парольную фразу, запустив generateKey, а затем протестировав соответствующий ключ, используя известную криптограмму AES. В том, что "не заботясь о парольной фразе"? Мне это непонятно.
Проблема в том, что злоумышленники могут запускать PBKDF2 на очень высокой скорости, используя GPU, FPGA или ASIC. Когда итерации высок (как и должно быть), PBKDF2 является узким местом сгенерировать ключ и поиск пароля. Таким образом, злоумышленники могут искать пароли на несколько порядков быстрее, чем обычные пользователи, использующие CryptoJS. С точки зрения усложнения поиска пароля, что является его основной целью в этом вопросе, PBKDF2, таким образом, является одним из наихудших возможных вариантов использования резервной мощности процессора для растяжка ключей когда дело доходит до сильных противников. Намного лучшие варианты Argon2, scrypt или даже bcrypt.
Вы решаете, случайно ли то, что NIST ранее рекомендовал PBKDF2, и по-прежнему не требует использования чего-то лучшего; как это раньше толкнуло Dual_EC_DRBG, с очевидным намерением позволить американской разведке взломать эту криптовалюту. Можно применить бритву Хэнлона, но я больше уважаю ученых NIST.
