A criptografia não pode ser revertida?

Tenho a impressão de que uma cadeia criptografada não pode ser descriptografada, portanto o valor original é perdido para sempre.

No entanto, se a seguinte seqüência sempre é igual a "dominic" (meu nome), não pode haver uma maneira lógica de revertê-la; sendo que não é aleatório nem se baseia na data / hora, mas existe um método lógico para isso?

0WrtCkg6IdaV/l4hDaYq3seMIWMbW+X/g36fvt8uYkE=

Não importa o que ou quantas vezes eu criptografar "dominic" (string), sempre é igual ao acima. Então, não deveria haver alguma maneira de descriptografar uma string como essa?

Exemplo do que estou falando:

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

A criptografia sempre pode ser revertida. O ponto da criptografia é pegar uma mensagem e codificá-la com uma chave secreta para que somente outra pessoa que possua a chave possa reverter a criptografia e ler a mensagem.

O que você está vendo aqui é hash , que não é o mesmo que criptografia, embora as técnicas criptográficas sejam frequentemente usadas na implementação de hashes. A idéia de um hash é que ele usa técnicas matemáticas complicadas para criar um novo valor que mapeia para um valor antigo, que é repetível. Não há chave e não deve ser revertida. Um hash criptograficamente forte é criado com a propriedade matemática que, se você tiver um valor Acujo hash é valor B, é muito, muito difícil criar intencionalmente outro valor Cque também seja hash B.

Os hashes não precisam ser reversíveis, porque são usados ​​para autenticação. Se você me der um nome de usuário e uma senha, você realmente não quer que eu armazene essa senha no meu banco de dados, porque se alguém invadir e obter acesso ao meu banco de dados, poderá obter sua senha! Então, em vez disso, eu armazenaria o hash da sua senha no banco de dados. Então, quando você faz login, verifico se há um nome de usuário que corresponda ao seu, com uma entrada de senha que corresponda ao hash da senha que você enviou e, se estiver, você está autenticado, porque é muito difícil criar uma colisão de hash ( dois valores que hash para o mesmo valor) com um bom hash, então estou quase perfeitamente certo de que a senha que você usou é a correta.

A outra propriedade de um forte hash criptográfico é que é muito difícil reverter. Você sabe que o valor 0WrtCkg6IdaV/l4hDaYq3seMIWMbW+X/g36fvt8uYkE=é o hash para "dominic" porque você acabou de descobrir, mas se você não sabia disso e não sabia por onde começar a procurar, e tudo o que você tinha era 0WrtCkg6IdaV/l4hDaYq3seMIWMbW+X/g36fvt8uYkE=, poderia literalmente levar bilhões de anos para descobrir que o original era "dominic", se o hash for bom. Novamente, isso é útil para evitar danos colaterais no caso de uma lista de senhas ser roubada.

O que você está fazendo não é "criptografia", por si só; é "hash". A principal diferença entre os dois é que a criptografia é facilmente reversível (com a chave correta, é claro), enquanto o hash é projetado para ser extremamente difícil de reverter em qualquer circunstância que não seja conhecer a mensagem original em primeiro lugar.

Em teoria, os hashes simulam um "oráculo aleatório", um homúnculo hipotético com memória eidética e uma maneira de gerar números perfeitamente aleatórios e perfeitamente únicos, sem limite superior de faixa. Você daria uma mensagem a esse homenzinho e uma das duas coisas aconteceria; ou ele nunca viu a mensagem antes; nesse caso, ele gera um novo número aleatório e fornece isso para você como resumo, ou ele já viu essa mensagem antes, e então ele se lembra e fornece o número que gerou quando a viu. primeira vez. Nesse modelo teórico, não há relação zero entre uma mensagem e seu resumo e, como nenhum número único aparece duas vezes no RNG, não há possibilidade de colisão.

Infelizmente, não temos um oráculo aleatório ideal; a ideia tem impossibilidades práticas para uma implementação digital, como a capacidade do oráculo de armazenar e recordar com eficiência todas as mensagens já contidas por qualquer pessoa em qualquer lugar, e a capacidade dos clientes de aceitar um número que pode ter centenas ou milhares de dígitos decimais em comprimento. Em vez disso, temos funções hash, que são operações matemáticas irreversíveis (unidirecionais) que funcionam na própria mensagem, para criar uma transformação determinística (mesma mensagem => mesmo hash) sem aparenterelacionamento entre o hash e a mensagem original. Conforme mencionado nos comentários, também não deve haver alteração previsível no valor do hash produzido, fazendo alterações sistemáticas na mensagem; idealmente, cada bit do resumo teria 50% de chance de mudar, dada uma alteração em um único bit da mensagem.

Existem muitos usos para uma função hash; eles são usados ​​para verificação de desafios (pense em credenciais de login como senhas) sem a necessidade de ambas as partes conhecerem o segredo do texto sem formatação e são usados ​​como somas de verificação para verificar se uma mensagem não foi adulterada ou corrompida. Eles também são usados ​​nos chamados cenários de "prova de trabalho"; tarefas computacionais difíceis de concluir, mas fáceis de verificar.

Se você alguma vez encontrar uma maneira de reverter eficientemente um resumo de hash SHA256 para produzir uma mensagem (qualquer mensagem) que resultaria nesse hash, seria uma demonstração demonstrando que, de fato, o hash está fundamentalmente quebrado. O SHA256 é, de fato, considerado seguro, o que significa que não há método documentado, por mais prático que seja, começar com um resumo de hash e produzir uma mensagem coletiva que requer menos trabalho do que simplesmente tentar todas as possibilidades (o que é ideal para o SHA-256). ^ 256 ~ = 10 ^ 77 possibilidades).