Primero, todavía no hay "SHA-3 real". En unos pocos meses, NIST publicará una especificación que definirá de forma inequívoca qué es SHA-3. A menos que haya una gran equivocación en alguna parte, podemos predecir que SHA-3 será compatible bit a bit con la especificación de Keccak presentada para la ronda 3 de la competencia.

Entonces no hay razón para reemplazar SHA-2 con (futuro-) SHA-3: ni científicamente (SHA-2 no está roto, ni mucho menos; y, para el rendimiento, Keccak no es terriblemente mejor que SHA-2 , y a menudo peor, dependiendo de la arquitectura), ni administrativamente (las propias personas del NIST sostienen que no es necesario reemplazar SHA-2 por SHA-3).

Hay razones para reemplazar MD5 y SHA-1 con SHA-2 (o SHA-3 en el futuro), pero estas razones ya eran válidas la semana pasada y ya deberías hacerlo.

Agilidad del algoritmo es una calidad importante de los protocolos , pero esa es una cuestión de diseño del protocolo. Las personas que están calificadas para diseñar protocolos de seguridad ya lo saben, y el otro debe abstenerse de diseñar protocolos.

Las funciones de hash son bastante nuevas, y aún estamos descubriendo nuevos ataques de criptoanálisis contra ellas. SHA-3 parece útil, por lo que no estoy de acuerdo con los comentarios de Schneier sobre un no premio . Sin embargo, deberíamos planear tener una competencia SHA-4 en un futuro cercano. Ser capaz de cambiar la función hash en la que confía es una característica útil. SSL / TLS es un buen ejemplo de esto.