Поскольку в криптоанализе SHA1 произошли значительные успехи, предполагается, что он будет постепенно отменен в пользу SHA2 (wikipedia).Является ли SHA1 еще безопасным для использования в качестве хеш-функции в PBKDF2?
Для использования в качестве базовой хеш-функции в PBKDF2, однако, в основном используется как PRNG. Таким образом, должно быть безопасно использовать SHA1 как хэш для PBKDF2, правильно?
Ни в одном из известных в настоящее время слабых мест на SHA-1 не влияет на его безопасность при использовании в HMAC, a fortiori при использовании в 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 не было скомпрометировано, но опять же, более длинные хэши в принципе более безопасны в этом сценарии.
Существует также довольно хорошее объяснение в [Stack Crypto] (http://crypto.stackexchange.com/questions/15218/is-pbkdf2-hmac-sha1-really-broken). Короче говоря, коллизии для паролей - это не плохо, это просто означает, что злоумышленник (или действительный пользователь) может войти в систему с паролем разных паролей, чтобы не вернуться к исходному «реальному» паролю. –