¿Puedo recuperar el contenido del archivo de su suma de comprobación / hash?

Una respuesta simple, NO.

Es como preguntar, si lo sé, que x%4 = 3 , ¿es posible encontrar el valor de x ? No. Seguramente, habría valores infinitos de x que satisfacen esta ecuación, pero simplemente no sabría cuál es el correcto.

De manera similar, muchos videoclips (o infinitos) podrían dar como resultado un valor hash dado (obviamente, los videoclips infinitos deben asignarse a un número específico de valores hash, por lo que es probable que se produzcan colisiones). No sabrías qué clip es correcto.

Eso también, en tiempo humano? No.

EDITAR: Como se señaló en los comentarios, dado que el archivo se divide en partes de 2 MB, no habrá posibilidades infinitas , pero sería bastante grande (2 aumentadas a una potencia de 16,7 millones, aproximadamente). La fuerza bruta en un número tan grande de posibilidades, en el tiempo humano, todavía es casi imposible. Pero sí, no es infinito .

Esto no es posible, no importa lo rápido que sea su computadora, simplemente porque no puede recrear la información correcta de prácticamente nada.

En realidad, está solicitando la restauración de 2 MB desde 32 bytes (tamaño de SHA-256) o como máximo 64 bytes (SHA-256 para el fragmento y para el archivo total). Esto sería una relación de 1: 65536 o 1: 32768. Dado que el video ya está muy comprimido, la probabilidad es prácticamente nula de que pueda restaurar los datos originales a partir de esta información. Puede ser que puedas crear un fragmento de 2 MB que dé como resultado los hashes SHA-256 específicos, pero es muy probable que este sea el fragmento original.

No se pudo reproducir el archivo en un período de tiempo razonable. La razón es que la única forma de "revertir" un hash es a través de la fuerza bruta, y teniendo en cuenta el tamaño del archivo original, le tomaría esa cantidad exacta de bytes para la fuerza bruta.

Supongamos que tiene un archivo de video de 100 MB de gran tamaño, con precisión.

• 1MB = 1,000,000 bytes
• 100MB = 100,000,000 bytes

Esto significa que deberías usar fuerza bruta en este archivo original y verificar que sea hash, deberías probar las permutaciones de n ^ r. Asumiendo que el archivo de video usa solo 256 caracteres por byte (ascii), estaríamos viendo:

256 ^100,000,000 & approx; 10 ^240,823,997 & approx; ∞

Eso es esencialmente infinito: básicamente, SIEMPRE se calculará esto, independientemente de los recursos de la CPU.

ACTUALIZACIÓN : también está, por supuesto, el problema con las colisiones hash que dejé aquí: con un hash Sha256, es probable que te encuentres con una cantidad infinita de colisiones. Con un archivo tan grande como nuestro ejemplo. Olvidé mencionar esto antes por simplicidad.

Supongamos que tiene una computadora que tiene una cantidad infinita de poder de procesamiento y que puede verificar de manera confiable todos los mensajes posibles contra cada hash posible en poco tiempo. Este es el problema al que te enfrentas ahora: collisions .

¿Qué es una colisión? Muchos archivos diferentes pueden coincidir exactamente con la misma firma. Muchos mensajes diferentes pueden coincidir exactamente con la misma firma.

El hash es one-way . Convierte una serie de caracteres en un hash. Cuando valida su hash, simplemente está comprobando si el mensaje coincide con el valor calculado del hash. El problema es que muchos mensajes diferentes pueden coincidir con este mismo hash. Se llama collision .

Sin embargo, como también tiene un poder computacional infinito, también puede reconstruir el archivo a través de prueba y error supermasivos. Sin embargo, una vez que tenga todos los ejemplos posibles para este valor hash, ¿cómo va a saber cuál es cuál?

¿Entonces me estás diciendo que hay una posibilidad?

Con la tecnología de hoy, y dado que nunca tendremos un poder computacional infinito, será completamente imposible. Incluso si se toma la potencia informática combinada de todo el mundo y se multiplica por mil millones, no se puede hacer esto. Incluso si de alguna manera hicieras esto, ¿cómo podrías saber qué mensaje era correcto?

¿Dónde se aplicaría mi idea?

• El hash es unidireccional . Con la clave proporcionada, solo valida que coincida con su hash calculado.
• El cifrado es bidireccional . Con la clave proporcionada, obtienes los resultados.

Tu idea se aplicaría bajo cifrado, no hash. Con el cifrado, si tiene la clave, puede obtener el contenido descifrado del archivo.

Es difícil si el archivo subyacente tiene suficiente entropía. Si sabe algo sobre los datos subyacentes, es posible que pueda recuperarlos. Por ejemplo, si hay un pirata informático en algún lugar cercano, no pasará mucho tiempo antes de que alguien le diga lo que he hecho con el md5:

73868cb1848a216984dca1b6b0ee37bc

Sin embargo, el video usualmente tiene mucha entropía, lo que hace que esta sea una causa perdida o al menos una muy difícil. Necesitarías que el video fuera una cámara de video y tendrías que esperar que la parte que falta muestre una hora de negro como la noche negra. Pongamos esto en perspectiva: crear un bitcoin es esencialmente una cuestión de invertir un hash. Invertir un fragmento de video muy corto es probablemente similar a hacer unos 20 bitcoins, tal vez más. Así que en tus zapatos yo haría las bitcoins, compraría una copia nueva del video y me guardaría el cambio. Casi ocho mil dólares en valor de cambio. Tal vez compraría acciones en una empresa de informática cuántica y facilitaría las futuras explotaciones; es divertido hacer lo "imposible".

Para aquellos que dicen, "los hashes son muchos a uno, por lo que no se puede decir qué fue": eso es cierto, pero de todos los muchos valores que tienen ese valor, algunos serán más plausibles que otros. Si invierte el hash anterior, no tendrá la menor duda de que ha encontrado la entrada correcta. ¡Que te diviertas! :-)

Un comentario pero es demasiado largo:

Como han demostrado otros, esto no es posible. Sin embargo, hay un problema relacionado que ciertamente es razonable:

Ok, no puedes reconstruir ese video de 200 mb que se dividió en 100 archivos de 2 mb de los cuales tienes 99.

Sin embargo, puedes crear otro archivo que se extienda a más de 2 mb y que te permita reconstruir cualquier archivo faltante de . Dos de estos archivos le permitirán reconstruir dos archivos faltantes, etc. Si bien el tamaño del bloque no se puede establecer de manera rentable más alto que el tamaño del archivo (un archivo de reparación de 4 mb todavía solo corrige un archivo faltante), se puede establecer más bajo, lo que puede ser valioso si existe la posibilidad de daños parciales. (El tiempo de cálculo aumenta, los archivos se vuelven un poco más grandes, pero tiene más capacidad para recuperarse del daño).

El programa estándar durante mucho tiempo fue: Quickpar pero no se ha actualizado en años. La alternativa más moderna que conozco (pero no he usado mucho todavía) es Multipar (Nota: este sitio está en japonés. Sin embargo, el programa está en buen inglés.)

Si voy a realizar una copia de seguridad de algunos datos en un DVD, habitualmente creo archivos de reparación adicionales en caso de que ocurra algo: el espacio adicional en el DVD se desperdiciará de todos modos, ¿por qué no poner un seguro allí? Multipar incluso tiene modos específicos para esto (aunque todavía no los he probado) donde generará bloques para llenar un disco DVD-R o BD-R.

Básicamente, tomará demasiado tiempo lograr un resultado satisfactorio, abordando ambos: generar la parte de video faltante (según criterios computables) y clasificar los mejores de ellos (eso necesita humanos). inteligencia o IA extremadamente desarrollada). Incluso si finalmente tienes un buen video que cumple todos los criterios, nunca sabrás si la película original tenía el mismo contenido. Puede que no tenga sentido intentar "reconstruir" algo que puede ser más variable, mejor y más rápido: usa tu propia fantasía.

Ciertamente, algunos valores de hash de 10 bytes "cruzados" no pueden representar / contener la información de 10 MB, por lo que creo que su esencia es la siguiente:

Incluso si tiene mucha información adicional para las correcciones dentro de todo el archivo de video: formato de datos, cuadros, el guión gráfico en sí mismo, voces de los actores y así sucesivamente: habrá miles de videos más o menos diferentes que se ajustan a todos los criterios conocidos. Incluso asumo que un puñado de fotogramas individuales aquí y allá podría hacer que cualquier video lleve a los mismos hashes.

Esta pregunta es muy parecida: ¿es posible que un virus (pequeño) se agregue a un archivo (grande) mientras mantiene la suma de comprobación del archivo con el mismo valor rellenando una cantidad (no tan grande) de bytes variables? Supongo que es posible, aunque difícil de calcular a tiempo hoy. Por otro lado, sabemos que muchos códigos posibles conducen al mismo hash, por lo que el tiempo de computación podría ser sobreestimado. Tal vez sea posible en segundos , solo los piratas informáticos lo sabrán

Editar: Durante la noche me inspiré para una buena comparación adicional de su "problema de parte de video perdido": para tales casos (recuperación completa de datos) ya se ha inventado el < tecnología> RAID-5 fuerte (Wiki vea aquí: enlace ). Uno de cada tres o más discos duros puede fallar y todos los datos pueden reconstruirse sin pérdida. Ciertamente, tiene muchos gastos generales de datos (redundancia para corrección de errores) almacenados en todas las unidades para poder hacerlo.

Hashes / Checksums son buenos para la detección de pequeñas manipulaciones / errores (bits o pocos bytes) que ocurrieron en algún lugar dentro de un archivo. Más avanzados son los CRC con corrección de errores. Al menos tenemos sistemas de redundancia como RAID.

La respuesta es NO, y parece que estás mezclando dos cosas diferentes:

• Checksums y Hashes son comprobadores de integridad unidireccionales . El propósito de su uso en ese asunto es asegurarse de que los datos no estén dañados, y nada más
• Los códigos de recuperación son los que está utilizando si necesita recuperar sus datos mediante el código proporcionado . El ejemplo más brillante es un código Reed-Solomon para recuperar CD Datos de la ROM El propósito de su uso en este asunto es ayudarlo a recuperar datos dañados / perdidos por algún motivo

Parece que son similares a primera vista, pero son MUY diferentes.

Hay una posibilidad para esto: Google, literalmente.

Si el archivo ya se ha cargado en varios sitios de intercambio de archivos, es probable que hayan publicado un hash y que se haya indexado.

Por ejemplo, google ' 60CCE9E9C6557335B4F7B18D02CFE2B438' '     

Es efectivamente imposible, debido a la teoría de la información. Efectivamente imposible, ya que en "muerte térmica del universo" se convierte en un factor limitante legítimo en tu búsqueda.

Falta una división de 2,000,000 byte (2MB). Un hash como SHA-1 tiene 20 bytes de información en él. Según la teoría de la información, debemos esperar que hay 1,999,980 bytes que aún son desconocidos. Eso significa 2 ^ (8 * 1,999,980) archivos posibles para explorar. Ese es un número tan grande que empiezas a hablar sobre la muerte por calor del universo antes de que cada átomo en el universo actúe mágicamente como un procesador de 2 Ghz, trabajando en conjunto, pueda encontrarlo. Y eso no incluye el desafío de averiguar cuál de las soluciones es la correcta. Es solo el costo de producir el correcto.

Algunos han mencionado que tienes información adicional. Por ejemplo, tienes el SHA-1 de todo el archivo. Lamentablemente, esto no es muy útil. Suponiendo que también tiene este hash, ahora tiene 1,999,960 bytes de información que aún se desconocen, y por lo tanto, 2 ^ (8 * 199,960) posibles cortes a considerar. Todavía estamos en la muerte de calor del reino del universo. Podríamos agregar restricciones adicionales, como la continuidad con el video existente, pero eventualmente vamos a tener límites en cuanto a cuánto podríamos saber sobre la porción sin tener suficiente información para simplemente recrearla directamente a partir de la información que conocemos.

La mejor oportunidad que tendrías es tener a todo el mundo entero unido para resolver tu problema, y alimentarte cada porción de datos de 2MB en toda Internet. Es muy probable que si "pierde" los datos, otra persona podría tener una copia de los mismos. Es mucho más fácil escanear a través de los petabytes de datos que la humanidad ha reunido que a través de un número mucho mayor de posibilidades que 2MB de datos arbitrarios tiene para ofrecer.

Los hash están diseñados para ser de una manera. Es fácil viajar de izquierda a derecha, pero es prácticamente imposible viajar de derecha a izquierda cuando se habla de Hashing.

Prefacio: normalmente se utiliza un hash para verificar la integridad de un archivo o conjunto de datos.

Siempre que el hash de suma de comprobación incluya los datos y el nombre, ese podría ser un punto de referencia para el contenedor, que luego podría implementarse en la búsqueda a través de la coincidencia de patrones de suma de comprobación. Siempre que supiera una sal (que podría incluir el valor de la fecha o la hora, por ejemplo).

Aunque causar una sola colisión a una velocidad de 1MH / s, aún podría tomar aproximadamente 3 años eliminar todas las posibilidades absolutas de obtener un resultado de tan solo 15 números. Así que entendemos otra referencia por ej. donde este archivo está en el medio de almacenamiento ayudaría a ser más específico .e.g. entrada de ID de sector o archivo.

Pero es creíble tener en cuenta que la transferencia de datos (especialmente a través de redes) tiende a estorbar, con su propia suma de comprobación para referencia.

Y en caso de que alguien quiera discutir, una sal suele ser complementaria y la criptografía no debe confundirse con la recuperación, ya que cuando se encripta no solo con un estándar de criptografía patética, y se olvida la clave, generalmente ser incapaz de recuperar sus datos.