Шифрование не может быть отменено?

У меня сложилось впечатление, что зашифрованная строка не может быть расшифрована, поэтому первоначальное значение теряется навсегда.

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

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=, это могло буквально отнять у вас миллиарды лет, чтобы выяснить, что оригинал был "доминирующим", если хеш хороший. Опять же, это полезно для предотвращения побочного ущерба в случае кражи списка паролей.

То, что вы делаете, само по себе не является «шифрованием»; это "хеширование". Основное различие между ними состоит в том, что шифрование является легко обратимым (с правильным ключом, конечно), в то время как хеширование предназначено для очень трудно устранить при любых обстоятельствах, кроме зная исходное сообщение в первую очередь.

Теоретически, хэши имитируют «случайного оракула», гипотетического гомункула с эйдетической памятью и способом генерирования совершенно уникальных, совершенно случайных чисел без верхнего предела диапазона. Вы дадите этому маленькому человеку сообщение, и произойдет одно из двух; либо он никогда не видел сообщение раньше, и в этом случае он генерирует новое случайное число и дает его вам в качестве дайджеста, или он видел это сообщение раньше, и поэтому он запоминает и дает вам число, которое он сгенерировал, когда увидел его: первый раз. В этой теоретической модели нет нулевой взаимосвязи между сообщением и его дайджестом, и без единого числа, которое когда-либо дважды появлялось в ГСЧ, нет возможности для столкновения.

К сожалению, у нас нет идеального случайного оракула; Идея имеет практическую невозможность для цифровой реализации, такую ​​как способность оракула эффективно хранить и эффективно вспоминать каждое сообщение, когда-либо хешированное кем-либо, и способность клиентов принимать число, которое может быть сотнями или тысячами десятичных цифр. в длину. Вместо этого у нас есть хеш-функции, которые являются необратимыми (односторонними) математическими операциями, которые работают с самим сообщением, чтобы создать детерминированное преобразование (то же сообщение => тот же хеш) без видимыхсвязь между хешем и исходным сообщением. Как упомянуто в комментариях, также не должно быть никаких предсказуемых изменений в значении хеш-функции, получаемых путем систематических изменений в сообщении; в идеале, каждый бит дайджеста должен иметь 50% шанс измениться, учитывая изменение одного бита сообщения.

Есть много вариантов использования хэш-функции; они используются для проверки запроса (например, учетные данные для входа в систему, например пароли), при этом обеим сторонам не нужно знать секрет открытого текста, и они используются в качестве контрольных сумм для проверки того, что сообщение не было подделано или повреждено. Они также используются в так называемых сценариях «доказательства работы»; вычислительные задачи, которые трудно выполнить, но легко проверить.

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