Le chiffrement ne peut pas être inversé?

J'ai l'impression qu'une chaîne chiffrée ne peut pas être déchiffrée, la valeur d'origine est donc perdue à jamais.

Cependant, si la chaîne suivante est toujours égale à "dominic" (mon nom), il ne peut pas y avoir de moyen logique de l'inverser; étant que ce n'est pas aléatoire et n'est pas basé sur la date / l'heure, mais il y a une méthode logique?

0WrtCkg6IdaV/l4hDaYq3seMIWMbW+X/g36fvt8uYkE=

Peu importe quoi ou combien de fois je crypte "dominic" (chaîne), c'est toujours comme ci-dessus. Alors, ne devrait-il pas y avoir un moyen de déchiffrer une chaîne comme ça?

Exemple de ce dont je parle:

public string EncryptPassword(string password)
{
    return Convert.ToBase64String(
        System.Security.Cryptography.SHA256.Create()
        .ComputeHash(Encoding.UTF8.GetBytes(password)));
}

Le cryptage peut toujours être inversé. Le but du cryptage est de prendre un message et de le coder avec une clé secrète afin que seule une autre personne qui possède la clé puisse inverser le cryptage et lire le message.

Ce que vous regardez ici, c'est le hachage , ce qui n'est pas la même chose que le chiffrement, bien que des techniques cryptographiques soient souvent utilisées pour implémenter les hachages. L'idée d'un hachage est qu'il utilise des techniques mathématiques complexes pour construire une nouvelle valeur qui correspond à une ancienne valeur, qui est répétable. Il n'y a pas de clé et elle n'est pas censée être inversée. Un hachage cryptographiquement fort est créé avec la propriété mathématique que, si vous avez une valeur Adont le hachage est une valeur B, il est très, très difficile de créer intentionnellement une autre valeur Cqui est également hachée B.

Les hachages n'ont pas besoin d'être réversibles, car ils sont utilisés pour l'authentification. Si vous me donnez un nom d'utilisateur et un mot de passe, vous ne voulez vraiment pas que je stocke ce mot de passe dans ma base de données, car si quelqu'un pirate et accède à ma base de données, il pourrait obtenir votre mot de passe! Au lieu de cela, je stocke le hachage de votre mot de passe dans la base de données. Ensuite, lorsque vous vous connectez, je vérifie s'il y a un nom d'utilisateur qui correspond au vôtre, avec une entrée de mot de passe qui correspond au hachage du mot de passe que vous avez envoyé, et si c'est le cas, vous êtes authentifié, car il est très difficile de créer une collision de hachage ( deux valeurs qui hachent à la même valeur) avec un bon hachage, donc je suis presque parfaitement certain que le mot de passe que vous avez utilisé est le bon.

L'autre propriété d'un hachage cryptographique puissant est qu'il est très difficile à inverser. Vous savez que la valeur 0WrtCkg6IdaV/l4hDaYq3seMIWMbW+X/g36fvt8uYkE=est le hachage de "dominic" parce que vous venez de le découvrir, mais si vous ne saviez pas cela, et ne saviez pas par où commencer à chercher, et tout ce que vous aviez était 0WrtCkg6IdaV/l4hDaYq3seMIWMbW+X/g36fvt8uYkE=, cela pourrait littéralement vous prendre des milliards des années pour comprendre que l'original était "dominic", si le hachage est bon. Encore une fois, cela est utile pour éviter les dommages collatéraux en cas de vol d'une liste de mots de passe.

Ce que vous faites n'est pas du "chiffrement" en soi; c'est du "hachage". La principale différence entre les deux est que le cryptage est facilement réversible (avec la bonne clé bien sûr), tandis que le hachage est conçu pour être extrêmement difficile à inverser en toute circonstance autre que de connaître le message d'origine en premier lieu.

En théorie, les hachages simulent un "oracle aléatoire", un homoncule hypothétique avec une mémoire eidétique et un moyen de générer des nombres parfaitement uniques, parfaitement aléatoires sans limite supérieure de plage. Vous donneriez un message à ce petit homme, et l'une des deux choses se produirait; soit il n'a jamais vu le message auparavant, auquel cas il génère un nouveau nombre aléatoire et vous le donne comme résumé, soit il a déjà vu ce message, et donc il se souvient et vous donne le numéro qu'il a généré quand il l'a vu le première fois. Dans ce modèle théorique, il n'y a aucune relation entre un message et son résumé, et avec aucun numéro unique apparaissant deux fois dans le RNG, il n'y a aucune possibilité de collision.

Malheureusement, nous n'avons pas d'oracle aléatoire idéal; l'idée a des impossibilités pratiques pour une implémentation numérique, telles que la capacité de l'oracle à stocker efficacement et à rappeler efficacement tous les messages jamais hachés par n'importe qui, et la capacité des clients à accepter un nombre qui pourrait être des centaines ou des milliers de chiffres décimaux en longueur. Au lieu de cela, nous avons des fonctions de hachage, qui sont des opérations mathématiques irréversibles (unidirectionnelles) qui fonctionnent sur le message lui-même, pour créer une transformation déterministe (même message => même hachage) sans apparenterelation entre le hachage et le message d'origine. Comme mentionné dans les commentaires, il ne devrait pas non plus y avoir de changement prévisible de la valeur de hachage produite en apportant des modifications systématiques au message; idéalement, chaque bit du résumé aurait 50% de chances de changer, étant donné un changement à un seul bit du message.

Il existe de nombreuses utilisations pour une fonction de hachage; ils sont utilisés pour la vérification des défis (pensez aux informations d'identification de connexion comme les mots de passe) sans que les deux parties aient besoin de connaître le secret en texte brut, et elles sont utilisées comme sommes de contrôle pour vérifier qu'un message n'a pas été falsifié ou corrompu. Ils sont également utilisés dans des scénarios dits de «preuve de travail»; tâches de calcul difficiles à réaliser mais faciles à vérifier.

Si vous deviez trouver un moyen d'inverser efficacement un condensé de hachage SHA256 pour produire un message (n'importe quel message) qui entraînerait ce hachage, ce serait une preuve par démonstration qu'en fait, le hachage est fondamentalement rompu. SHA256 est, en fait, considéré comme sûr, ce qui signifie qu'il n'y a pas de méthode documentée, aussi pratique soit-elle, pour commencer par un condensé de hachage et produire un message entrant en collision qui nécessite moins de travail que d'essayer toutes les possibilités (ce qui, dans le cas de SHA-256, est idéalement 2 ^ 256 ~ = 10 ^ 77 possibilités).