La crittografia non può essere invertita?

9

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), non può esistere un modo logico per invertirla; essendo come non è casuale né si basa sulla data / ora, ma c'è un metodo logico ad esso?

0WrtCkg6IdaV/l4hDaYq3seMIWMbW+X/g36fvt8uYkE=

Indipendentemente da quante o quante volte cifro "dominic" (stringa), equivale sempre come sopra. Quindi, non dovrebbe esserci un modo per decodificare una stringa del genere?

Esempio di ciò di cui sto parlando:

public string EncryptPassword(string password)
{
    return Convert.ToBase64String(
        System.Security.Cryptography.SHA256.Create()
        .ComputeHash(Encoding.UTF8.GetBytes(password)));
}
    
posta user1477388 08.07.2013 - 20:31
fonte

2 risposte

39

La crittografia può sempre essere invertita. Il punto di crittografia è di 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 vedendo qui è hashing , che non è lo stesso della crittografia, anche se le tecniche di crittografia sono spesso utilizzate nell'implementazione degli hash. L'idea di un hash è che utilizza complicate tecniche matematiche per costruire un nuovo valore che mappa un vecchio valore, che è ripetibile. Non c'è chiave, e non è pensato per essere invertito. Un hash crittograficamente strong viene creato con la proprietà matematica che, se si ha valore A il cui hash è il valore B , è molto, molto difficile creare intenzionalmente un altro valore C anche hash a B .

Gli hash non devono essere reversibili, perché vengono utilizzati per l'autenticazione. Se mi dai un nome utente e una password, davvero non vuoi che io memorizzi quella password nel mio database, perché se qualcuno vi accede e ottiene l'accesso al mio database, potrebbe ottenere la password! Quindi, invece, memorizzerei l'hash della tua password nel database. Quindi, quando effettui il login, controllo se c'è un nome utente che corrisponde al tuo, con una 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 certo che la password che hai usato sia quella giusta.

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

    
risposta data 08.07.2013 - 20:39
fonte
9

Quello che stai facendo non è "crittografia", di per sé; è "hashing". La principale differenza 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 se non conoscendo il messaggio originale nel primo posto.

In teoria, gli hash simulano un "oracolo casuale", un ipotetico homunculus con una memoria eidetica e un modo per generare numeri perfettamente unici, perfettamente casuali senza limiti di gamma superiore. Darebbe a questo piccolo uomo un messaggio e una delle due cose accadrebbe; o non ha mai visto il messaggio prima, nel qual caso genera un nuovo numero casuale e lo dà come digest, o ha già visto quel messaggio prima, e così si ricorda e ti dà il numero che ha generato quando l'ha visto prima volta. In quel modello teorico, non vi è alcuna relazione tra un messaggio e il suo riassunto, e se nessun numero singolo appare mai due volte dall'RNG non c'è possibilità di collisione.

Purtroppo, non abbiamo un oracolo casuale ideale; l'idea ha impossibilità pratica per un'implementazione digitale, come la capacità dell'oracolo di archiviare in modo efficiente e di richiamare in modo efficiente ogni messaggio mai cancellato da chiunque, e la capacità dei client 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 funzionano sul messaggio stesso, per creare una trasformazione deterministica (stesso messaggio = > stesso hash) con nessuna relazione apparente tra l'hash e il messaggio originale. Come menzionato nei commenti, non dovrebbe esserci alcun cambiamento prevedibile del valore hash prodotto apportando modifiche sistematiche al messaggio; idealmente, ogni bit del digest avrebbe una probabilità del 50% di cambiare, data una modifica di 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 conoscano il segreto del testo normale e vengono utilizzate come checksum per verificare che un messaggio non sia stato manomesso o danneggiato. Sono anche usati negli scenari cosiddetti di "prova del lavoro"; compiti computazionali difficili da completare ma facili da verificare.

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

    
risposta data 08.07.2013 - 21:22
fonte

Leggi altre domande sui tag