¿Debo usar constantes propias cuando uso algoritmos de hashing bien conocidos?

No. Las constantes son parte de lo que hace que el hash sea seguro, y las constantes en las especificaciones son las que se han utilizado en los exámenes de la comunidad criptográfica de las funciones de hash que actualmente creemos que son seguras. Se ha demostrado que las constantes mal elegidas intencionalmente pueden romper una función de hash de manera sutil pero explotable , y crear sus propias constantes podría inadvertidamente Te deja con una función de hash débil también.

No, debido a razones que ya ha indicado: no diseñe sus propios algoritmos. Puede obtener resistencia de las tablas de arco iris utilizando sales únicas , no es necesario alterar las constantes de su algoritmo de hash. Los algoritmos han sido sometidos a un criptoanálisis exhaustivo por expertos internacionales, como para NIST SP800-90 Dual Ec Prng , es probable que no tengas los recursos para hacer lo mismo para tus constantes. Sin embargo, en la mayoría de los casos, los números se eligen muy aleatoriamente . Puede que incluso tenga ventajas al elegir sus propias constantes, en algunos casos, pero todavía no lo recomiendo.

Editar: fsmv ha señalado que no debes implementar los hashes usted mismo, pero use una biblioteca. Estoy de acuerdo. Si realmente quería usar sus propias constantes, obtenga una implementación de biblioteca conocida (tenga cuidado con la licencia) del algoritmo y aplique los cambios a ese código. Las implementaciones se han hecho resistentes a los ataques de canal lateral.

No soy un experto en seguridad, pero ¿no obtuvo la NSA una mala reputación por elegir intencionalmente constantes rompibles para uno de los estándares de NIST hace un tiempo?

Supongo que depende de tu modelo de amenaza. Si está preocupado por la NSA, tal vez debería contratar a los mejores criptógrafos del mundo y hacer que encuentren mejores constantes. De lo contrario, siga los estándares, porque es probable que estén bastante seguros contra otros agentes.

Respuesta corta: No

Las constantes son parte del algoritmo. Si no confías en las constantes, entonces no confíes en el algoritmo. Vale la pena ver algunos ejemplos.

Hashes de Merkle-Damgård

Una constante que podría cambiarse en tal algoritmo es la IV. Para el análisis de seguridad, cambiar el IV equivale a anteponer los datos con un bloque de material clave. Pero se preferiría el prefijado debido a que no es necesario cambiar el algoritmo real.

Sin embargo, ya es sabido que el hecho de preparar un material clave no es una buena forma de crear un hash con clave. Un mejor enfoque sería utilizar una construcción HMAC.

El IV no es la única constante en un hash Merkle-Damgård. También hay constantes en la función de compresión. Si elige sus propias constantes, existe un riesgo significativo de que sean débiles por alguna razón. Así que incluso si todas las investigaciones apuntan a que el original es seguro, su versión podría ser débil. Si se encuentra una debilidad en el algoritmo original, es poco probable que haya logrado encontrar mejores constantes.

De hecho, para encontrar mejores constantes en ese caso, básicamente habrías tenido que encontrar la debilidad y una solución. En otras palabras, si no pudiera escribir un documento sobre por qué sus constantes son mejores que los originales y conseguir que se acepte en un diario sobre criptografía, entonces sus constantes no son mejores.

DECDRBG

Este es un buen ejemplo de no confiar en las constantes. Las constantes originales vinieron sin ninguna explicación de cómo fueron construidas. Esa es una señal de advertencia y no se debe confiar en esas constantes.

Un análisis adicional de cómo se podrían haber construido esas constantes reveló una posible puerta trasera. El algoritmo completo ahora se considera sospechoso.

Si quisiera usar ese algoritmo, no debería usar las constantes originales que no son de confianza. Pero si generas tus propias constantes, ¿cómo podrías hacer que alguien más confíe en tus constantes?

De hecho, con el conocimiento que tenemos ahora, DECDRBG con constantes no estándar es una de las formas más simples de crear un algoritmo criptográfico con su propia puerta trasera y hacer que parezca un error inocente.

DECDRBG muestra por qué una vez que existe un escepticismo justificado acerca de las constantes en un algoritmo, no debe confiar en el algoritmo hasta que alguien presente un criterio real para decidir cuáles son las constantes buenas para el algoritmo.