Archivia un hash crittografico con funzionalità di ricerca

Se hai bisogno di un sistema veramente sicuro con salatura e stiramento delle chiavi, allora non c'è modo di rendere ricercabili gli hash. È lo stesso problema con la memorizzazione delle password:

• Con la salatura previeni gli attacchi alle tabelle arcobaleno, ma prima devi verificare il sale prima di poter verificare l'hash dei dati.
• Con lo stiramento delle chiavi (rendendo l'hash lento) puoi contrastare gli attacchi a forza bruta, ma non è possibile verificare rapidamente molti / tutti gli hash dei dati.

Questo rende l'utilizzo di hash e ricerche sicure che si escludono a vicenda. Dipende dal livello di sicurezza richiesto, se puoi andare senza sale o se puoi passare a una crittografia meno sicura.

Un modo per uscire da questo problema potrebbe essere, per crittografare i dati, senza memorizzare la chiave. Ciò richiede che l'utente inserisca una password ogni volta che usa il servizio. Da questa password utente si genera quindi una chiave con una funzione di derivazione chiave e si mantiene la chiave in memoria per tutto il tempo necessario.

Potresti prendere in considerazione l'utilizzo di una firma separata piuttosto che un semplice valore hash, se la tua applicazione non è vulnerabile alla "scopri l'attacco di informazioni rimanenti" .

Ad esempio: Alice ha un database di documenti sensibili su un computer protetto che normalmente è spento. Prima che il computer sia spento, Alice usa quel computer con la chiave privata di quel computer per firmare crittograficamente ciascun documento, generando una diversa firma separata per ciascun documento. (L'algoritmo di firma crittografica utilizza internamente un algoritmo di hash crittograficamente sicuro per generare un valore hash a larghezza intera). Quindi Alice copia le firme distaccate su una chiavetta USB e quindi inserisce la chiavetta USB in un server separato che Alice mantiene acceso e consente al pubblico di accedere.

Successivamente, Bob ha in mano alcuni documenti presumibilmente sensibili e si chiede se sia lo stesso di uno di quei documenti precedenti. Quindi Bob mette il documento in mano usando lo stesso algoritmo di hash e usa l'algoritmo di verifica standard per verificare se si verifica contro una delle firme distaccate. (C'è un valore di hash troncato a 16 bit memorizzato in ogni firma distaccata PGP standard, quindi è possibile scrivere software per utilizzare una ricerca binaria per trovare rapidamente qualsiasi firma che potrebbe corrispondere, quindi se ci sono qualsiasi corrispondenza, utilizzare l'algoritmo a chiave pubblica lenta per verificare). Il risultato sarà sempre uno dei seguenti:

• Nessuna corrispondenza: no, quel documento non si trova sicuramente sul computer protetto.
• Corrispondenza: sì, quel documento era sicuramente sul computer protetto.

(È considerato praticamente impossibile avere falsi positivi o falsi negativi).

dettagli:

• "In che modo una chiave pubblica verifica una firma?"
• "Come sono le firme separate utilizzato per verificare l'integrità e l'autenticità di un file? "
• "Cosa succede quando si verifica una firma separata?"
• "Creazione e verifica delle firme"

Se hai relativamente pochi pezzi di testo (ad esempio, intorno a N = 1000 pezzi di testo), e va bene che il tuo sistema occasionalmente dia un "falso positivo", potresti prendere in considerazione l'utilizzo di un hash troncato.

Ad esempio: Alice ha un database di circa N = 1000 documenti sensibili su un computer protetto che normalmente è spento. Alice è disposta ad avere un tasso di errore falso positivo di e = 1/100. Prima che il computer sia spento, Alice usa quel computer con qualsiasi funzione di hash crittograficamente protetta (SHA-3, BLAKE, Argon2, ecc.) per cancellare ogni documento (magari usando lo stesso valore di sale pubblicato pubblicamente per tutti i 1000), quindi troncare l'hash a log2 (N / e) = log2 (1000 * 100) = circa 17 bit, quindi copia gli hash troncati a 17 bit su una chiavetta USB, quindi posiziona la chiavetta USB in un server separato che Alice mantiene acceso e consente al pubblico di accedere.

Successivamente, Bob ha in mano alcuni documenti presumibilmente sensibili e si chiede se sia lo stesso di uno di quei documenti precedenti. Quindi Bob mette il documento in mano e confronta il suo hash troncato a 17 bit con ciascuno dei circa 1000 valori hash sul server (probabilmente usando una ricerca binaria relativamente veloce). Il risultato sarà sempre uno dei seguenti:

• Nessuna corrispondenza: no, quel documento non è sicuramente sul computer protetto
• Corrispondenza: il documento potrebbe trovarsi sul computer protetto.

Questo algoritmo è abbastanza resistente al "imparare l'attacco di informazioni rimanenti", perché ci sono così tanti falsi positivi è difficile per un utente malintenzionato capire qual è l'effettiva informazione rimanente.

Se qualcuno genera casualmente un mucchio di documenti (nessuno dei quali corrisponde esattamente a nessuno dei documenti sensibili), mi aspetto che circa l'1% di quei documenti abbia un valore hash coincidente, dando il "falso positivo" di "Quello il documento potrebbe essere sul computer protetto ". Il restante 99% di questi documenti indica "No, quel documento non è sicuramente sul computer protetto".