La crittografia non può essere invertita?

Ho l'impressione che una stringa crittografata non possa essere decifrata, quindi il valore originale viene perso per sempre.

Tuttavia, se la seguente stringa è sempre uguale a "dominic" (il mio nome), allora non può esserci un modo logico per invertirla; essendo come non è casuale né si basa sulla data / ora, ma esiste un metodo logico?

0WrtCkg6IdaV/l4hDaYq3seMIWMbW+X/g36fvt8uYkE=

Non importa cosa o quante volte crittografare "dominic" (stringa), è sempre uguale a sopra. Quindi, non dovrebbe esserci un modo per decrittografare una stringa del genere?

Esempio di cosa sto parlando:

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

La crittografia può sempre essere invertita. Il punto di crittografia è prendere un messaggio e codificarlo con una chiave segreta in modo che solo un'altra persona che ha la chiave possa invertire la crittografia e leggere il messaggio.

Quello che stai guardando qui è l' hash , che non è lo stesso della crittografia, sebbene le tecniche crittografiche siano spesso utilizzate nell'implementazione degli hash. L'idea di un hash è che utilizza complicate tecniche matematiche per costruire un nuovo valore che si associa a un vecchio valore, che è ripetibile. Non c'è chiave e non è pensato per essere invertito. Un hash crittograficamente forte viene creato con la proprietà matematica che, se si dispone di un valore il Acui hash è valore B, è molto, molto difficile creare intenzionalmente un altro valore a Ccui anche l'hash B.

Gli hash non devono essere reversibili, perché vengono utilizzati per l'autenticazione. Se mi dai un nome utente e una password, in realtà non vuoi che io memorizzi quella password nel mio database, perché se qualcuno entra e accede al mio database, potrebbe ottenere la tua password! Quindi, invece, memorizzerei l'hash della tua password nel database. Quindi quando eseguo l'accesso, controllo per vedere se esiste un nome utente che corrisponde al tuo, con una voce password che corrisponde all'hash della password che hai inviato e, in tal caso, sei autenticato, perché è molto difficile creare una collisione hash ( due valori che hanno lo stesso valore) con un buon hash, quindi sono quasi perfettamente sicuro che la password che hai usato sia quella giusta.

L'altra proprietà di un forte hash crittografico è che è molto difficile invertire. Sai che il valore 0WrtCkg6IdaV/l4hDaYq3seMIWMbW+X/g36fvt8uYkE=è l'hash per "dominic" perché l'hai appena capito, ma se non lo sapessi e non sapessi da dove iniziare a cercare, e tutto ciò che avevi 0WrtCkg6IdaV/l4hDaYq3seMIWMbW+X/g36fvt8uYkE=, potrebbe letteralmente prenderti miliardi di anni per capire che l'originale era "dominico", se l'hash è buono. Ancora una volta, questo è utile per prevenire danni collaterali in caso di furto di un elenco di password.

Quello che stai facendo non è "crittografia", di per sé; è "hashing". La differenza principale tra i due è che la crittografia è facilmente reversibile (con la chiave corretta ovviamente), mentre l'hashing è progettato per essere estremamente difficile da invertire in qualsiasi circostanza diversa dalla conoscenza del messaggio originale in primo luogo.

In teoria, gli hash simulano un "oracolo casuale", un ipotetico omuncolo con una memoria eidetica e un modo per generare numeri perfettamente unici, perfettamente casuali senza limite superiore. Daresti un messaggio a questo ometto e succederebbe una delle due cose; o non ha mai visto il messaggio prima, nel qual caso genera un nuovo numero casuale e te lo dà come digest, o ha già visto quel messaggio prima, e così ricorda e ti dà il numero che ha generato quando lo ha visto prima volta. In quel modello teorico, non vi è alcuna relazione tra un messaggio e il suo digest e senza che un singolo numero appaia mai due volte dal RNG non c'è possibilità di una collisione.

Sfortunatamente, non abbiamo un oracolo casuale ideale; l'idea ha impossibilità pratiche per un'implementazione digitale, come la capacità dell'oracolo di archiviare e richiamare in modo efficiente ogni messaggio mai ricevuto da chiunque in qualsiasi luogo, e la capacità dei clienti di accettare un numero che potrebbe essere centinaia o migliaia di cifre decimali in lunghezza. Invece, abbiamo funzioni hash, che sono operazioni matematiche irreversibili (a senso unico) che lavorano sul messaggio stesso, per creare una trasformazione deterministica (stesso messaggio => stesso hash) senza apparenterelazione tra l'hash e il messaggio originale. Come menzionato nei commenti, non dovrebbe esserci alcuna modifica prevedibile al valore di hash prodotto apportando modifiche sistematiche al messaggio; idealmente, ogni bit del digest avrebbe una probabilità del 50% di cambiare, dato un cambio a un singolo bit del messaggio.

Ci sono molti usi per una funzione hash; vengono utilizzati per la verifica delle sfide (si pensi alle credenziali di accesso come le password) senza che entrambe le parti debbano conoscere il segreto del testo normale e vengono utilizzate come checksum per verificare che un messaggio non sia stato manomesso o danneggiato. Sono anche utilizzati nei cosiddetti scenari di "prove di lavoro"; compiti computazionali difficili da completare ma facili da verificare.

Se dovessi mai trovare un modo per invertire efficacemente un digest hash SHA256 per produrre un messaggio (qualsiasi messaggio) che provocherebbe tale hash, sarebbe una dimostrazione dimostrativa che in realtà l'hash è sostanzialmente rotto. SHA256 è, infatti, ritenuto sicuro, nel senso che non esiste un metodo documentato, non importa quanto pratico, iniziare con un digest hash e produrre un messaggio di collisione che richiede meno lavoro rispetto al semplice tentativo di ogni possibilità (che per SHA-256 è idealmente 2 ^ 256 ~ = 10 ^ 77 possibilità).