Riservatezza degli hash dei file

SHA-1 produce un hash a 160 bit. L'hashing di un file più lungo di 160 bit (20 ottetti) perderà quindi necessariamente le informazioni e rende impossibile la ricostruzione. In teoria, cioè.

D'altra parte, i file di hashing più brevi di 20 ottetti sono altamente probabili (praticamente garantiti) per produrre una mappatura 1: 1. Una mappatura 1: 1 significa che senza sale, è banale riportare l'hash ai contenuti originali con una tabella arcobaleno facilmente esistente. Anche con un tipico sale non segreto, è molto possibile eseguire un attacco a forza bruta su file molto brevi, quindi se si è preoccupati di ciò, è necessario aggiungere un sale sufficientemente lungo (ad esempio, 128 bit) e mantenere il segreto del sale (non è come si usa normalmente un sale, ma si ha anche una situazione diversa). Puoi aggiungere ulteriormente il nome di ogni file a the salt (a meno che ciò che stai cercando di fare sia la deduplicazione), quindi file diversi con contenuti identici hanno hash diversi.

In pratica, sebbene l'hash non possa essere invertito per i file più grandi di 20 ottetti, i file piccoli (ma più grandi di 20 ottetti) potrebbero ancora essere invertiti se l'attaccante è sufficientemente persistente. Ad esempio, esistono 65536 file con 22 ottetti ^[1] che hanno lo stesso SHA-1 e non è possibile dimostrare quale sia quello corretto. O puoi? Sfortunatamente la risposta è "sì". Sebbene ognuno di questi 65 file diversi sia una soluzione ugualmente valida dal punto di vista dell'hash, solo uno di essi (o forse due) sarà qualcosa che non è una spazzatura binaria casuale priva di senso. Che è banale da identificare usando un programma di compressione generico (i file di testo in chiaro sono comprimibili, la spazzatura casuale non lo è). Inoltre, se il nome di un file è noto, di solito è relativamente facile controllarne il contenuto rispetto ad alcuni magici byte o ad una particolare struttura. L'utente malintenzionato deve solo considerare i file che hanno byte magici che corrispondono al loro tipo.
Fortunatamente, questo attacco diventa rapidamente poco pratico. Ci sono già 10 file ²⁸ di lunghezza 32 che si associano allo stesso hash e la maggior parte dei file su ogni computer è più lunga!

E ora ecco una sorpresa: il "più sicuro" SHA-512 è in realtà meno sicuro a tale riguardo. Poiché esegue 512 bit, eseguirà un mapping 1: 1 per file fino a 64 byte .

La mia raccomandazione sarebbe:

1. Se davvero non vuoi (o non puoi) usare TLS / SSH (sai che rsync farà l'intero hash comparativo inclusa connessione SSH per te, don ' t you?), utilizzare un contenitore di crittografia come ad es Truecrypt. Ciò impedirà a qualcun altro di accedere agli hash anche se pubblichi il contenitore su Internet su un server non affidabile o se li invii via email.
   Questo rende ogni altra considerazione obsoleta. Non c'è bisogno di preoccuparsi se gli hash possono essere ripristinati se l'attaccante non li conosce!
2. Non utilizzare un hash più grande del necessario. La possibilità di una collisione casuale di hash in 10 ¹⁶ file (cioè 10 miliardi di volte il numero di file presenti sul mio computer desktop!) Con un hash a 160 bit è di circa 10 ^-15 . Per diecimila file, è 10 ^-22 . In altre parole, non succederà nella tua vita. Set di controlli di revisione come ad es. Git fa affidamento sul fatto che le collisioni semplicemente non accadono. Gli hash più grandi non rendono nulla di meglio nel tuo scenario, ma potrebbero addirittura peggiorare le cose (per i file di piccole dimensioni).
3. Salta il contenuto del file con nomi di file e con una quantità di sale casuale sufficientemente lunga da mantenere segreta.
4. Considera anche i nomi dei file di hashing, poiché i nomi dei file da soli possono trasmettere informazioni importanti.
5. Non trasmettere lunghezze di file. Non ti dà un vantaggio, ma può darlo a un utente malintenzionato.

La sicurezza che stai pensando per quanto riguarda la forza dell'hash e la sicurezza di cui stai parlando con gli hash su Internet sono due cose diverse. Gli hash come SHA * sono progettati per funzionare rapidamente in modo che i file che invii e il file che ricevi possano essere verificati per essere uguali, tuttavia, questo rende più facile la forza bruta, a causa di questa velocità.

Ciò a cui tutto si riduce sono i bit di entropia: più bit di entropia del file hanno, più tempo ci vorrà per indovinare. Direi che se il tuo file è più di un (limite arbitrario) 1kb, dovrebbe essere ragionevolmente al sicuro da brute-force.

Tuttavia, senza una connessione sicura, non puoi garantire che i messaggi non siano stati modificati durante il transito.

Se sei ragionevolmente sicuro che gli hash non verranno modificati durante il trasporto, questo dovrebbe essere un modo ragionevole per confrontare le due copie del file.

Domanda: vuoi pubblicare i nomi dei file sensibili su Internet?

Il tuo approccio sopra sembra implicare che pubblicherai i nomi dei tuoi file su Internet.

Potresti non volere che i tuoi nomi di file siano pubblicati su Internet.

brain@brain-laptop:~/Secret Files$ sha256sum *
c988f4a50da6021fc70f618faeb5e27891b5de7162fb395b1dfd5b42f76a8070  Blueprints for Secret Lair Island in the Philippines.docx
78530f114e56ed419950e465f79c33f14bcc91eb63acefcf976ab96cd190915a  Secret Plan to Take Over the World.docx

In alcune condizioni, gli hash potrebbero divulgare informazioni riservate.

Dipende se un utente malintenzionato può o meno intuire il contenuto di file specifici.

Come esempio banalizzato, diciamo che i tuoi file sono memo del tuo capo che dice quale dipendente stanno per licenziare. Sono sempre semplici file di testo ASCII sotto forma di The next employee we fire is [Name] . Quando lo sapevo e avrei una lista di impiegati, potrei calcolare le somme di hash di tutti i possibili file:

The next employee we fire is Alice   9a76503a707ae3b58c3a12324622d45dfbbbd0d6a35e9e539104e285e25b2965
The next employee we fire is Bob     0d42e6bbc62c1a308c85dded89b9f300afe2537539fc068eeb99e00f3154aac5
The next employee we fire is Charlie e3a0ab856e1440eba0d520e0c86f6db22a47675371db80dbccb55a207db9a0dc

Quando si trova una corrispondenza, conosco il contenuto del file.

Questo attacco presuppone che sia possibile indovinare il contenuto del file. Tieni presente che l'hardware specializzato è in grado di fare milioni di ipotesi al secondo. Tuttavia, quando i file sono ragionevolmente complessi, come con un testo in prosa contenente più di poche frasi, ciò diventa impossibile in un tempo ragionevole. Ma fai attenzione quando distribuisci file non univoci in questo modo, specialmente i file a cui un utente malintenzionato ha accesso ma che non dovresti avere. Ad esempio i file multimediali piratati.