Gli hash contengono uno qualsiasi dei dati del file originale?

Un hash è una mappatura da un input di lunghezza arbitraria ad un output di lunghezza fissa. Un malinteso comune è che le funzioni di hash non dovrebbero avere collisioni (casi in cui due input ottengono lo stesso hash). Questo è sbagliato. Ci deve essere un numero infinito di collisioni secondo il principio del pigeonhole, poiché la mappatura va da un input infinitamente grande a un'uscita a lunghezza fissa. Tuttavia, una buona funzione di hash dovrebbe rendere molto difficile trovare collisioni.

È possibile costruire un hash errato con una singola mappa di valori in 0 e qualsiasi altra mappa di valori in 1 . Da questo, sarebbe banale determinare che un hash di 0 significhi che i dati originali del file erano a . Ecco un'implementazione:

def bad_hash(x):
    if x == 'a':
        return 0
    return 1

Gli hash di buona qualità sono progettati per garantire che sia computazionalmente difficile eseguire qualsiasi mappatura inversa (passare da un hash a un input che genera l'hash) e garantire che un hash possa essere invertito in una quantità infinita di input dati (quindi, anche se trovi un valore che esegue il hash sulla destinazione, anche altri valori di input equivarrebbero allo stesso target).

Pertanto, per una buona funzione di hash (e sha-256 è certamente considerato buono), rivelare l'hash non rivela quali fossero i dati originali.

Per sha-256 , non esiste un modo noto per trovare i dati di input oltre alla ricerca esaustiva, e anche quando lo hai trovato, non puoi essere sicuro che quello sia stato il particolare dato di input.

Può contenere o meno. Ad esempio, è possibile prendere la prima lettera di un messaggio come hash. Può essere un buon algoritmo di hash per uno scopo particolare, ma sicuramente non è un buon hash crittografico .

Quindi suppongo che la tua domanda riguardi l'hash crittografico .

L'algoritmo di hash ideale crittografico ha (accanto ad altre) queste proprietà:

• Non è possibile generare un messaggio dal suo valore di hash tranne che da provare tutti i possibili messaggi .
• Una piccola modifica a un messaggio dovrebbe cambiare il valore hash così ampiamente che il nuovo valore hash appare non correlato con il vecchio valore hash .
• Non è possibile trovare due messaggi diversi con lo stesso valore hash .

(Nel mondo reale, sostituisci la parola "impossibile" con "altamente improbabile".)

Quindi, solo la prima di queste proprietà mostra che sei quasi corretto nella tua dichiarazione

The only way to know anything about the file is to recreate it independently through trial and error, where the hash offers nothing but confirmation that the created file matches the original.

perché ci sono alcuni problemi con esso:

• L'insieme di tutti i messaggi è infinito , quindi non c'è possibilità di eseguire una ricerca esauriente .

• Nel contesto della ricerca cieca l'hash non offre conferma che il file creato corrisponda all'originale in quanto vi sono molti e molte collisioni (stessi hash per messaggi diversi).

• È altamente improbabile che trovi anche 1 file (messaggio) con l'hash dato, quindi il metodo "tentativi ed errori" non ti darà altro che errori.

Ecco una risposta breve per i non esperti di tecnologia.

Chiedere se un hash buono

MD5("StackExchange") = f25cb1c6953bb0c62c639f3d7a242ec4

contiene qualcuno dei dati originali un po ' come chiedere, se il risultato della operazione modulo contiene qualsiasi suggerimento del quoziente e del divisore originali.

1337 % 2 = 1

In teoria - se viene dato solo 1 - un avversario potrebbe indovinare dopo un tempo molto lungo che hai usato 1337 e 2 come il quoziente e il divisore originali per arrivare a 1 . Se pensi a questo nel contesto di file e grandi quantità di dati, le congetture diventano insormontabili. È come sparare in aria con un fucile e cercare di colpire una molecola d'aria specifica . Possibile, ma davvero difficile.

In questo caso sarebbe molto facile trovare un altro quoziente e divisore che dia lo stesso risultato. Ma non è il caso di una normale funzione di hash.

Quando trovi un input che crea lo stesso hash di un secondo, si parla di collisione. Ad esempio 1337 % 2 = 1 e 1339 % 2 = 1 sarebbero proprio questo. Quando viene utilizzata una funzione hash buona , è quasi impossibile trovare collisioni. Se non lo è, è considerato crittograficamente insicuro. Questo è un argomento piuttosto complesso che è ampiamente discusso in questo sito e Cryptography StackExchange . Un tipico utente finale non deve preoccuparsi di questo. ^{[citazione necessaria]}

Non puoi ricavare i dati originali da un hash.

È come provare a ricreare un oggetto con alcune pile di vari atomi senza altre informazioni.

Inoltre, lo stesso hash può essere ottenuto da dati diversi (anche se l'occorrenza è estremamente rara e difficile da ottenere intenzionalmente - paper here ) che è chiamato collisione SHA (nel caso di SHA) che rende un proof-related ad un hash non valido al 100%.

and that it does not contain the original file’s data in any way?

Un hash è essenzialmente una funzione di f(I) -> O quindi c'è sempre una relazione tra I -> O . Se ti viene dato O , puoi calcolare un insieme di valori che producono O quando viene assegnato all'hash. Per una funzione hash crittograficamente strong ... questo è uguale a forza bruta ma considera questo scenario. Diciamo che dici al tuo capo che lui / lei è un b0d7afc8ffd4ec4150ce9bba29f20969 quindi non ci vorrà molto per loro per capire cosa stavi cercando di dire.

The serial number contains nothing about the file. The only way to know anything about the file is to recreate it independently through trial and error, where the hash offers nothing but confirmation that the created file matches the original.

Un hash crittograficamente strong non contiene nulla sui dati da cui è derivato ... tranne per il fatto che è stato derivato da qualche input e l'unico modo per sapere cosa c'era nel file è creare tutti i possibili file e vedere se i loro hash corrispondono.