Шифрування неможливо відновити?

У мене складається враження, що зашифрований рядок не можна розшифрувати, тому початкове значення втрачено назавжди.

Однак, якщо наступний рядок завжди дорівнює "домініка" (моє ім'я), то чи не може бути логічного способу його змінити; як це не випадково, і не засноване на даті / часі, але є логічний метод для цього?

0WrtCkg6IdaV/l4hDaYq3seMIWMbW+X/g36fvt8uYkE=

Незалежно від того, що або скільки разів я шифрую "домінік" (рядок), це завжди дорівнює як вище. Отже, чи не може бути якийсь спосіб розшифрувати такий рядок?

Приклад того, про що я говорю:

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

Шифрування завжди можна змінити. Суть шифрування полягає в тому, щоб прийняти повідомлення та кодувати його секретним ключем, щоб лише інша людина, яка має ключ, могла змінити шифрування та прочитати повідомлення.

Те, що ви дивитесь тут, - хешування , яке не те саме, що шифрування, хоча криптографічні методи часто використовуються для впровадження хешей. Ідея хешу полягає в тому, що він використовує складні математичні прийоми для побудови нового значення, яке відображається на старе значення, яке можна повторити. Немає жодного ключа, і його не передбачається повернути назад. Криптографічно сильний хеш створюється з математичною властивістю, що, якщо у вас є цінність A, хеш якої є цінністю B, навмисно створити інше значення, Cяке також хеширується , дуже важко B.

Хеші не повинні бути оборотні, оскільки вони використовуються для аутентифікації. Якщо ви дасте мені ім’я користувача та пароль, ви дійсно не хочете, щоб я зберігав цей пароль у моїй базі даних, тому що якщо хтось увірветься і отримає доступ до моєї бази даних, він може отримати ваш пароль! Тому замість цього я б зберігав хэш вашого пароля в базі даних. Потім, коли ви входите в систему, я перевіряю, чи є ім’я користувача, яке відповідає вашому, із записом пароля, який відповідає хешу надісланого вами пароля, і якщо так, ви маєте автентифікацію, тому що дуже важко створити хеш-зіткнення ( два значення, які мають хеш на одне і те ж значення) з хорошим хешем, тому я майже повністю впевнений, що використаний вами пароль є правильним.

Інша властивість сильного криптографічного хешу полягає в тому, що його дуже важко повернути. Ви знаєте, що цінністю 0WrtCkg6IdaV/l4hDaYq3seMIWMbW+X/g36fvt8uYkE=є хеш для "домініка", тому що ви тільки що це розробили, але якщо ви цього не знали і не знали, з чого почати шукати, і все, що у вас було 0WrtCkg6IdaV/l4hDaYq3seMIWMbW+X/g36fvt8uYkE=, це може буквально зайняти вас мільярди років, щоб зрозуміти, що оригінал був "домінічним", якщо хеш - хороший. Знову ж таки, це корисно для запобігання пошкодження застави у випадку викрадення списку паролів.

Те, що ви робите, - це не "шифрування", саме по собі; це "хеширование". Основна відмінність між ними полягає в тому, що шифрування є легко оборотним (з правильним ключем, звичайно), в той час як хешування призначене для дуже важко усунути за будь-яких обставин, крім знаючи вихідне повідомлення в першу чергу.

Теоретично хеши моделюють "випадковий оракул", гіпотетичний гомункулус з ейдетичною пам'яттю та спосіб генерування ідеально унікальних, ідеально випадкових чисел без верхньої межі діапазону. Ви дасте цьому маленькій людині повідомлення, і відбудеться одна з двох речей; або він ніколи раніше не бачив повідомлення, і в цьому випадку він генерує нове випадкове число і дає це вам як дайджест, або він бачив цю мессенсу раніше, і тому він пам’ятає і дає вам число, яке він створив, коли побачив це перший раз. У цій теоретичній моделі існує нульова залежність між повідомленням та його дайджестом, і жодне число, яке ніколи не з'являється з RNG, не існує можливості зіткнення.

На жаль, у нас немає ідеального випадкового оракула; ідея має практичні можливості для цифрової реалізації, такі як здатність оракула ефективно зберігати та ефективно пригадувати кожне повідомлення, коли-небудь у будь-якому місці, що завгодно, і здатність клієнтів приймати число, яке може становити сотні чи тисячі десяткових цифр в довжину. Натомість у нас є хеш-функції, які є незворотними (односторонніми) математичними операціями, які працюють над самим повідомленням, щоб створити детерміновану трансформацію (те саме повідомлення => той же хеш) без видимихспіввідношення між хешем та оригінальним повідомленням. Як зазначалося в коментарях, також не повинно бути передбачуваних змін хеш-значень, вироблених внесенням систематичних змін у повідомлення; в ідеалі кожен шматочок дайджесту мав би 50% шансів зміни, враховуючи зміну одного біта повідомлення.

Існує багато застосувань для хеш-функції; вони використовуються для перевірки викликів (думаю, що вхідні дані, такі як паролі), без того, щоб обидві сторони знали секрет простого тексту, і вони використовуються як контрольні суми для перевірки того, що повідомлення не було підроблене чи пошкоджене. Вони також використовуються в так званих сценаріях "доказ роботи"; обчислювальні завдання, які важко виконати, але легко перевірити.

Якщо ви коли-небудь знаходили спосіб ефективного зворотного перетворення хешу для SHA256, щоб створити повідомлення (будь-яке повідомлення), яке призведе до цього хешу, це буде підтвердженням, демонструючи, що насправді хеш принципово зламаний. Насправді, SHA256 вважається безпечним, тобто немає документально підтвердженого методу, яким би практичним не було, починати з дайджесту хешу і створювати зіткнення повідомлення, яке потребує менше роботи, ніж просто спроба будь-якої можливості (що для SHA-256 ідеально 2 ^ 256 ~ = 10 ^ 77 можливостей).