È pericoloso avere hash di parti di una stringa privata

Le informazioni aggiuntive possono solo aiutare l'aggressore; ma quell'aiuto extra potrebbe essere trascurabile.

Se modelliamo la funzione di hash come oracolo casuale , quindi mostrando h ( P + B ) per una determinata stringa non vuota B non fornisce ulteriori informazioni utili per l'attaccante (prendo "+" per indicare qui concatenazione di stringhe, non aggiunta numerica). Un "oracle casuale" è (in termini approssimativi) una funzione tale da non sapere nulla sul suo output per ogni dato input senza provarlo. Quando hai h ( x ), puoi ottenere informazioni su x solo attraverso la forza bruta, cioè provando i potenziali valori per x fino a quando non viene trovata una corrispondenza. Pertanto, h ( P + B ) non fornisce alcun potere aggiuntivo all'attaccante, rispetto a h ( P ), e indipendentemente da come è stato scelto B : l'attaccante deve ancora provare i potenziali valori P e sperare di essere fortunato. Il meglio che l'attaccante può fare per ottimizzare le cose dalla sua parte è scegliere una strategia che minimizzi il costo computazionale di ogni tentativo; poiché le comuni funzioni di hash hanno un costo proporzionale alla dimensione dell'input, l'attaccante preferirà lavorare con h ( P ) di h ( P + B ) comunque.

Il problema con il modello oracle casuale è che le solite funzioni di hash sono non oracoli casuali. Tuttavia, nel caso delle funzioni hash Merkle-Damgård (una categoria che include funzioni di hash comuni come MD5, SHA-1, SHA-256 e SHA-512), esiste una proprietà chiamata " attacco di estensione della lunghezza ": dato h ( P ), è possibile calcolare h ( P + B ) per i valori B che possono essere, in larga misura, scelti a piacimento, e puoi farlo senza conoscere P (devi sapere la lunghezza di P , ma non il suo valore effettivo). L'attacco di estensione della lunghezza è solitamente considerato come una innocua curiosità o una debolezza (nella maggior parte dei protocolli, è innocuo e può essere ignorato); ma, nel nostro caso, ha una conseguenza interessante. Vale a dire, ci permette di mostrare che rivelando h ( P + B ) non fornisce ulteriori informazioni all'attaccante, proprio perché l'attaccante ha fatto non c'è bisogno di aspettare per noi: potrebbe già calcolare h ( P + B ) per una grande classe di < em> B valori.

Sono un po 'confuso dalla costruzione della tua domanda, ma dovrei comunque essere in grado di far luce sull'argomento in ogni caso.

In primo luogo, assumerò che quando dici P+B intendi significare che P e B saranno concatenati, piuttosto che l'aggiunta in qualche forma viene preformata, e io ll ha indicato questo di seguito con la notazione || anziché con + .

In secondo luogo, l'output di una funzione hash crittograficamente protetta non rivela alcuna informazione sul suo input. Se lo facesse, cesserebbe di essere considerato una funzione sicura. Quindi, solo conoscere H(P||B) è, in effetti, l'hash di due input sconosciuti, (P e B) e H(P) è anche l'hash di uno di quegli sconosciuti che non ti dà alcuna informazione su cosa siano effettivamente gli input sconosciuti siamo.

In terzo luogo, una funzione di hash crittograficamente sicura produrrà risultati che non sono distinguibili da quelli casuali per test efficienti. Ciò significa che gli input correlati (in questo caso P è la parte relativa dell'input) non produrranno output correlati. Dato H(P||B) senza sapere che è in effetti un hash di P e B genererà un output che non è correlato all'output di H(P) . Non impari nulla su P o B da H(P) o su P da H(P||B) .

Quindi, cosa può essere attaccato? Poiché non si impara nulla sugli input dall'output di una funzione hash crittograficamente protetta, il modo in cui si attacca è testando gli input candidati e confrontandoli con l'output hash specificato per vedere se la corrispondenza, generalmente usando un dizionario o forza bruta per generare i candidati di input. Detto questo, più breve e meno casuale è l'input, meno candidati devono essere testati per trovare una corrispondenza. Pertanto, l'approccio più ovvio che un utente malintenzionato potrebbe assumere è che sa che gli hash sono il risultato di H(P||B) e H(P) e sa qual è, ma non sa che P o B sarebbero quelli di attaccare il uscita di H(P) . Poiché l'input è inferiore e i bit di entropia sono necessariamente inferiori ( B deve aggiungere almeno un bit di entropia all'input in virtù dell'esistente), un utente malintenzionato può trovare P più rapidamente di P||B e poi usalo per attaccare H(P||B) per provare a trovare B .

Tuttavia, ciò non significa che trovare P da H(P) sia necessariamente facile, o persino realisticamente possibile, comunque. È solo teoricamente più facile. È potrebbe essere possibile, e anche facile, ma dipende interamente dalle proprietà di P . Se è piccolo, e non casuale, per alcuni valori piccoli e non casuali, è completamente fattibile. Se è grande e abbastanza casuale, il numero di test richiesti potrebbe rendere impossibile calcolare il numero richiesto di valori hash per trovare l'input corretto.