Поскольку были достигнуты значительные успехи в криптоанализе SHA1, он должен был быть поэтапно отменен в пользу SHA2 (wikipedia).
Однако для использования в качестве базовой хэш-функции в PBKDF2 он в основном используется как PRNG. Как таковой, должно быть еще безопасно использовать SHA1 как хэш для PBKDF2, правильно?
Ни одна из известных в настоящее время слабых сторон SHA-1 не влияет на ее безопасность при использовании в HMAC, тем более при использовании в PBKDF2. В этом отношении MD5 тоже будет хорошо (но не MD4).
Однако SHA-1 не подходит для связей с общественностью: если в 2011 году вы используете SHA-1, тогда вы должны подготовиться к тому, чтобы оправдать этот выбор. С другой стороны, SHA-256 является прекрасной функцией по умолчанию, и никто не будет подвергать сомнению ее.
В PBKDF2 нет проблемы с производительностью (PBKDF2 включает в себя "счетчик итераций", предназначенный для того, чтобы сделать его как можно медленнее по мере необходимости), поэтому очень мало оснований предпочитать SHA-1 над SHA-256 здесь. Однако, если у вас есть существующая развернутая система, которая использует PBKDF2-SHA-1, то нет необходимости немедленно ее исправлять.
Атаки на SHA1, которые вызвали много публичных потрясений, позволяют построить сообщение, имеющее такой же хеш, как и другое сообщение. Это, конечно, всегда возможно (в принципе) для каждой хэш-функции, поскольку хэш-функция имеет меньше выходных битов, чем входные биты. Однако, как правило, это случается не случайно, а делать это специально должно быть невозможно вычислить.
С точки зрения "обеспечить целостность сообщения" это можно рассматривать как катастрофу.
С другой стороны, с целью генерации случайных чисел это не имеет никакого отношения.
Конечно. SHA-256 или больше, может быть более эффективным, если вы хотите генерировать больше ключевых материалов. Но PBKDF2-HMAC-SHA1 в порядке. Также стандартное использование HMAC не было скомпрометировано, но опять же, более длинные хэши в принципе более безопасны в этом сценарии.