Une réponse simple, NON.

C'est comme demander, si je sais, que x% 4 = 3 , est-il possible de trouver la valeur de x ? Non. Il y aurait sûrement des valeurs infinies de x satisfaisant cette équation, mais vous ne sauriez pas simplement laquelle est correcte.

De même, de nombreux clips vidéo (ou infinis) peut entraîner une valeur de hachage donnée (évidemment, des clips vidéo infinis doivent être mappés à un nombre spécifique de valeurs de hachage, de sorte que les collisions sont inévitables). Vous ne sauriez pas quel clip est correct.

Cela aussi, dans le temps humain? Non.

EDIT: Comme indiqué dans les commentaires, puisque le fichier est découpé en morceaux de 2 Mo, il n'y aura pas de possibilités infinies , mais ce serait assez volumineux ( 2 porté à une puissance de 16,7 millions, environ). Forcer brutalement un si grand nombre de possibilités, dans le temps humain, est encore presque impossible. Mais oui, ce n'est pas infini .

Ce n'est pas possible quelle que soit la vitesse de votre ordinateur, simplement parce que vous ne pouvez pas recréer les informations correctes à partir de pratiquement rien.

Vous demandez en fait de restaurer 2 Mo à partir de 32 octets (taille de SHA -256) ou au plus 64 octets (SHA-256 pour le bloc et pour le fichier total). Ce serait un rapport de 1: 65536 ou 1: 32768. Étant donné que la vidéo est déjà fortement compressée, la chance est pratiquement nulle que vous puissiez restaurer les données d'origine à partir de ces quelques informations. Il se peut que vous puissiez créer un bloc de 2 Mo qui aboutit aux hachages SHA-256 spécifiques, mais il y a très peu de chances que ce soit ce bloc d'origine.

Vous n'avez pas pu reproduire le fichier dans un délai raisonnable. La raison en est que la seule façon d'inverser un hachage est via la force brute, et compte tenu de la taille du fichier d'origine, cela vous prendrait cette quantité exacte d'octets en force brute.

Disons vous avez un fichier vidéo d'une taille précise de 100 Mo.

• 1 Mo = 1 000 000 octets
• 100 Mo = 100 000 000 octets

Cela signifie vous auriez besoin de forcer brutalement ce fichier original et de vérifier qu'il est haché, vous devrez essayer n ^ r permutations. En supposant que le fichier vidéo n'utilise que 256 caractères par octet (ascii), nous examinerions:

256 ^{100 000 000} ≈ 10 ^{240 823 997} ≈ ∞

C'est essentiellement infini - il faudrait fondamentalement TOUJOURS pour calculer cela, quelles que soient les ressources du processeur.

MISE À JOUR : Il y a aussi, bien sûr, le problème avec collisions de hachage que j'ai laissées de côté ici - avec un hachage Sha256, vous allez probablement rencontrer une quantité infinie de collisions avec un fichier aussi volumineux que notre exemple. J'ai négligé de mentionner cela plus tôt par souci de simplicité.

Supposons que vous ayez un ordinateur qui a une puissance de traitement infinie et qui peut vérifier de manière fiable chaque message possible contre chaque hachage possible en peu de temps. Voici le problème auquel vous êtes maintenant confronté: collisions.

Qu'est-ce qu'une collision? De nombreux fichiers différents peuvent correspondre exactement à la même signature. De nombreux messages différents peuvent correspondre exactement à la même signature.

Le hachage est unidirectionnel . Vous convertissez une série de caractères en hachage. Lorsque vous validez votre hachage, vous vérifiez simplement si le message correspond à la valeur calculée du hachage. Le problème est que de nombreux messages différents peuvent correspondre à ce même hachage. Cela s'appelle collision.

Cependant, puisque vous avez également une puissance de calcul infinie, vous pouvez Enfin, reconstruisez le fichier par essais et erreurs supermassifs. Cependant, une fois que vous avez tous les exemples possibles pour cette valeur de hachage, comment allez-vous savoir laquelle est laquelle?

Vous me dites donc qu'il y a une chance?

Avec la technologie d'aujourd'hui, et comme nous n'aurons jamais une puissance de calcul infinie, ce sera complètement impossible. Même en prenant la puissance de calcul combinée du monde entier et en la multipliant par un milliard, vous ne pouvez pas faire cela. Même si vous faisiez cela d'une manière ou d'une autre, comment pourriez-vous savoir quel message était correct?

Où mon idée s'appliquerait-elle?

• Le hachage est aller simple . Avec la clé fournie, vous confirmez uniquement qu'elle correspond à votre hachage calculé.
• Le chiffrement est bidirectionnel . Avec la clé fournie, vous récupérez les résultats.

Votre idée s'appliquerait au chiffrement et non au hachage. Avec le chiffrement, si vous avez la clé, vous pouvez obtenir le contenu déchiffré du fichier.

C'est difficile si le fichier sous-jacent a une entropie suffisamment élevée. Si vous savez quelque chose sur les données sous-jacentes, vous pourrez peut-être les récupérer. Par exemple, s'il y a un hacker n'importe où dans le voisinage, il ne faudra pas longtemps avant que quelqu'un vous dise ce que j'ai haché md5 pour obtenir:

  73868cb1848a216984dca1b6b0ee37bc  

Cependant, la vidéo généralement a beaucoup d'entropie, ce qui en fait une cause perdue ou du moins difficile. Il faudrait que la vidéo soit une caméra vidéo et il faudrait espérer que le morceau manquant montre une heure de noir comme une nuit noire. Mettons cela en perspective: la création d'un bitcoin est essentiellement une question d'inverser un hachage. Inverser un extrait vidéo très court équivaut probablement à gagner environ 20 bitcoins, peut-être plus. Donc, à votre place, je ferais les bitcoins, j'achèterais une nouvelle copie de la vidéo et j'empocherais la monnaie. Près de huit mille dollars de monnaie. Peut-être que j'achèterais des actions dans une société d'informatique quantique et faciliterais les futurs exploits; c'est amusant de faire "l'impossible".

Pour ceux qui disent, "les hachages sont plusieurs contre un, donc vous ne pouvez pas dire ce qui a été haché": C'est vrai, mais de toutes les nombreuses valeurs qui hachent à cela une valeur, certains seront plus plausibles que d'autres. Si vous inversez le hachage ci-dessus, vous n'aurez aucun doute que vous avez trouvé la bonne entrée. S'amuser! :-)

Il y a une possibilité pour cela: Google it - littéralement.

Si le fichier a déjà été téléchargé sur l'un des nombreux sites de partage de fichiers, ils en ont probablement publié un hachage, et il a peut-être été indexé.

Par exemple, google ' 60CCE9E9C6557335B4F7B18D02CFE2B438A8B3E2'.

Un commentaire mais c'est trop long:

Comme d'autres l'ont montré, ce n'est pas possible. Cependant, il existe un problème connexe qui est certainement raisonnable:

Ok, vous ne pouvez pas reconstruire cette vidéo de 200 Mo qui a été divisée en 100 fichiers de 2 Mo dont vous avez 99.

Cependant , vous pouvez créer un autre fichier qui sera un cheveu de plus de 2 Mo qui vous permettra de reconstruire tout un fichier manquant. Deux de ces fichiers vous permettront de reconstruire deux fichiers manquants et ainsi de suite. Bien que la taille du bloc ne puisse pas être fixée à une valeur supérieure à la taille du fichier (un fichier de réparation de 4 Mo ne corrige toujours qu'un seul fichier manquant), elle peut être définie plus bas, ce qui peut être utile si un dommage partiel est possible. (Le temps de calcul augmente, les fichiers deviennent légèrement plus volumineux mais vous avez plus de capacité à récupérer des dommages.)

Le programme standard pendant longtemps était: Quickpar mais il n'a pas 't été mis à jour depuis des lustres. L'alternative la plus moderne que je connais (mais que je n'ai pas encore beaucoup utilisée) est Multipar (Remarque: ce site est en japonais. Le programme est en bon anglais, cependant.)

Si je dois sauvegarder des données sur un DVD, je crée régulièrement des fichiers de réparation supplémentaires au cas où quelque chose se produirait - l'espace supplémentaire sur le DVD va de toute façon gaspiller, pourquoi ne pas y mettre une assurance? Multipar a même des modes spécifiquement pour cela (bien que je ne les ai pas encore essayés) où il générera des blocs pour remplir un disque DVD-R ou BD-R.

Il faudra fondamentalement trop de temps pour obtenir un résultat satisfaisant, en abordant les deux: générer la partie vidéo manquante (selon des critères calculables) et en trier les meilleures (ce qui nécessite des humains intelligence ou IA extrêmement développée). Même si vous avez enfin une belle vidéo correspondant à tous les critères, vous ne saurez jamais si le film original avait le même contenu. Essayer de "reconstruire" quelque chose qui peut être le plus variable - mieux et plus vite: utilisez votre propre fantaisie.

Certainement des valeurs de hachage de 10 octets "croisées" ne peut pas représenter / contenir les informations de 10 Mo, donc je pense que votre essence est la suivante:

Même si vous avez beaucoup d'informations supplémentaires pour les corrections dans tout le fichier vidéo: format de données, cadres , le storyboard lui-même, les voix des acteurs, etc.: il y aura des milliers de vidéos plus ou moins différentes qui répondront à tous les critères connus. J'imagine même que une poignée d'images vidéo uniques ici et là pourrait faire n'importe quelle vidéo menant aux mêmes hachages.

Cette question est très similaire: est-il possible pour un (petit) virus de s'ajouter à un (gros) fichier tout en gardant la somme de contrôle du fichier de la même valeur en remplissant une (pas si grande) quantité d'octets variables? Je suppose que c'est possible, bien que difficile à calculer à temps aujourd'hui. D'un autre côté, nous savons que de nombreux codes possibles conduisent au même hachage, de sorte que le temps de calcul pourrait être surestimé. Peut-être que c'est possible en quelques secondes - seuls les pirates le sauront.

Modifier: Au cours de la nuit, j'ai eu l'inspiration pour une belle comparaison supplémentaire de votre "problème de partie vidéo perdue": pour de tels cas (récupération complète des données), il a déjà été inventé le technologie strong> RAID-5 (voir le Wiki ici: https://en.wikipedia.org/wiki/RAID). Un disque dur sur trois ou plus peut tomber en panne et toutes les données peuvent être reconstruites sans perte. Vous avez certainement beaucoup de surcharge de données (redondance pour la correction d'erreurs) stockée sur tous les disques pour pouvoir le faire.

Les hachages / sommes de contrôle sont bons pour la détection de petites (bits ou quelques octets) de falsification / les erreurs qui se sont produites quelque part dans un fichier. Les CRC avec correction d'erreurs sont plus avancés. Au moins, nous avons des systèmes de redondance comme RAID.

La réponse est NON, et il semble que vous mélangez deux choses différentes:

• Les sommes de contrôle et les Hashes sont vérificateurs d'intégrité à sens unique . Le but de leur utilisation à cet égard est de s'assurer que les données n'ont pas été corrompues et que rien d'autre
• Les codes de récupération sont ceux que vous ' utilisez si vous avez besoin de récupérer vos données par le code fourni . L'exemple le plus brillant est un code Reed-Solomon pour la récupération de données sur CD-ROM. Le but de leur utilisation dans cette affaire est de vous aider à récupérer des données corrompues / perdues pour une raison quelconque

Elles semblent être similaires à première vue, mais ce sont des choses TRÈS différentes.

C'est effectivement impossible, en raison de la théorie de l'information. Effectivement impossible, car dans "la mort thermique de l'univers" devient un facteur limitant légitime de votre recherche.

Il vous manque une tranche de 2 000 000 octets (2 Mo). Un hachage comme SHA-1 contient 20 octets d'informations. Selon la théorie de l'information, nous devrions nous attendre à ce qu'il y ait 1 999 980 octets encore inconnus. Cela signifie 2 ^ (8 * 1 999 980) fichiers possibles à explorer. C'est un nombre si grand que vous commencez à parler de la mort thermique de l'univers avant que chaque atome de l'univers agissant comme par magie comme un processeur 2Ghz, fonctionnant en tandem, puisse le trouver. Et cela n'inclut pas le défi de déterminer laquelle des solutions est la bonne. C'est juste le coût de production du bon.

Certains ont mentionné que vous aviez des informations supplémentaires. Par exemple, vous avez le SHA-1 du fichier entier. Malheureusement, ce n'est pas très utile. En supposant que vous ayez également ce hachage, vous avez maintenant 1 999 960 octets d'informations qui sont encore inconnues, et donc 2 ^ (8 * 199 960) tranches possibles à considérer. Nous sommes toujours dans la chaleur de la mort du royaume de l'univers. Nous pourrions ajouter des contraintes supplémentaires, telles que la continuité avec la vidéo existante, mais nous finirons par rencontrer des limites quant à ce que nous pourrions éventuellement savoir sur la tranche sans avoir suffisamment d'informations pour simplement la recréer directement à partir des informations que nous connaissons.

La meilleure chance que vous auriez est de réunir le monde entier pour résoudre votre problème et de vous alimenter chaque tranche de 2 Mo de données sur tout Internet. Il est fort probable que si vous «perdiez» les données, quelqu'un d'autre pourrait en avoir une copie. Il est beaucoup plus facile de parcourir les pétaoctets de données que l'humanité a rassemblés que de parcourir le nombre beaucoup plus grand de possibilités que 2 Mo de données arbitraires ont à offrir.

Les hachages sont conçus pour être à sens unique. Il est facile de voyager de gauche à droite, mais il est pratiquement impossible de voyager de droite à gauche quand on parle de hachage.

Préface: un hachage est normalement utilisé pour vérifier l'intégrité d'un fichier ou d'un ensemble de données.

À condition que le hachage de la somme de contrôle inclue les données et le nom, cela pourrait être un point de référence pour le conteneur, qui pourrait alors être implémenté dans la recherche par correspondance de modèle de somme de contrôle. À condition que vous connaissiez un sel (qui pourrait inclure la valeur de la date ou de l'heure par exemple).

Bien que pour provoquer une seule collision à une vitesse de 1MH / s, il pourrait encore prendre environ 3 ans pour éliminer toute possibilité absolue pour un résultat aussi peu que 15 numéros. Donc comprendre une autre référence, par exemple où ce fichier est sur le support de stockage aiderait à être plus spécifique. entrée de l'ID de secteur ou de fichier.

Mais il est crédible de noter que le transfert de données (en particulier sur les réseaux) a tendance à être généralement gênant, avec sa propre somme de contrôle pour référence.

Et au cas où quelqu'un voudrait argumenter, un sel est généralement gratuit et la cryptographie ne doit pas être mélangée avec la récupération, comme lorsque vous cryptez avec non seulement une norme de cryptographie pathétique et que vous oubliez la clé, vous ne pourrez généralement pas récupérer vos données.