¿Deberíamos estar usando SHA3? (2017)

No estoy convencido de que debamos . SHA-3 tiene algunos nice features con seguridad, pero por los motivos que enumero a continuación, probablemente sugiera usar SHA-2 o BLAKE2 por el momento. Incluso los NIST mismos dicen:

  

Actualmente no es necesario realizar la transición de aplicaciones de SHA-2 a SHA-3.

Dicho esto, es posible que aún estés pensando "¿por qué no" ?

1. SHA-3 aún no cumple con FIPS-140 . Sin FIPS 140-3 , está fuera del alcance de agencias gubernamentales no militares y contratistas gubernamentales. Si está preocupado por el cumplimiento de FIPS, está atascado con el paquete SHA-2 por ahora. SHA-3 fue incluido en FIPS 140-2 Anexo A , y aunque este documento todavía dice" Borrador "en la portada parece que se ha finalizado a través de estas two páginas.
2. Rendimiento . SHA-3 es increíblemente rápido en implementaciones de hardware (ASIC) . Sin embargo, es mucho más lento en software que se ejecuta en CPU con registros limitados, lo que significa que generalmente es menos útil *. Su principal competidor (al menos, después de la competencia) es BLAKE2, que ha demostrado ser mucho más rápido en las CPU generales y, a veces, se prefiere sobre Keccak / SHA-3 por otras razones . Si bien creo que el NIST subestimó las diferencias de rendimiento en el software entre los finalistas, sus comentarios sobre el desempeño en la última ronda de toma de decisiones pueden ser útiles para proporcionar contexto. De NISTIR 7896 , sección 3.2:

     

   a. Los cinco finalistas tienen un desempeño lo suficientemente bueno como para poder usarse en la mayoría de las aplicaciones.
     segundo. Ninguno de los cinco finalistas es el mejor para cada aplicación, y ninguno ofrece mejoras realmente convincentes sobre los algoritmos SHA-2.   do. Los algoritmos basados en ARX, BLAKE y Skein, funcionan extremadamente bien en software.
     re. Keccak tiene una clara ventaja en rendimiento de rendimiento / área en implementaciones de hardware.
     mi. Grøstl y JH son considerablemente más lentos que los otros tres algoritmos en la mayoría de las implementaciones de software.

3. prudencia potencialmente innecesaria . También vale la pena señalar que BLAKE obtuvo comentarios negativos debido a qué tan similar fue a SHA-2. Por prudencia, esto ayudó a Keccak / SHA-3 a ganar la competencia. De NISTIR 7896 , sección 3.4:

     

   b. Debido a que SHA-2 es un diseño basado en ARX con un programa clave, tiene algunos elementos de diseño importantes en común con BLAKE y Skein, aunque ninguno de ellos está estrechamente relacionado con SHA-2. Sin embargo, es más probable que las herramientas criptoanalíticas que se aplican a SHA-2 en el futuro se apliquen a BLAKE o Skein que a los otros tres finalistas.

* Recuerda que estamos discutiendo las funciones de hash criptográficas aquí, no necesariamente las funciones de hashing de contraseña o KDF.

Algunas lecturas más que pueden valer la pena:

1. Es posible que NIST no te tenga en cuenta , por Adam Langley
2. La familia de funciones de esponja Keccak
3. NISTIR 7896
4. BLAKE2: “Más difícil, mejor, más rápido, más fuerte” que MD5
5. ¿Por qué reemplazar SHA-1 con BLAKE2?
6. Quizás omitir SHA-3

Debería estar usando el cifrado más fuerte que pueda, y SHA3 parece ser adecuado. Aunque estás adelantado a tu edad, ya que casi nadie lo usa. Ni siquiera OpenSSL es compatible con SHA3. La cuestión es que, en general, SHA2 aún se considera seguro, y para un sistema complejo, sería mejor que eligiera SHA2 sobre SHA3 para evitar problemas de incompatibilidad.

Mire este gráfico: enlace

¿Qué crees que deberías estar usando?

Como regla general, debe usar el método de hashing más potente disponible en ese momento (en este caso, SHA-3), a menos que tenga una razón convincente para no hacerlo, como:

• Compatibility

• Rendimiento

• Requisitos reglamentarios (por ejemplo, debe utilizar la implementación criptográfica validada FIPS)

Entonces, si no puedes usar SHA-3, el siguiente mejor sería SHA-2.