Pourquoi les fonctions de hachage sont-elles à sens unique? Si je connais l'algorithme, pourquoi ne puis-je pas calculer son entrée?
Pourquoi un hachage de mot de passe ne peut-il pas être rétroconçu?
J'ai étudié cela il y a longtemps et j'en ai lu beaucoup, mais je ne trouve pas l'explication de pourquoi cela ne peut pas être fait. Un exemple facilitera la compréhension de ma question et pour garder les choses simples, nous le baserons sur un algorithme de hachage qui n'utilise pas de sel ( LanMan ).
Dites que mon mot de passe est "Mot de passe". LanMan va hacher cela et le stocker dans la base de données. Les programmes de piratage peuvent les forcer brutalement en hachant les suppositions de mot de passe que vous fournissez. Il compare ensuite le hachage généré au hachage de la base de données. S'il y a une correspondance, cela détermine le mot de passe.
Pourquoi, si le pirate de mot de passe connaît l'algorithme pour transformer un mot de passe en texte brut en hachage, ne peut-il pas simplement inverser le processus de calcul du mot de passe à partir du hachage?
Cette question était Question de la semaine sur la sécurité informatique.
Lisez le 24 février 2012 entrée de blog pour plus de détails ou soumettez le vôtre Question de la semaine.
Permettez-moi d'inventer un "algorithme de hachage de mot de passe" simple pour vous montrer comment cela fonctionne. Contrairement aux autres exemples de ce fil, celui-ci est réellement viable, si vous pouvez vivre avec quelques restrictions de mot de passe bizarres. Votre mot de passe est composé de deux grands nombres premiers, x et y. Par exemple :
x = 48112959837082048697
y = 54673257461630679457
Vous pouvez facilement écrire un programme informatique pour calculer xy en O ( [~ # ~] n [~ # ~ ] ^ 2) heure, où [~ # ~] n [~ # ~] est le nombre de chiffres dans x et y. (Fondamentalement, cela signifie qu'il faut quatre fois aussi longtemps que les nombres sont deux fois plus longs. Il y a des algorithmes plus rapides, mais ce n'est pas pertinent.) Store xy dans la base de données de mots de passe.
x*y = 2630492240413883318777134293253671517529
Un enfant de cinquième année, avec suffisamment de papier brouillon, pourrait trouver cette réponse. Mais comment inversez-vous cela? Il existe de nombreux algorithmes conçus par les gens pour factoriser de grands nombres, mais même les meilleurs algorithmes sont lents par rapport à la vitesse à laquelle vous pouvez multiplier x par y. Et aucun de ces algorithmes ne pouvait être exécuté par une cinquième niveleuse, à moins que les nombres soient très petits (par exemple, x = 3, y = 5).
C'est la propriété clé: le calcul est beaucoup plus simple en avant qu'en arrière. Pour de nombreux problèmes, vous devez inventer un algorithme complètement nouveau pour inverser un calcul.
Cela n'a rien à voir avec les fonctions injectives ou bijectives. Lorsque vous déchiffrez un mot de passe, peu importe si vous obtenez le même mot de passe ou si vous obtenez un mot de passe différent avec le même hachage. La fonction de hachage est conçue de sorte qu'il est difficile de l'inverser et d'obtenir une réponse, même un mot de passe différent avec le même hachage. En crypto-langage: une fonction de hachage vulnérable à une attaque de pré-image n'a absolument aucune valeur. (L'algorithme de hachage de mot de passe ci-dessus est injectif si vous avez une règle qui x < y. )
Que font les experts en cryptographie? Parfois, ils essaient de trouver de nouveaux algorithmes pour inverser une fonction de hachage (pré-image). Ils font exactement ce que vous dites: analysez l'algorithme et essayez de le renverser. Certains algorithmes ont été inversés auparavant, d'autres non.
Exercice pour le lecteur: Supposons que la base de données de mots de passe contienne l'entrée suivante:
3521851118865011044136429217528930691441965435121409905222808922963363310303627
Quel est le mot de passe? (Celui-ci n'est en fait pas trop difficile pour un ordinateur.)
Note de bas de page: En raison du petit nombre de mots de passe que les gens choisissent dans la pratique, un bon hachage de mot de passe est non seulement difficile à calculer en arrière, mais aussi long à calculer en avant, pour ralentir les attaques par dictionnaire. Comme autre couche de protection, le sel aléatoire empêche l'utilisation de tables d'attaque précalculées (telles que les "tables arc-en-ciel").
Note 2: Comment savons-nous qu'il est difficile d'inverser une fonction de hachage? Malheureusement non. Nous ne savons tout simplement pas comment inverser les fonctions de hachage. Faire une fonction de hachage qui est difficile à inverser est le Saint Graal de la conception de la fonction de hachage, et cela n'a pas encore été réalisé (peut-être que cela n'arrivera jamais).
Maintenant c'est une bonne question.
Nous devons d'abord donner une précision: de nombreuses fonctions unidirectionnelles, en particulier la fonction de hachage comme couramment utilisée en cryptographie, acceptent les entrées d'un espace beaucoup plus grand que l'espace des valeurs de sortie. Par exemple, SHA-256 est défini pour les entrées qui sont des chaînes allant jusqu'à 18446744073709551615 bits; il y a 218446744073709551616-1 entrées possibles, mais comme la sortie est toujours une séquence de 256 bits, il n'y a que 2256 sorties possibles pour SHA-256. Forcément, certaines entrées distinctes produisent la même sortie. Par conséquent, pour une sortie donnée de SHA-256, il n'est pas possible de récupérer sans ambiguïté l'entrée qui a été utilisée, mais, éventuellement, il pourrait être possible de calculer un entrée qui donne la valeur de sortie donnée. Preimage resistance est à ce sujet: la difficulté de trouver une entrée correspondante pour une sortie (quelle que soit la façon dont cette sortie a été obtenue en premier lieu).
Nous parlons donc d'une fonction que tout le monde peut calculer sur n'importe quelle entrée (en utilisant un programme connu du public, aucune valeur secrète impliquée - nous ne parlons pas de cryptage).
Ce que disent les universitaires
Il n'est pas clair si des fonctions à sens unique peuvent réellement exister. À l'heure actuelle, nous avons de nombreuses fonctions que personne ne sait inverser; mais cela ne signifie pas qu'ils sont impossibles à inverser, au sens mathématique. Notez, cependant, qu'il n'est pas prouvé que les fonctions à sens unique ne peuvent pas exister, donc l'espoir demeure. Certaines personnes soupçonnent que l'existence ou non de fonctions à sens unique pourrait être l'une de ces affirmations mathématiques gênantes qui ne peuvent être ni prouvées ni réfutées ( théorème de Gödel prouve que de telles choses doivent exister). Mais il n'y a aucune preuve de cela non plus.
Par conséquent, il n'y a aucune preuve qu'une fonction de hachage donnée soit vraiment résistante aux préimages.
Certaines fonctions peuvent être liées à des problèmes difficiles bien connus. Par exemple, si n est le produit de deux grands nombres premiers, alors la fonction x ⟼ x2 mod n est difficile à inverser: être capable de calculer les racines carrées modulo un entier non premier n (sur une base générale ) équivaut à pouvoir facteur n , et ce problème est connu pour être difficile. Pas éprouvé pour être dur, attention; seulement que les mathématiciens ont essayé de factoriser efficacement les grands entiers pendant (au moins) les 2500 dernières années, et bien que des progrès aient été réalisés, aucune de ces personnes intelligentes n'a trouvé d'algorithme vraiment tueur pour cela. Le record du monde pour la factorisation d'un "module RSA" (un produit de deux grands nombres premiers choisis au hasard de longueurs similaires) est n entier de 768 bits .
Certaines fonctions de hachage basées sur de tels "problèmes difficiles" ont été proposées; voir par exemple MASH-1 et MASH-2 (sur le problème RSA ) et ECOH ( avec courbes elliptiques). Seules quelques fonctions de ce type existent, car:
Transformer un "problème difficile" en une fonction de hachage sécurisée n'est pas facile; il y a beaucoup de problèmes délicats. Par exemple, alors que l'extraction des racines carrées modulo un non-prime n est généralement difficile, il existe des valeurs pour lesquelles l'extraction des racines carrées est facile.
Les performances de ces fonctions de hachage ont tendance à être, disons, sous-optimales. Comme être 100 fois plus lent qu'un SHA-1 plus couramment utilisé.
La manière la plus "standard" de construire une fonction de hachage est de rassembler les cryptographes et de les faire ronger avec certaines conceptions proposées; les fonctions qui survivent aux tentatives cryptanalytiques pendant quelques années sont alors considérées comme "probablement robustes". Concours SHA- est un tel effort; le gagnant devrait être annoncé plus tard cette année. Sur les 51 candidats (ceux qui ont réussi l'étape administrative), 14 ont été retenus pour le "tour 2" et ces 14 ont été examinés de près par de nombreux cryptographes, et aucun d'entre eux n'a trouvé quelque chose de vraiment intéressant à dire sur les fonctions. La liste a été réduite à 5 et sera encore réduite à 1 "bientôt", mais pas pour des raisons de sécurité (la plupart des données réelles concernaient les performances, pas la résistance).
Ce qui rend MD5 difficile à inverser
Comme nous ne savons pas prouver qu'une fonction est difficile à inverser, le mieux que nous puissions faire est de lui donner un essai sur une fonction spécifique, afin d'obtenir une "intuition" de la façon dont la fonction atteint sa résistance apparente.
Je choisis MD5 , ce qui est bien connu. Oui, MD5 est "cassé" , mais c'est pour les collisions, pas pour les pré-images. Il y a connu attaque de pré-image qui est, au moins théoriquement, plus rapide que la voie générique (la "voie générique" est la "chance", c'est-à-dire essayer une correspondance est trouvée, pour un coût moyen de 2128 évaluations puisque MD5 a une sortie 128 bits; --- attaque Sasaki-Aoki a coûté 2123,4, ce qui est inférieur, mais toujours beaucoup trop élevé pour être réellement essayé, donc le résultat est toujours théorique). Mais MD5 est relativement simple et a résisté aux attaques pendant un certain temps, c'est donc un exemple intéressant.
MD5 consiste en un certain nombre d'évaluations d'une "fonction de compression" sur des blocs de données. Le message d'entrée est d'abord rempli, de sorte que sa longueur devient un multiple de 512 bits. Il est ensuite divisé en blocs de 512 bits. Un état d'exécution de 128 bits (contenu dans quatre variables de 32 bits appelées [~ # ~] a [~ # ~] , [~ # ~] b [~ # ~] , [~ # ~] c [~ # ~] et [~ # ~] d [~ # ~] ) est initialisé à une valeur conventionnelle, puis traité avec la fonction de compression . La fonction de compression prend l'état en cours d'exécution et un bloc de messages 512 bits et les mélange en une nouvelle valeur pour l'état en cours d'exécution. Lorsque tous les blocs de messages ont été ainsi traités, la valeur finale de l'état en cours d'exécution est la sortie de hachage.
Concentrons-nous donc sur la fonction de compression. Cela fonctionne comme ceci:
- Entrées: l'état en cours d'exécution ( A B C D ) et un bloc de messages [~ # ~] m [~ # ~] . Le bloc de message est de 512 bits; nous le divisons en 16 mots de 32 bits M, M1, M2, ... M15.
- Sortie: la nouvelle valeur d'état de fonctionnement.
En traitement:
- Enregistrer l'état actuel dans certaines variables: A → A ', B → B' , C → C ' et D → D '
- Faites 64 tours qui ressemblent à ceci:
- Calculer T = B + ((A + fje(B, C, D) + Mk + Xje) <<< sje) . Cela se lit comme ceci: nous calculons une fonction donnée fje (une simple fonction au niveau du bit, qui dépend du nombre rond i ) sur [~ # ~] b [~ # ~] , [~ # ~] c [~ # ~] et [~ # ~] d [~ # ~] . Ajoutez à cela la valeur de [~ # ~] a [~ # ~] , un message Word Mk et une constante Xje (les ajouts se font modulo 232). Faites pivoter le résultat vers la gauche de quelques bits (le montant du décalage dépend également du tour). Enfin, ajoutez [~ # ~] b [~ # ~] : le résultat est [~ # ~] t [~ # ~] .
- Faites pivoter les mots d'état: D → A , C → D , B → C , T → B .
- Ajoutez les valeurs d'état enregistrées aux variables d'état actuelles: A + A '→ A , B + B' → B , C + C '→ C , D + D' → D .
Le point important est qu'il y a 64 tours, mais seulement 16 mots de message. Cela signifie que chaque message Word entre quatre fois dans le traitement . J'écris cela en gras parce que c'est le point central; la résistance aux préimages provient de cette caractéristique. Le message qui est utilisé dans chaque cycle est décrit dans la spécification MD5 (RFC 1321); la spécification décrit également les fonctions fje, la rotation compte sje et les constantes 32 bits Xje.
Supposons maintenant que vous essayez d '"inverser" MD5; vous commencez à partir de la sortie et montez lentement la fonction de compression. Tout d'abord, vous devez décider de la sortie de la ronde 64. En effet, la sortie de la fonction de compression est la somme de la sortie de la ronde 64 et de l'état enregistré (le A 'B' C 'D' ). Vous n'avez ni l'un ni l'autre, vous devez donc choisir. Votre espoir est que vous serez en mesure de trouver des valeurs pour les mots du message qui vous permettront d'obtenir pour la saisie de la ronde 1 des valeurs cohérentes avec votre décision arbitraire sur A ' et ses frères.
Voyons à quoi les choses ressemblent lorsque vous faites reculer la fonction de compression. Vous avez la sortie d'un tour (les variables [~ # ~] a [~ # ~] , [~ # ~] b [~ # ~] , [~ # ~] c [~ # ~] et [~ # ~] d [~ # ~] après la ronde) et vous voulez recalculer l'entrée de cette ronde. Vous connaissez déjà les valeurs précédentes de [~ # ~] b [~ # ~] , [~ # ~] c [~ # ~] et [~ # ~] d [~ # ~] , mais pour [~ # ~] a [~ # ~] et Mk vous avez l'embarras du choix: chaque valeur 32 bits est possible pour [~ # ~] a [~ # ~] , et chacune a un correspondant Mk. Au début, vous en êtes content; qui refuserait une telle liberté? Choisissez simplement un aléatoire Mk, et cela donne le [~ # ~] a [~ # ~] correspondant avec seulement quelques opérations (essayez-le!).
Mais après avoir inversé de cette façon 16 tours (les tours 49 à 64, puisque vous travaillez en arrière), la liberté disparaît. Vous avez "choisi" les valeurs de tous les mots du message. Lorsque vous essayez d'inverser la ronde 48, vous souhaitez recalculer la valeur de [~ # ~] a [~ # ~] juste avant cette ronde; selon la spécification MD5, message Word M2 est utilisé au tour 48, et vous avez déjà choisi la valeur de M2 (en inversant la ronde 63). Il n'y a donc qu'un seul choix pour [~ # ~] a [~ # ~] . Alors quoi, diriez-vous. Un seul choix suffit pour continuer la marche arrière. Alors vous continuez.
Maintenant, vous êtes au début de la fonction de compression. Rappelez-vous qu'au départ, vous avez fait un choix arbitraire des valeurs de A 'B' C 'D' : cela vous a permis de calculer la sortie de la ronde 64 et de commencer la marche arrière. Vous avez maintenant obtenu l'entrée du tour 1, qui devrait être identique à A 'B' C 'D' ... et elle ne correspond pas. C'est tout à fait normal: vous avez choisi A 'B' C 'D' arbitrairement, et vous avez également choisi les mots du message Mk arbitrairement, on peut donc s'attendre à ce que cela ne fonctionne pas la plupart du temps. Vous essayez donc de réparer le calcul, en modifiant rétrospectivement soit votre choix initial de A 'B' C 'D' , soit un ou plusieurs des les choix aléatoires pour Mk. Mais chaque modification sur n'importe quel Mk implique des modifications ailleurs, car chaque Mk est utilisé quatre fois. Vous avez donc besoin d'autres modifications pour annuler les autres, et ainsi de suite ...
À ce stade, vous commencez à comprendre le problème de l'inversion de MD5: chaque fois que vous touchez un seul bit, cela déclenche énormément de modifications dans l'algorithme, que vous devez annuler en touchant d'autres bits, et il y a tout simplement trop d'interactions . Fondamentalement, vous jonglez avec 2128 balles en même temps, et c'est beaucoup trop pour garder une trace de toutes.
Si chaque bloc de message avait une longueur de 2 048 bits, était divisé en 64 mots et que chaque message Word n'était utilisé qu'une seule fois dans MD5, alors vous pouviez l'inverser facilement. Vous faites comme ci-dessus: sélection arbitraire de A 'B' C 'D' , sélection arbitraire des mots de message pour les tours 64 à 5; et pour les quatre premiers tours, vous considérez simplement la valeur que vous souhaitez obtenir pour l'entrée du tour (la valeur qui correspond à votre choix arbitraire de A ', B' , C ' ou D' ) et élaborez le message correspondant Word. C'est de la tarte. Mais MD5 ne traite pas les données par blocs de 2048 bits, mais par blocs de 512 bits, et chaque message Word est utilisé quatre fois.
Quelques rebondissements supplémentaires
La structure de la fonction de compression de MD5 est en fait une généralisation d'un chiffrement de Feistel . Dans un chiffrement Feistel, les données sont divisées en deux moitiés et, pour chaque tour, nous modifions une moitié en l'ajoutant/en la xorant à une valeur intermédiaire qui est calculée à partir de l'autre moitié et de la clé; puis nous échangeons les deux moitiés. Étendez ce schéma à un fractionnement en quatre parties et vous obtenez la même structure que les tours MD5 - avec une rotation de 90 °: MD5 ressemble au cryptage de l'état actuel à l'aide du bloc de message comme clé (et il y a l'ajout supplémentaire de la sortie de la ronde 64 avec l'état enregistré, ce qui écarte MD5 d'un chiffre tourné).
Alors peut-être que nous pouvons construire des fonctions de hachage à partir de chiffrements de blocs? En effet, nous pouvons: c'est à cela que sert Whirlpool . Une fonction de hachage construite sur un chiffre de bloc tourné (le bloc de message est la clé); le chiffre de bloc de Whirlpool est "W", un dérivé de Rijndael, mieux connu sous le nom de AES . Mais W a des blocs plus gros (512 bits au lieu de 128 bits) et un calendrier de clés reforgé.
Lorsque vous créez une fonction de hachage à partir d'un chiffrement de bloc tourné, les attaques de pré-image sur la fonction de hachage sont quelque peu équivalentes aux attaques de reconstruction de clés sur le chiffrement de bloc; il y a donc un peu d'espoir que si le chiffrement par bloc est sécurisé, la fonction de hachage l'est également. Là encore, il y a des détails obscurs. De plus, pour une telle structure, collisions sur la fonction de hachage sont comme attaques par clé associée sur le chiffrement de bloc; les attaques de clés liées sont généralement considérées comme non fatales et souvent ignorées (par exemple, elles ne faisaient pas partie des critères d'évaluation du concours AES, et Rijndael est réputé un peu flasque à cet égard, c'est pourquoi W a une toute nouvelle clé programme).
Certaines conceptions plus récentes sont construites sur un chiffrement par bloc qui n'est pas tourné, de sorte que la sécurité de la fonction de hachage peut être dérivée plus directement de la sécurité du chiffrement par bloc; voir par exemple le candidat SHA-3 Skein , défini sur un chiffrement de bloc appelé Threefish.
Inversement, on pourrait essayer de faire un chiffrement de bloc à partir d'une fonction de hachage. Voir par exemple SHACAL , qui est SHA-1 "set upright". Et, au bon moment, SHACAL a quelques faiblesses liées qui sont assez similaires aux faiblesses connues de SHA-1 en ce qui concerne les collisions (aucune collision réelle n'a été calculée, mais nous avons une méthode qui devrait être presque un million de fois plus rapide que la algorithme générique de recherche de collision).
Par conséquent, contrairement à ce que j'ai dit dans l'introduction de ce post, nous avons toujours parlé de cryptage . Il reste encore beaucoup à découvrir et à étudier sur les liens entre les fonctions de hachage et le chiffrement symétrique.
TL; DR: il n'y a pas de TL; DR pour ce message. Lisez-le en entier ou partez.
La première étape de la réponse ici consiste à voir des exemples, comme celui de Nice de @Dietrich, de fonctions qui sont beaucoup plus difficiles à exécuter dans une direction que l'inverse, et ont résisté à de nombreuses tentatives pour trouver une percée de vitesse. Mais le problème est complexe, je vais donc essayer de l'étoffer un peu plus.
Beaucoup de gens semblent tomber dans le piège (heh) de penser que les fonctions de hachage sont en fait en quelque sorte magique - qu'elles sont vraiment des "fonctions à sens unique" absolues qui ne peuvent mathématiquement pas être exécutées à l'envers du tout, juste parce qu'on les appelle des hachages. Ce n'est pas une façon saine d'y penser dans un forum sur la sécurité. C'est souvent faux en pratique. Et c'est toujours faux en théorie, étant donné la définition mathématique de base d'une fonction en tant que mappage d'un domaine vers une image .
Tous les hachages peuvent être inversés, en principe. Cela peut être désordonné et brutal (comme en force brute), cela peut prendre un temps impraticable avec le matériel d'aujourd'hui, et cela peut même durer sur le long terme, mais mathématiquement, c'est simplement une question de temps. Comme l'a noté @mucker, toutes les informations sont là pour trouver le mot de passe d'origine (ou, au moins, un mot de passe qui fonctionne). Si nous oublions cela, nous oublions le danger d'une heuristique intelligente pour sélectionner les mots de passe probables, qui font régulièrement l'actualité. Le hachage est un problème d'ingénierie et le principal défi est celui de l'efficacité - comment rendre coûteux la recherche du mot de passe compte tenu du hachage. L'un des principaux résultats de ce type de réflexion est l'importance de faire des hachages de mot de passe lent
Et la science et les mathématiques du hachage ne s'améliorent que lentement. Il n'y a vraiment aucune preuve que les hachages sont vraiment durs. @ La réponse de Dietrich est une belle façon d'illustrer comment les fonctions de hachage idéales pourraient être possibles. Mais regardez les vrais experts qui décrivent comment nous n'avons pas de preuves pour l'un des meilleurs algorithmes de cryptographie: Quel est le modèle mathématique derrière les revendications de sécurité des chiffrements symétriques et des algorithmes de digestion?
Le fait que LanMan ait été cité dans la question est une preuve supplémentaire que nous devons éviter d'idéaliser les hachages. LanMan est tout sauf une fonction de hachage idéale, facilement vaincue par une combinaison d'un peu d'analyse et d'un peu de forçage brutal. Pour un autre exemple populaire d'une horrible fonction de hachage, voir MySQL OLD_PASSWORD cryptanalysis? .
Alors sortez du piège - tomber dans ce piège ne doit pas être un aller simple. Reconnaissez que les hachages sont réversibles et maintenez cet état d'esprit de sécurité fidèle pendant que vous recherchez la meilleure façon de les inverser. C'est souvent le meilleur moyen de trouver ceux qui sont vraiment difficiles à inverser. Je n'essaie pas de jeter des idées sur les meilleures pratiques, comme bcrypt ou PBKDF2 ou scrypt. Mais il est clair que même les bons programmeurs se trompent trop souvent. alors soyez prudent avec la façon dont vous les utilisez et n'essayez pas d'inventer le vôtre.
Parce que c'est ainsi que fonctionnent les fonctions de hachage cryptographiques, ce sont des fonctions mathématiques à sens unique (du simple au hachage). Des algorithmes sont créés et testés spécifiquement pour éviter cela, et également éviter les collisions (2 textes simples différents génèrent le même hachage).
Vous pouvez lire plus sur wikipedia , mais le point principal de l'article est:
La fonction de hachage cryptographique idéale a quatre propriétés principales ou importantes:
- il est facile (mais pas nécessairement rapide) de calculer la valeur de hachage pour un message donné
- il est impossible de générer un message qui a un hachage donné
- il est impossible de modifier un message sans changer le hachage
- il est impossible de trouver deux messages différents avec le même hachage
La plupart des attaques contre les fonctions de hachage sont basées sur la recherche de collisions (donc 2 textes en clair différents correspondront au même hachage) ou la pré-génération de millions de hachages et leur comparaison jusqu'à ce que vous trouviez la plaine qui l'a généré.
Longue histoire courte: si un algorithme de hachage est ingénierie inverse ou peut être attaqué de cette façon, ce n'est pas un bon algorithme de hachage.
Pour les mots de passe, enquêter sur BCrypt, cet article a beaucoup d'informations à ce sujet.
Imaginez une fonction de hachage qui utilise un seul bit pour le hachage. Votre hachage peut donc être égal à 0 ou 1.
Et disons que la fonction de hachage additionne chaque octet de données et si les données étaient paires, la valeur de hachage est 0. Si les données étaient impaires, le hachage est 1.
Voyez-vous pourquoi vous n'avez pas pu récupérer vos données par rétro-ingénierie de cette fonction de hachage?
C'est la même chose pour les algorithmes de hachage réels, seules les formules sont nettement meilleures que la fonction que je viens de décrire.
Votre difficulté peut être que vous envisagez le hachage en ce qui concerne leur utilisation pour les mots de passe. Ce n'est pas évident pourquoi vous ne pouvez pas récupérer un mot de passe à 8 caractères à partir d'un hachage de 128 bits. Mais cette fonction de hachage que vous utilisez pour les mots de passe peut également être utilisée pour calculer le hachage d'un téraoctet entier de données, et le hachage ne prendra toujours que 128 bits de données. De toute évidence, vous ne pouvez pas rétroconcevoir ce hachage 128 bits et récupérer votre téraoctet de données.
En outre, en supposant que vous disposiez de toutes les permutations possibles d'un seul téraoctet de données, il y aurait une énorme quantité de données différentes qui généreraient le même hachage. Après tout, si vous avez plus de 2 ^ 127 permutations de données différentes, vous risquez de rencontrer deux données différentes qui ont le même hachage.
Il existe des algorithmes intrinsèquement non réversibles; ils transforment une entrée A en une sortie B de telle manière que même si vous connaissez les étapes exactes de l'algorithme, vous ne pouvez pas récupérer A de B.
Un exemple très simple: convertissez chaque caractère du mot de passe en sa valeur ASCII et additionnez toutes les valeurs. Il n'y a aucun moyen de récupérer le mot de passe d'origine à partir du résultat.
Il y a un aspect du problème que les gens manquent dans les réponses précédentes. C'est la nature plusieurs à une des fonctions de hachage. Étant donné que la plupart des fonctions de hachage sont des sorties de longueur fixe (par exemple 256 bits), techniquement, il existe une infinité de chaînes qui hachent toutes à la même valeur.
Par exemple, si vous prenez toutes les chaînes de 512 bits (dont 2 ^ 512). Il n'y a que 2 ^ 256 sorties de la fonction de hachage. Ainsi, pour chaque sortie de la fonction de hachage, il y a environ 2 ^ 256 512 chaînes de bits qui hachent à cette valeur. Je dis à peu près parce que nous ne savons pas si la fonction de hachage est en fait une fonction aléatoire, elle pourrait avoir de légers biais.
Ainsi, étant donné un résumé, il existe de nombreuses chaînes qui hachent à la même valeur. Par conséquent, si vous définissez "inverser une fonction de hachage" comme sortie du mot de passe des utilisateurs, comment votre fonction d'inversion va-t-elle gérer le nombre potentiellement infini de chaînes qui aboutissent au résumé donné?
Vous demandez "pourquoi est-il important que les fonctions de hachage soient à sens unique?" C'est une propriété de sécurité.
Il existe deux types de "hachage" (ou "résumé de message" comme on les appelle) couramment utilisés aujourd'hui. L'un est un résumé de message simple, que vous connaissez peut-être comme un algorithme de somme de contrôle, tel que CRC32. L'algorithme est conçu de sorte qu'un seul changement de bit dans l'entrée produira une valeur de résumé différente. Le but principal de ceci est de s'assurer qu'un message n'est pas corrompu par accident. Des sommes de contrôle CRC32 sont présentes sur chaque paquet TCP/IP, et une mauvaise correspondance entraîne une retransmission pour corriger l'erreur.
Les résumés de messages sont souvent utilisés en cryptographie dans le cadre de la "signature" d'un message. Le message est chiffré par l'expéditeur avec sa clé privée, et n'importe qui peut utiliser la clé publique pour valider qu'il a été chiffré uniquement par l'expéditeur. Mais la cryptographie à clé publique RSA ne peut chiffrer que les messages inférieurs à la taille de la clé (256 octets), qui sont beaucoup plus courts que la plupart des messages utiles. Les algorithmes de résumé des messages produisent des valeurs inférieures aux clés RSA. Ainsi, en chiffrant le résumé au lieu du message, les signatures RSA peuvent être utilisées sur n'importe quel message de taille.
Mais un résumé de message ordinaire n'est pas sécurisé contre un attaquant. Considérons une somme de contrôle très simple qui additionne simplement les valeurs des caractères. Si vous signiez une telle somme de contrôle, je pourrais échanger tout autre message qui produit la même somme de contrôle, et les signatures correspondraient, trompant la victime.
Une autre utilisation courante pour les résumés de messages est la protection par mot de passe pendant le stockage. Si vous cryptez les mots de passe avant de les stocker dans le système, un administrateur système qui connaît la clé pourrait tous les décrypter. (Vous avez peut-être remarqué ce problème récemment lorsque certains sites Web ont été piratés.)
Pour éviter ces problèmes, un autre type de hachage est nécessaire, celui qui est "cryptographiquement sécurisé". Un algorithme de hachage sécurisé a deux propriétés supplémentaires, résistance aux collisions et non-réversibilité.
La résistance à la collision signifie que je ne devrais pas être en mesure de trouver un message qui produit le même condensé. De cette façon, je ne peux pas échanger mon mauvais message contre votre bon message.
La propriété de non-réversibilité signifie que je ne peux pas transformer un résumé en texte clair, donc je ne peux pas décrypter le message d'origine, comme le mot de passe de l'utilisateur.
La création d'un résumé est un problème très similaire au cryptage, dans la mesure où vous devez brouiller les données de manière à ce qu'elles ne fuient aucune information sur les données d'origine. C'est encore plus difficile, car le même calcul ne doit donner aucun indice sur la façon de créer une collision avec succès.
Je pense qu'il y a plusieurs raisons, mais une est évidente: un condensé produit par une fonction de hachage ne peut jamais contenir des informations infinies, car le condensé a des bits finis. Mais la fonction de hachage peut être utilisée pour hacher des entrées d'informations infinies. L'entrée peut en fait être n'importe quoi.
La difficulté de découvrir une collision n'est pas la réponse. La vraie difficulté est de prouver que vos données d'origine sont en fait la seule entrée possible qui correspond à un certain résumé. Je pense que vous ne pouvez jamais calculer une entrée et prétendre que c'est la seule réponse au résumé.
D'autres ont expliqué pourquoi de bonnes fonctions de hachage cryptographique sont difficiles à inverser - mais selon cet article Wikipedia , LanMan est mal conçu et peut être inversé relativement facilement:
Bien qu'il soit basé sur DES, un chiffrement de bloc bien étudié, le hachage LM n'est pas une véritable fonction à sens unique car le mot de passe peut être déterminé à partir du hachage en raison de plusieurs faiblesses dans sa mise en œuvre ... En montant une attaque par force brute sur chaque moitié séparément, les machines de bureau modernes peuvent casser des hachages alphanumériques LM en quelques heures ... En 2003, Ophcrack, une implémentation de la technique de table Rainbow, a été publiée. Il cible spécifiquement les faiblesses du chiffrement LM et inclut des données pré-calculées suffisantes pour casser pratiquement tous les hachages alphanumériques LM en quelques secondes.