A partir de esta mañana, cualquier hash SHA-1 puede colisionarse oficialmente por tan solo $ 110k en potencia de GPU en Amazon.
Obviamente, esto significa que para muchas aplicaciones, SHA-1 es completamente inútil y que en los próximos años habrá seguido el camino del MD5.
Pregunta :
Parece que con el tiempo decidimos que la mejor manera de hacer las cosas más seguras es crear algoritmos que necesiten cada vez más entropía de bits y más y más potencia de procesamiento de CPU, lo que parece una solución falsa.
Si la entropía de 128 bits es suficiente entropía (es decir, AES-128 es preferible a AES-256), ¿por qué no creamos algoritmos que puedan manejar mejor la entropía de 128 bits?
Además, en lugar de pasar a algoritmos en los que también se encontrarán fallas que aumentarán drásticamente la CPU, la memoria y los requisitos de almacenamiento (hay una GRAN diferencia entre el MD5 y el SHA-256 cuando se realiza la computación en un teléfono o una pi de frambuesa), ¿por qué no emparejamos dos algoritmos imperfectos juntos?
Por ejemplo: no podríamos ejecutar 512 bits a través del algoritmo MD5 y luego ejecutar esos mismos 512 bits a través de un SHA-1 y hacer un simple mux sobre el resultado combinado y aunque ambos algoritmos tienen ataques conocidos, la coincidencia de un atacante que encuentre cualquier conjunto de bits que se alinee en las tablas de ambos algoritmos parece que sería bastante seguro. O simplemente digiera el MD5 a la inversa en cada bloque y esparza algunos de los bits fuente anteriores cada n bloques: puede leer un bloque hacia adelante, invertir los bits, pasarlo al revés y luego continuar con el siguiente bloque y después de 16 bloques el enésimo bit de los bloques fuente originales, tal vez incluso tenga una ventana móvil en él, con menos de 1k de memoria en un momento dado.
Parece que estamos tratando de encontrar esta única solución matemática definitiva para entropiar a algo que podría resolverse mucho más simple con dos o tres soluciones matemáticas más simples que están fuera de banda entre sí y esto sería más rápido, más memoria eficiente, más almacenamiento eficiente y más seguro que cualquier algoritmo único.
¿Hay algún fallo en mi razonamiento?
Esto NO ES UN DUPLICADO
El otra pregunta es hablar sobre tomar el resultado final de un hash en serie con otro (enlace más débil):
f(g(x)) => y
Mi pregunta es sobre el uso de múltiples hashes simultáneamente en cada bloque para evitar debilidades (exclusión mutua de vulnerabilidades)
for n of x:
f(x[n]) \
(x[n]')XOR(x[n]'') => y
g(x[n]) /
Debido a que la pregunta es diferente, las respuestas también son diferentes.