Puis-je récupérer le contenu du fichier à partir de sa somme de contrôle / hachage?
Disons que j'ai un fichier vidéo divisé en plusieurs parties. Chaque pièce fait 2 mégaoctets. J'ai également une liste du * insérer le nom de hachage ici * pour chaque morceau et aussi pour le fichier complet.
Supposons maintenant que j'ai égaré/perdu/fubar une de ces pièces.
Puis-je récupérer la pièce perdue de son hachage, en utilisant la force brute ou toute autre méthode en durée de vie humaine de temps? =
Une table de style arc-en-ciel serait irréalisable, je pense.
Question numérique bonus - combien cela prendrait-il sur un réseau informatique distribué de taille moyenne basé principalement sur des PC grand public? (Exemple: CPU 4 GHz + GPU d'entrée de gamme + 8 Go de RAM)
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) peuvent entraîner une valeur de hachage donnée (évidemment, les 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, en temps humain? Non.
EDIT: Comme indiqué dans les commentaires, puisque le fichier est divisé en morceaux de 2 Mo, il n'y aura pas infini possibilités, mais ce serait assez grand (2 augmentés à une puissance de 16,7 millions, environ ). Forcer brutalement un si grand nombre de possibilités, en temps humain, est encore presque impossible. Mais oui, ce n'est pas infini.
Cela 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, il est pratiquement nul 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, ce qui entraîne les hachages SHA-256 spécifiques, mais les chances sont très faibles que ce soit ce bloc d'origine.
Vous ne pouvez pas reproduire le fichier dans un délai raisonnable. La raison en est que la seule façon de `` renverser '' un hachage est via la force brute, et compte tenu de la taille du fichier d'origine, il vous faudrait cette quantité exacte d'octets en force brute.
Supposons que vous ayez un fichier vidéo d'une taille de 100 Mo, précisément.
- 1 Mo = 1 000 000 octets
- 100 Mo = 100 000 000 octets
Cela signifie que vous devrez forcer brutalement ce fichier d'origine et vérifier qu'il s'agit d'un hachage, vous devrez essayer n ^ r permutations. En supposant que le fichier vidéo n'utilise que 256 caractères par octet (ascii), nous examinerions:
256100 000 000 ≈ 10240 823 997 ≈ ∞
C'est essentiellement infini - il faudrait essentiellement FOREVER pour le calculer, quelles que soient les ressources du processeur.
UPDATE : Il y a aussi, bien sûr, le problème des collisions de hachage que j'ai laissé ici - avec un hachage Sha256, vous allez probablement rencontrer à peu près une quantité infinie de collisions avec un fichier aussi gros que notre exemple. J'ai négligé de le mentionner plus tôt pour des raisons de simplicité.
Disons que vous avez un ordinateur qui a une quantité infinie de puissance de traitement et qui peut vérifier de manière fiable chaque message possible par rapport à chaque hachage possible en peu de temps. Voici le problème auquel vous êtes 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 one-way. 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, étant donné que vous disposez également d'une puissance de calcul infinie, vous pouvez également éventuellement reconstruire le fichier via des essais et erreurs supermassifs. Cependant, une fois que vous avez tous les exemples possibles pour cette valeur de hachage, comment allez-vous dire lequel est lequel?
Alors tu me dis 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 le faire. Même si vous l'avez fait d'une manière ou d'une autre, comment pourriez-vous dire quel message était correct?
Où s'appliquerait mon idée?
- Le hachage est unidirectionnel . Avec la clé fournie, vous validez seulement qu'elle correspond à votre hachage calculé.
- Le cryptage est bidirectionnel . Avec la clé fournie, vous obtenez les résultats.
Votre idée s'appliquerait sous cryptage, pas de hachage. Avec le cryptage, si vous avez la clé, vous pouvez obtenir le contenu décrypté 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 pirate informatique n'importe où dans le voisinage, il ne faudra pas longtemps avant que quelqu'un vous dise ce que j'ai md5 haché pour obtenir:
73868cb1848a216984dca1b6b0ee37bc
Cependant, la vidéo généralement a beaucoup d'entropie, ce qui en fait une cause perdue ou au moins une sacrément difficile. Vous auriez besoin que la vidéo soit une caméra vidéo et vous devriez espérer que le morceau manquant montre une heure de nuit noire comme noire. Mettons cela en perspective: la création d'un bitcoin consiste essentiellement à inverser un hachage. Inverser une capture vidéo très courte revient probablement à créer environ 20 bitcoins, peut-être plus. Donc, à votre place, je ferais les bitcoins, achèterais une nouvelle copie de la vidéo et empocherais la monnaie. Près de huit mille dollars de monnaie. Peut-être que j'achèterais des actions dans une entreprise d'informatique quantique et faciliterais les futurs exploits; c'est amusant de faire "l'impossible".
Pour ceux qui disent: "les hachages sont multiples pour un, vous ne pouvez donc pas dire ce qui a été haché": C'est vrai, mais parmi toutes les nombreuses valeurs qui hachent à cette seule valeur, certaines seront plus plausibles que d'autres. Si vous inversez le hachage ci-dessus, vous n'aurez pas le moindre 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 peut avoir é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, etc. Bien que la taille du bloc ne puisse pas être définie de manière rentable supérieure à la taille du fichier (un fichier de réparation de 4 Mo ne résout toujours qu'un fichier manquant), il peut être défini plus bas, ce qui peut être utile si des dommages partiels sont possibles. (Le temps de calcul augmente, les fichiers deviennent légèrement plus gros mais vous avez plus de capacité à récupérer des dommages.)
Le programme standard depuis longtemps était: Quickpar mais il n'a pas été mis à jour depuis des lustres. L'alternative la plus moderne que je connaisse (mais je n'ai pas encore beaucoup utilisé) est Multipar (Remarque: ce site est en japonais. Le programme est cependant en bon anglais.)
Si je veux sauvegarder certaines 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 être gaspillé, 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.
Cela prend essentiellement 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 trier le meilleur ceux d'entre eux (qui nécessitent une intelligence humaine ou une 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. Cela pourrait ne pas avoir de sens d'essayer de "reconstruire" quelque chose qui peut être le plus variable - meilleur et plus rapide: utilisez votre propre fantaisie.
Certes, certaines valeurs de hachage de 10 octets "crossfiring" ne peuvent pas représenter/contenir les informations de 10 Mo, donc je pense que votre Gist est le suivant:
Même si vous avez beaucoup d'informations supplémentaires pour les corrections à l'intérieur du fichier vidéo entier: format des données, images, le storyboard lui-même, voix des acteurs et ainsi de suite: il y aura des milliers de vidéos plus ou moins différentes qui conviendront à tous les connus Critères. Je suppose même que une poignée d'images vidéo uniques ici et là pourraient faire n'importe quelle vidéo conduisant aux mêmes hachages.
Cette question est très similaire: est-il possible qu’un (petit) virus s’ajoute à un (gros) fichier tout en conservant la somme de contrôle du fichier à la même valeur en remplissant une quantité (pas si grande) 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, donc le temps de calcul peut être surestimé. Peut-être que c'est possible en quelques secondes - seuls les pirates le sauront.
Edit: 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é la technologie RAID-5 (Wiki voir 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. Certes, vous avez beaucoup de surcharge de données (redondance pour la correction des erreurs) stockée sur tous les lecteurs pour pouvoir le faire.
Les hachages/sommes de contrôle sont bons pour la détection de petites (bits ou quelques octets) falsifications/erreurs qui se sont produites quelque part dans un fichier. Plus avancés sont les CRC avec correction d'erreur. 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:
- Somme de contrôle et Hashs sont vérificateurs d'intégrité unidirectionnels . Le but de leur utilisation dans ce domaine est de s'assurer que les données n'ont pas été corrompues, et rien d'autre
- 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 récupérer les données du 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
Ils semblent similaires à première vue, mais ils sont [~ # ~] très [~ # ~] très différents.
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 comprenne les données et le nom, cela pourrait être un point de référence pour le conteneur, qui pourrait ensuite être implémenté dans la recherche par correspondance de modèle de somme de contrôle. Pourvu que vous connaissiez un sel (qui pourrait inclure la date ou l'heure par exemple).
Bien que pour provoquer une seule collision à un taux de 1MH/s, il pourrait encore prendre environ 3 ans pour éliminer toute possibilité absolue pour un résultat aussi petit que 15 nombres. Donc, comprendre une autre référence, par exemple où ce fichier est sur le support de stockage aiderait à être plus spécifique .e.g. secteur ou entrée d'ID de fichier.
Mais il est crédible de noter que le transfert de données (en particulier sur les réseaux) tend généralement à entraver, avec sa propre somme de contrôle pour référence.
Et au cas où quelqu'un voudrait discuter, un sel est généralement complémentaire et la cryptographie ne devrait 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.
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 lorsque l'on parle de hachage.
C'est effectivement impossible, en raison de la théorie de l'information. Effectivement impossible, car dans "la chaleur de la mort 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, il faut s'attendre à ce qu'il y ait 1 999 980 octets qui sont encore inconnus. Cela signifie 2 ^ (8 * 1 999 980) fichiers possibles à explorer. C'est un nombre si grand que vous commencez à parler de mort thermique de l'univers avant que chaque atom dans l'univers agissant comme un processeur 2Ghz, travaillant en tandem, puisse le trouver. Cela inclut le défi de trouver réellement la bonne solution, mais simplement le coût de la production de la bonne solution.
Certains ont mentionné que vous disposiez d'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 disposez maintenant de 1 999 960 octets d'informations qui sont encore inconnus, et donc de 2 ^ (8 * 199 960) tranches possibles à considérer. Nous sommes toujours dans la chaleur morte du royaume de l'univers. Nous pourrions ajouter des contraintes supplémentaires, telles que la continuité avec la vidéo existante, mais finalement nous allons 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 serait d'avoir le monde entier réuni pour résoudre votre problème et de vous alimenter chaque tranche de 2 Mo de données sur l'ensemble d'Internet. Il est fort probable que si vous "perdez" les données, quelqu'un d'autre puisse 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 le faire à travers le nombre beaucoup plus grand de possibilités que 2 Mo de données arbitraires peuvent offrir.