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).