Asegurar una suma de comprobación

Dos preguntas, de verdad.

1. No. Nunca nunca Mala idea. Mal mal mal mal mal Nunca asumas que concatenar múltiples cosas inseguras hace que estés seguro porque, ya sabes, probablemente debería ser más seguro. Puede obtener un poco de seguridad a través de la oscuridad, pero recuerde que los hashes están rotos . Se encuentran fallas fundamentales en el modelo matemático que proporciona garantías de seguridad. No está claro de inmediato si dos algoritmos rotos pueden romperse juntos fácilmente, a menos que tenga los antecedentes matemáticos necesarios para romper criptografía en primer lugar. Nunca lo hagas de esta manera.

   • Como ejemplo trivial, considere el siguiente conjunto de sumas de comprobación: MD-5, CRC8-AUTOSAR y CRC-32. Mediante el uso de 3 sumas de comprobación, sin duda debería ser más seguro ¿verdad? No. Encontrará que los dos CRC agregan un 0% más de seguridad que el MD-5 y el MD-5 está roto, por lo que esas tres sumas de comprobación no harán nada por usted.

2. Sí, puede usar HMAC para proporcionar códigos de autenticación de mensajes basados en hash y luego eliminar el bit de autenticación al publicar la clave. Si eliminas las palabras que no se aplican, te quedas con "código hash". Sí, si hash algo con un algoritmo de hash seguro, el resultado será seguro. Por supuesto, puedes ahorrarte un montón de tiempo con solo usar el hash.

3. La mejor opción es la que no mencionó: descubra qué algoritmos hash son seguros y solo use uno.

Finalmente, enfócate en las partes débiles de tu sistema. Describe un caso en el que los datos pueden ser atacados, pero nadie atacará la suma de control. Esa es una situación bastante extraña. El único caso que conozco donde ocurre es cuando uno descarga un archivo desde una ubicación no confiable y luego descarga su firma desde una ubicación confiable para minimizar el ancho de banda requerido por parte de la ubicación confiable. Asegúrese de que el resto de su sistema sea seguro. Como señala Bruce Schneier, ¡muy raramente el cripto es en realidad la parte débil del enlace!

En cuanto use la frase "compartir el secreto junto con el hash generado", estará en un terreno inestable. Los hash son públicos, cualquiera puede generarlos y cualquiera puede verificarlos. Los "secretos" son secretos. Necesita un canal seguro para comunicarse, o no son secretos. HMACs trabajan entre las partes con el secreto ya. Herramienta adecuada para el trabajo correcto.

El propósito de un hash es detectar la corrupción (violación de integridad), ya sea accidental o deliberada. Si bien puede ser trivial generar una colisión MD5 arbitraria, aún es difícil crear un texto plano significativo contra una suma MD5 específica.

Entonces, ¿cuál es el propósito de tu hash? Si es contra el ruido en la línea (corrupción accidental), md5 está bien. Si es contra un atacante activo que subvierte su texto simple (lo que supongo de la pregunta), ¿qué modelo de amenaza supone que la suma de comprobación no se puede modificar si el texto simple puede?

Si su pregunta es "¿sería más difícil encontrar un solo documento que colisionara con dos algoritmos de suma de verificación diferentes?", la respuesta es claramente sí. ¿Pero por qué? ¿Qué estás tratando de lograr?

Si le preocupa la fuerza de cualquier algoritmo de hashing en particular, use uno más fuerte. Por supuesto, puede usar dos o más algoritmos, pero para obtener algún beneficio, todos los destinatarios tendrían que verificar todos los hashes.

Creo que es probable que algunos clientes (software o humanos) solo marquen uno, en cuyo caso su hash múltiple no es útil.

Mi recomendación sería utilizar una función hash más resistente a las colisiones.