2011-02-08 13 views

Respuesta

20

Ninguna de las debilidades actualmente conocidas en SHA-1 tiene ningún impacto en su seguridad cuando se utiliza en HMAC, a fortiori cuando se utiliza en PBKDF2. Para el caso, MD5 estaría bien también (pero no MD4).

Sin embargo, SHA-1 no es bueno para las relaciones públicas: si, en 2011, usa SHA-1, entonces debe prepararse para tener que justificar esa elección. Por otro lado, SHA-256 es una fina "función por defecto" y nadie lo cuestionará.

No hay problemas de rendimiento en PBKDF2 (PBKDF2 incluye un "recuento de iteraciones" destinado a hacerlo exactamente tan lento como sea necesario) así que hay muy pocas razones para preferir SHA-1 sobre SHA-256 aquí. Sin embargo, si tiene un existente, sistema implementado que utiliza PBKDF2-with-SHA-1, entonces no hay necesidad inmediata de "corregirlo".

+1

También hay una explicación bastante buena en [Stack Crypto] (http://crypto.stackexchange.com/questions/15218/is-pbkdf2-hmac-sha1-really-broken). En resumen, las colisiones de contraseñas no son malas, solo significa que un usuario malintencionado (o un usuario válido) podría iniciar sesión con un par de contraseñas diferentes, pero no que pueda volver a la contraseña "real" original. –

0

Los ataques a SHA1 que causaron mucha agitación pública hacen posible construir un mensaje que tiene el mismo hash que un mensaje diferente. Esto, por supuesto, siempre es posible (en principio) para cada función hash, ya que una función hash tiene menos bits de salida que bits de entrada. Sin embargo, normalmente no es probable que ocurra por accidente, y hacerlo a propósito no debería ser computacionalmente factible.

Desde el punto de vista de "garantizar la integridad del mensaje", esto puede verse como un desastre.

Por otro lado, con el fin de generar números aleatorios, esto no tiene absolutamente ninguna relación.

0

Sure. SHA-256, o superior, podría ser más eficiente si desea generar más material clave. Pero PBKDF2-HMAC-SHA1 está bien. Además, el uso estándar de HMAC no se ha visto comprometido, pero, una vez más, los hashes más largos son en principio más seguros en ese escenario.

Cuestiones relacionadas