DUPLICATES possibles: strong>
est-il possible de déchiffrer les hachages MD5?
est-il possible d'inverser un SHA1? P>J'ai posé cette question: Travailler avec une feuille de calcul énorme p>
et obtenu une bonne réponse et j'ai suivi la conseils. J'ai utilisé ceci: http://splinter.com.au/blog/?p=86
et j'ai haché environ 300 000 éléments différents dans une colonne dans une feuille de calcul Excel p>
puisque vous pouvez faire: p>
xxx pré> et vous " d Retour: p>
2fd4e1c67a2d28fced849ee1bb76e7391b93eb12
11 Réponses :
réponse générale
a Fonction de hachage cryptographique ne peut pas être facilement inversée. C'est pourquoi il est également parfois appelé une fonction à sens unique. Il n'y a pas de retour.
Vous devez également faire attention à l'appelant à ce "déchiffrement". Le hachage n'est pas la même chose que le cryptage. L'ensemble de la valeur de hachage possible est généralement plus petit que l'ensemble d'entrées possibles afin de multiples entrées de carte vers la même sortie.
Pour toute fonction de hachage donnée à la sortie, vous ne pouvez pas savoir laquelle des nombreuses entrées a été utilisée pour générer cette sortie particulière.
Pour les hachages cryptographiques comme SHA1, il est très difficile de trouver même une entrée une qui produit cette sortie.
Le moyen le plus simple d'inverser un hachage cryptographique est de deviner l'entrée et le hachage de voir s'il donne la bonne sortie. Si vous avez tort, devinez à nouveau. Une autre approche consiste à utiliser Tables arc-en-ciel .
concernant l'utilisation de hachage pour chiffrer les SSNS
Avec votre cas d'utilisation de SSNS, une attaque est réalisable en raison du nombre relativement faible de valeurs d'entrée possibles. Si vous êtes inquiet pour les personnes ayant accès à SSNS, il peut être préférable de ne pas stocker ni utiliser le SSN du tout dans votre application, et en particulier ne les utilisez pas comme identifiant. Au lieu de cela, vous pouvez trouver ou créer un autre identifiant, par exemple une adresse électronique, un nom de connexion, un GUID ou un numéro d'incrémentation. Il peut être tentant d'utiliser le SSN tel qu'il est déjà là et à première vue semble être un identifiant unique immuable, mais en pratique en utilisant simplement des problèmes. Si vous avez absolument besoin de le stocker pour une raison quelconque, utilisez une forte cryptage non déterministe avec une clé secrète et assurez-vous de garder cette clé de sécurité.
Si vous connaissez l'algorithme de hachage, est-il possible de revenir en arrière?
Non, pas possible avec un algorithme de hachage.
+1, une fois que vous allez noir, il n'y a pas de retour
Voir ma réponse ci-dessous. Oui, vous pouvez facilement obtenir un numéro SSN de retour d'un hachage SHA1 si vous ne le selez pas! Il suffit de générer le hachage SHA1 de tous les SSN (environ 10 millions) correspondant directement au hachage non salué au hachage dans la feuille de calcul. Que faudrait-il, environ 2 minutes pour générer toute la liste de 10 millions de hachages SSN ???
désolé mais pouvez-vous s'il vous plaît expliquer à moi comment utiliser des tables arc-en-ciel?
@Zak qui suppose que vous savez que la cible ici est une SSN
@blockhead: Non, il est possible de trouver un ensemble de préimages. Avec des fonctions de hachage simples par exemple. f (x) = x% 7 , si nous savions f (x) == 4 , nous pouvons immédiatement déduire x dans [4, 11, 18, ...] et la bonne entrée est dans l'une d'entre elles. C'est la même chose pour les fonctions de hachage cryptographique, sauf qu'il est conçu pour être extrêmement difficile à calculer l'inverse.
@Blockhead: C'est une entreprise très risquée qui repose sur la sécurité par l'obscurité. Ce n'est pas un très gros saut pour quelqu'un de regarder un ensemble de données, rappelez-vous que SSN a été recueilli avec toutes les autres informations, puis je me demande, «Oh, je me demande si ce n'est que le numéro SSN Hashed». Même chose avec les numéros de carte de crédit.
@Ser Rainbow Tables sont un peu trop complexes pour donner un tutoriel complet sur une réponse afin de répondre (mais Internet a beaucoup d'informations sur eux, alors faites une recherche). L'idée générale est que vous pré-calculez des haubans pour tout un tas de plaintes candidats et utilisez ensuite un moyen intelligent de faire une recherche inversée pour trouver quel clairect correspond à un hachage donné. Cette technique est toutefois facilement vaincue par "salage" des plaintes (modifiant chacune d'elles de manière unique mais déterministe, avant le hachage).
@Zak Salting seul ne suffira pas pour un petit domaine tel que SSNS. Cela rendra la vie plus difficile en obligeant l'attaquant à brut-force chacun séparément, mais le domaine est toujours assez petit qu'une attaque de force brute est pratique.
Nick, alors quelle est votre suggestion?
@NICK - voir ma réponse ci-dessous ... avec un sel assez grand et en gardant votre secret de sel, vous pouvez tout d'abord éviter une masse de passage unique de la masse de tous les SSN et en faire un grand nombre de fois plus difficile à brute la force de brute. ....
@ user298234987509328745509823745: Si vous faites une fonction qui mappe une SSN à une valeur unique de manière déterministe, quiconque connaît cette fonction peut l'appeler pour toutes les valeurs SSN possibles et voir les valeurs existantes dans votre base de données. Les deux manières que je peux penser à empêcher que quelqu'un de faire cela est: a) empêcher les gens de connaître la fonction. Mais si vous devez inclure la fonction dans votre fichier Excel, cela ne fonctionnera pas. b) Faites de votre fonction si lent que la force brute est infaisable. Voir «Renforcement des essences»: en.wikipedia.org/wiki/key_stressive Nith Aucun option est agréable ...
@ZAK Si c'est secret, ce n'est pas un sel - c'est un HMAC mal mis en œuvre. @ user298234987509328745509823745 Si vous avez la capacité de stocker un secret, utilisez un HMAC, qui empêchera toute personne de trouver un prétimage sans la clé secrète. Mieux encore, ne donnez pas aux gens l'accès à cette feuille de calcul si elles ne devraient pas connaître le SSN.
Un bon hash est aller simple, ce qui signifie que vous ne devriez pas être capable d'aller en arrière. Le point est de fournir une clé d'une chaîne sans révéler la chaîne. Par exemple, c'est un bon moyen de faire correspondre des mots de passe sans stocker un mot de passe. Au lieu de cela, vous stockez un hachage et comparez le hachage d'intrants résultant.
Si vous connaissez l'algorithme de hachage, est-il possible de revenir en arrière?
Peut-être, mais beaucoup sont conçus pour rendre cela très difficile. Certains algorithmes génèrent le même hachage pour différentes entrées, et beaucoup, sinon tout, dépendent de la longueur de l'entrée. Vous devez en savoir beaucoup sur les données supprimées pour y retourner.
C'est la différence entre une fonction de hachage «normale», comme vous l'utiliseriez dans une carte Python ou Java.Util.HashMap et une fonction de hachage cryptographique comme SHA1. Les fonctions normales de hachage sont principalement optimisées pour la diffusion des bits d'entrée dans l'entrée (couverture sur toute la plage de sortie de hachage) et efficacité. Un hachage cryptographique ajoute également la contrainte non réversible, avec une efficacité comme une contrainte de second ordre.
cryptage et hachage sont deux choses différentes.
hachage digère simplement la chaîne en un nombre. Le cryptage conserve le contenu de la chaîne afin qu'il puisse être déchiffré ultérieurement. Il n'y a pas de méthode d'obtenir la chaîne d'origine d'un hachage. Le contenu n'est tout simplement pas là.
'Xept si vous avez toutes les cordes qui correspondaient au hachage, ensuite parcouru à travers eux.
Je ne suis pas d'homme mathémique mais ce ne serait pas des cordes d'infini?
Non. Le point d'un hachage est que c'est un cryptage à sens unique (comme les autres ont souligné, ce n'est pas vraiment "cryptage", mais reste avec moi ici). L'inconvénient est la, en théorie, il existe une petite possibilité de "collisions", lorsque deux ou plusieurs chaînes renvoient le même hachage. Mais ça vaut généralement ça.
Le point entier d'un hachage cryptographique est que vous ne pouvez pas le déchiffrer et que celui-ci chiffre de la même manière à chaque fois.
Un cas d'utilisation très courant pour les hachages cryptographiques est la validation du mot de passe. Imaginez que j'ai le mot de passe "mypass123" et le hachage est "AEF8976A17371BBCD". Ensuite, un programme ou un site Web souhaitant valider mon mot de passe peut stocker le hachage "AEF897676A17371BBCD" dans leur base de données, au lieu du mot de passe, et chaque fois que je souhaite vous connecter, le site ou le programme rétablit mon mot de passe et veille à ce que les hatus correspondre. Cela permet au site ou au programme d'éviter de stocker mon mot de passe réel, et protège ainsi mon mot de passe (au cas où il est un mot de passe que j'utilise ailleurs) dans le cas où les données sont volées ou non compromises - un pirate informatique ne serait pas capable de revenir en arrière du hachage au mot de passe.
Une autre utilisation courante des hachages cryptographiques est la vérification de l'intégrité. Supposons un fichier donné (par exemple une image d'un CD de distribution Linux) dispose d'un hachage cryptographique connu, disponible publiquement disponible. Si vous avez un fichier qui prétend être la même chose, vous pouvez le récupérer vous-même et voir si le match des hachages. Ici, le fait qu'il accueille de la même manière chaque fois que chaque fois la validait de manière indépendante, et le fait qu'il soit cryptographiquement signifie que personne ne peut créer de manière gérée de faux fichier différent (par exemple avec un chevaux de Troie) qui a le même hachage.
Gardez à l'esprit la très grande distinction entre le hachage et le cryptage, bien que: Hashing perd des informations . C'est pourquoi vous ne pouvez pas aller en arrière (déchiffrer) le hachage. Vous pouvez utiliser un fichier de 20 gib et vous retrouver avec un hachage de 40 caractères. De toute évidence, cela a perdu beaucoup d'informations dans le processus. Comment pouvez-vous éventuellement "déchiffrer" 40 caractères à 20 Gibib? Il n'y a pas de compression qui fonctionne bien! Mais c'est aussi un avantage, car afin de vérifier l'intégrité d'un fichier de 20 gib, il vous suffit de distribuer un hachage de 40 caractères de 40 caractères.
Parce que les informations sont perdues, de nombreux fichiers auront le même hachage, mais la principale caractéristique d'un hachage cryptographique (qui parle de quoi vous parlez) est que malgré le fait que l'information est perdue , il est informellement infaisable de commencer par un fichier et de construire un deuxième fichier légèrement différent qui a le même hachage. Tout autre fichier avec le même hachage serait radicalement différent, et pas facilement à la maugeable pour le fichier d'origine.
C'est une excellente réponse! Je vous remercie. Si vous connaissez l'algorithme de hachage, est-il possible de revenir en arrière?
Non, vous ne pouvez pas aller en arrière, c'est tout le point. La raison est que la hache perd des informations. J'ai édité ça dans ma réponse.
+1 pour "Hashing perd des informations", c'est pourquoi vous ne pouvez pas revenir!
@ user298234987509328745509823745- Vous ne pouvez pas "aller en arrière" dans le sens de l'inversion de la formule mathématique, en appliquant votre hachage et ré-générer votre entrée d'origine. Vous pouvez toutefois créer une table de toutes les entrées possibles, exécutez-les via la fonction Hash et stockez l'entrée + Résultat de hachage dans une table. Utilisez cette table pour revenir à la recherche quelles entrées possibles auraient pu générer cette sortie. En tant que Tyler mentionné, plusieurs entrées différentes vous donneront la même sortie. Même si vous aviez le temps / stockage pour générer une telle table, vous aurez toujours un certain nombre d'entrées possibles.
L'utilisateur cible cependant les numéros SSN. Tout le monde ici devrait lui rappeler de saler ses hatumes ..
Non. Au moins pas facilement.
SHA1 est toujours considéré comme cryptographiquement sécurisé. Un algorithme de hachage est sécurisé s'il est facile de calculer une solution, mais très difficile (recherche exhaustive) pour calculer l'autre sens. Il est vrai que chaque fois que vous cryptez une phrase spécifique, cela entraînera le même hachage, mais il y a des phrases infinies qui auront également une hausse de cette même valeur. La sécurité provient de ne pas savoir quelles sont ces autres phrases jusqu'à ce que vous les exécutions tout au long de la fonction SHA1.
Non, vous ne pouvez pas revenir en arrière car il n'est pas assez d'informations est préservé par la fonction de hachage.
Vous pouvez y penser comme la fonction de hachage mappant le texte original à un seul nombre, énorme, nombre. Ce même numéro peut également être mappé sur d'autres textes également, bien qu'une bonne fonction de hachage aura peu de collisions:
Si le message d'origine a été crypté, vous pouvez revenir en arrière.
qu'il crypte le même texte de la même manière à chaque fois que tout le point d'un hachage. C'est une fonctionnalité.
Si j'ai une base de données des mots de passe de mots de passe, je peux vérifier que vous avez entré le mot de passe correct en hachaillant et en voyant si le hachage correspond à ce que j'ai dans la base de données pour vous. Mais si quelqu'un a volé ma base de données de hashes, ils ne seront pas en mesure de comprendre ce que votre mot de passe est à moins qu'ils trébuchent accidentellement sur un texte brut qui a atteint cette valeur.
dans la cryptographie, il s'appelle un digest. Un digest cryptographiquement fort ne permet pas d'obtenir un texte source en fonction de la valeur de Digest sans certaines connaissances supplémentaires. Une valeur de Digest est la même pour le même texte, vous pouvez donc calculer la digère du texte et le comparer avec un digest publié. Une application populaire est la vérification du mot de passe, de sorte que vous puissiez enregistrer le digest au lieu du mot de passe. Ceci est bien entendu sujet à une attaque de dictionnaire que vous avez déjà explorée, et c'est pourquoi il est fortement recommandé de ne pas utiliser les mots de dictionnaire pour les mots de passe.
Non, vous ne pouvez pas revenir en arrière. Comptez combien de hashes différents vous pouvez avoir. Maintenant, comptez combien de chaînes différentes vous pouvez avoir. Le premier est fini, la seconde est infinie. Il y a beaucoup de chaînes (infiniment nombreuses, à être précises) qui ont la même somme SHA1. Le point est cependant très difficile de trouver deux textes, qui ont le même hachage.
Vous pouvez penser à hachage comme raccourcir quelque chose. Par exemple, prenez une fonction de hachage qui résume tous les codes ASCII des lettres d'une chaîne. Vous ne pouvez pas dire ce qui était avant hachage, connais simplement la somme des codes ASCII des lettres. Il est similaire avec SHA1, mais plus compliqué.
Le point de hachage n'est pas de chiffrer quelque chose. Le point de hachage est de raccourcir quelque chose, de manière à vérifier si deux choses ont la même chose prend moins de temps. Maintenant, comment pouvez-vous dire que deux choses sont la même chose si vous savez que beaucoup de choses ont le même hachage? Eh bien, vous ne pouvez pas. Vous supposez simplement que c'est si rare que cela ne se produise pas.
Mais le hachage ne concerne pas seulement la vérification, car la vérification de l'égalité à l'aide de hachages est généralement utilisée pour la confirmation / la validation et elle n'est pas déterministe. Si vous voyez que les hachages sont identiques, alors basez sur les paramètres d'une fonction de hachage particulière, vous pouvez estimer la probabilité que les objets hachés sont effectivement les mêmes.
Et c'est pourquoi le fait qu'une fonction de hachage donne toujours les mêmes résultats pour les mêmes objets est la caractéristique la plus importante d'une fonction de hachage. Il vous permet de valider et de comparer des objets.
Je vois votre point basé sur le fait que vous essayez de masquer les numéros de sécurité sociale. Si quelqu'un sait que vous utilisez un SHA1HASH sur la SSN pour créer un identifiant unique, vous pouvez simplement générer une liste rapide de tous les numéros SSN, SHA1HASHSHS, puis comparez-les automatiquement à la SSN de la personne dans l'enregistrement. Pire encore, ils peuvent préenrer tous ceux-ci dans une table de recherche de hasch et avoir une clé de 1 hachage pour chaque SSN. Ceci s'appelle une table de recherche de hachage et des formes plus complexes sont appelées tables arc-en-ciel.
C'est pourquoi une deuxième caractéristique de hachage a été inventée. C'est ce qu'on appelle Salting. Salage est fondamentalement ceci; Vous créez un sel, puis modifiez vos données à l'aide du sel. Par exemple, disons que vous aviez le SSN 123-45-6789. Vous pourriez saler avec la chaîne "Moonbeam". Votre nouvelle chaîne pour hachage est "123-45-6789moonbeam"
Maintenant, même si quelqu'un sait que vous hachez le SSN pour générer votre identifiant unique, ils ne connaissent toujours pas le sel que vous utiliserez et sont donc incapables de dériver le SSN d'origine en pré-hache une liste de toutes les SSN et de comparer à votre identifiant. Cependant, vous pouvez toujours prendre le SSN de l'utilisateur, utiliser le sel et réhabiter le sel SSN + pour voir si l'utilisateur SSN correspond à son identifiant.
Enfin, si vous utilisez un seul sel pour tout, Et gardez-le secret, au lieu de pouvoir voir le sel et générer le SSN correspondant en exécutant des incréments SSN + 100 millions de fois et en choisissant le match, ils doivent faire beaucoup plus de travail pour récupérer SSN. En effet, les 100 millions de numéros SSN ont une quantité relativement faible d'entropie. (10 ^ 9 combinaisons). En ajoutant votre sel et en gardant le secret, au lieu de simplement exécuter ils devront exécuter à quel point ils ont finalement réussi à craquer le SSN + sel Ils ne savent même pas comment Beaucoup de personnages ont longtemps votre sel est
Donc, c'est 10 ^ (nombre de caractères de votre sel) fois plus de travail à faire pour obtenir 1 SSN, sans parler de la table entière. Mise à jour:
Plusieurs années plus tard, je vois que mes informations sur la salage étaient incorrectes lorsque j'ai répondu à cette question. Veuillez consulter les informations correctes dans les messages et les commentaires ci-dessous sur l'utilisation de sels uniques par entrée, car c'est toujours le premier message de la chaîne. Si vous pensez que je devrais changer l'OP après avoir lu ceci, laissez un commentaire ci-dessous (ou upvote One), et si le consensus est là, je vais le corriger.
Un sel est pas un secret! Les sels devraient être annexés à la valeur hachée et servir à prévenir le précomputation des attaques de dictionnaires. Ce que vous faites référence, c'est plus comme un HMAC - auquel cas vous devez utiliser un HMAC approprié plutôt que ce schéma ad-hoc.
Un sel n'est pas un secret, mais un sel peut être secret. J'essaie réellement d'adapter une solution au problème particulier de ce type. Prenez le numéro SSN. Si vous savez que c'est un numéro SSN et que vous voyez le sel juste dans la feuille de propagation, vous venez de courir dans les 100 000 000 hachages SHA1 pour toutes les SSN en utilisant ce sel et ce bingo, vous avez que les gars SSN. Gardez le secret de sel et vous n'aurez pas ce problème.
Je peux voir que ma réponse montre que le sel est un secret. Mise à jour pour corriger cela.
Une attaque possible sur le stockage de H (SSN || sel): Si l'attaquant s'enregistre (ou une personne d'autre, ou un SSN fictif) dans le système, ils peuvent probablement trouver la ligne correspondant à leur enregistrement et au hachage de leur SSN. Comme ils connaissent déjà leur propre SSN afin qu'ils puissent utiliser cette informatin à la force brute le sel (Moonbeam). Une fois qu'ils connaissent le sel, ils peuvent obtenir les autres SSN relativement facilement.
@ZAK Un sel secret n'est qu'un HMAC mal mis en œuvre. Les sels sont toujours stockés à côté du hachage. @Mark Sels, utilisé correctement, sont générés au hasard pour chaque valeur stockée - le sel d'une entrée n'indique aucune relation avec le sel sur un autre.
@Nick Johnson: Si vous devez stocker les sels par ligne associés au Mac, vous pouvez simplement vous assurer que les sels sont uniques et stockent le sel dans le fichier Excel sans aucune concaténation ni hachage. En fait, aucun besoin d'utiliser un sel, il suffit d'utiliser une série 1,2,3 ...
@Mark Le point d'un sel est d'empêcher le précomputation. Si c'est prévisible - une séquence, par exemple - il est possible que quelqu'un de précalcule une table de hachage possibles et de se sauver beaucoup de travail.
@Nick Johnson: Oui, mais vous manquez mon point. Si vous devez stocker une cartographie secrète séparée et sécurisée de SSNS aux sels, vous pouvez également utiliser simplement les "sels" comme identifiant aléatoire unique dans le fichier Excel et oublier l'étape de hachage. En fait, ne les appelez même pas de sels, appelez-leur des nombres aléatoires. Le point est de faire une cartographie déterministe. Si vous avez une base de données secrète de SSN-> Un certain nombre, c'est déjà une cartographie déterministe et sa irrésistible irréversible pour toujours quelle que soit la puissance de calcul. Le hachage du SSN n'est tout simplement pas nécessaire dans ce scénario.
@NICK JOHNSON: Sauf si vous parlez de des sels non secrets tels qu'ils sont traditionnellement utilisés, auquel cas nous parlons de deux choses complètement différentes ... peut-être que je n'ai peut-être pas assez clair? Je réponds à la réponse et en particulier à cette partie: "Ils ne connaissent toujours pas le sel que vous utiliserez". À mon avis, cette réponse est imparfaite et je démontrais une attaque contre elle. Si vous souhaitez proposer un système différent, je vous suggère de la publier comme une réponse séparée afin que je puisse commenter votre schéma là-bas et non ici et afin que les deux régimes différents ne soient pas confus.
@Nick Johnson: Un autre problème avec le sel différent par rangée qui met en feuille des sels secrets et non secrets est de savoir comment saurez-vous le sel à utiliser? Vous avez besoin d'une autre façon d'identifier la ligne et qui ne devront pas être basé sur le SSN qui me ramène au point que j'ai fabriqué dans ma réponse (dernier paragraphe). Fondamentalement - n'utilisez pas SSNS comme identifiant, qu'ils soient hachés ou non.
@Mark Si vous stockez un identifiant sans signification pour chaque utilisateur suffisamment suffisant, je doute que l'OP poserait des questions sur les SSN de hachage en premier lieu. Vraisemblablement, ils ont une raison impérieuse pour laquelle ils doivent stocker un hachage de la SSN. Comme je l'ai déjà dit, un "sel secret" n'est pas un sel - c'est un HMAC mal mis en œuvre. En ce qui concerne le sel - le sel devient une partie de la valeur hachée - hachage (valeur + sel) + sel. C'est assez de crypto de base.
@Mark - Un SSN haché n'est pas un SSN. C'est tout le point. Pour vraiment concevoir une bonne solution, OP devrait identifier plus clairement quel est le problème. J'ai créé ma réponse basée sur un besoin implicite qui compte tenu d'un SSN, quelqu'un devrait pouvoir rechercher l'utilisateur, mais ne doit pas stocker le SSN, et ne doit pas être en mesure d'inverser l'ingénieur le SSN facilement si vous êtes un utilisateur final. Regardant la feuille de calcul. Toute ma solution est fondée sur l'idée qu'il peut même y avoir une personne avec "accès administrateur" et qui connaît la clé secrète de hachage. Dire ne pas stocker que les SSN HAHSED, c'est comme dire ne pas stocker PWS hachées.
@ZAK: Peut-être que je me trompe et c'est une bonne solution ... Je suppose que vous dites que cela dépend de l'interprétation de la question. Il a quelques avotes et les acceptent donc beaucoup de gens ici pensent que c'est une bonne solution. Je ne suis toujours pas totalement convaincu que c'est une bonne idée, mais je ne pense pas que vous en discuterez en outre va changer d'avis ou à vous, alors je pense que je vais jeter un coup d'œil à d'autres questions maintenant. Félicitations pour obtenir l'acceptation.
Un meilleur titre à cette question serait "peut-être un hasch facilement être déchiffré?"
Qui vous a dit peut aller en arrière?
Avez-vous essayé d'aller en arrière? Avez-vous trouvé une fonction qui réellement fait en arrière?
Pouvez-vous inverser l'entropie?
Pour une idée de hashes simple consiste à cartographier une très large gamme de valeurs à une petite quantité avec une bonne distribution. Pour que l'idée cryptographique des hashes est difficile de trouver des valeurs de valeurs pour le hash.
Je suggérerais de déplacer la question de 20 Go à une autre question. Ils sont deux choses différentes
@Matt non, ce n'est pas parce que les hachages ne sont pas cryptage. Mieux serait "puis-je trouver le prétimage d'un hash?"
Fondamentalement, une journée, quelqu'un a demandé: "Hé, j'ai besoin d'une bonne fonction qui ne peut aller qu'un seul moyen. Je me demande ce que je vais utiliser?" Après beaucoup d'essais différents, quelqu'un a inventé SHA1 afin de remplir ce besoin. Il est spécifiquement conçu pour ne faire qu'un seul moyen, même si vous connaissez la fonction. Voir Cryptage de clé publique pour une perspective différente au même problème.
Cartes de hachage Un nombre infini d'entrées possibles (plaintes) au nombre fini de sorties possibles (valeurs de hachage réelles). Pour 128 bits Hash, il y a 2 ^ 128 hachages possibles et un nombre infini de plaintes possibles. L'infini divisé par (2 ^ 128) est toujours l'infini. Donc, chaque valeur de hachage possible a un nombre infini de plaintes qui pourraient le produire. Donc, vous ne pouvez pas y retourner.
MD5 ^ -1 () Bien sûr, serait bien pour les pirates informatiques :)
@Nick Johnson, juste à l'aide du phrasé original!
Argh! Cela me rend fou: "Decrypt" est très, très mal dans ce contexte, mais je ne veux pas le changer car un nouveau venu T Le champ (c'est-à-dire quelqu'un qui poserait cette question) jamais pense "trouver une pré-image" et ne le rechercheras pas ou ne le reconnaîtra pas comme pertinent s'ils le voient. :: Je n'abandonnerai pas. Je ne pas obsédé. I pas Obsess i ne sera pas Obsess ! ::