Modificato : guarda la nota importante alla fine, che è stata aggiunta dopo che ho postato in origine e poi rileggere la domanda.
L'unica cosa che posso pensare è creare una tabella indicizzata usando gli hash. Ma questo indebolirà sicuramente la tua sicurezza dal momento che stiamo scambiando la crittografia completa che (si spera) non perde alcuna informazione sui contenuti per le tabelle di hash, che perdono informazioni sui contenuti dei dati di un utente (conoscendo il numero di termini indicizzati per un dato account dà un attacco a un punto di appoggio per l'analisi della frequenza tra le altre cose.
Nota: sto facendo la seguente ipotesi: hai un iv diverso per ogni utente.
Prima di crittografare una riga del database, è possibile leggere le righe e assegnarle token a una tabella che indicizzerà tali elementi. Dovresti quindi hash i token con un sale generato dal iv. Quindi, ora, per un determinato utente, "secretfoo" viene salvato nell'indice come c9a60f248c3a99e2b7004061d5c74e5f2240426f1f0f95eaf5843aa875e68542 .
Quando esegui una ricerca, dovrai scorrere tutti gli ivs per generare tutti i sali, quindi eseguire una ricerca per il token c9a60f248c3a99e2b7004061d5c74e5f2240426f1f0f95eaf5843aa875e68542 per trovare il record che contiene "secretfoo".
Questa sarebbe una ricerca più veloce, ma qui c'è uno scambio di velocità per la sicurezza. Dato che in pratica si è salvato un dizionario di hash per una determinata parola, se il database dovesse essere sottratto, è possibile (ma improbabile) che le informazioni indicizzate possano essere utilizzate per assemblare i dati originali. Per lo meno, può essere usato per assemblare i metadati relativi ai dati. Detto questo, sarebbe computazionalmente difficile.
Supponiamo che tu abbia 100.000 utenti con circa 100 righe per utente per una dimensione totale della tabella di 100.000.000 di righe di dati.
Decifrare tutti i 100.000.000 di milioni per eseguire una ricerca non indicizzata richiederà montagne di tempo.
Sotto il paradigma di cui sopra, devi solo generare 100.000 hash e cercare ognuno di quei una volta nell'indice per trovare i record che vuoi.Inoltre, possiamo abbinare intere stringhe (l'hash) e non è necessario eseguire ricerche di sottostringa.
Questo ha il vantaggio di calcolare 100.000 hash e di eseguire 100.000 ricerche su una tabella indicizzata BTREE che ci dà buoni risultati.
Come ha sottolineato Mike Ounsworth, devi ancora decidere cosa è sensibile e quali non sono i dati sensoriali per fare una ricerca; tuttavia, avere tutti i token SHA256 con hash è ordini di grandezza migliori del testo normale.
A CURA :
Dopo aver effettuato il mio post, ho riletto la tua domanda e mi sono reso conto che hai salvato l'iv nel database, il che renderebbe l'indice vulnerabile all'esfiltrazione.
L'unico modo per risolverlo è quello di archiviare l'iv in un database separato che non è esposto al web e che è accessibile solo tramite un'API. Questa è una configurazione comune nelle applicazioni conformi PCI.
Quando si effettua una query, l'applicazione Web deve chiedere al server sicuro la iv da cui genera l'hash ed eseguire la ricerca.
Questa è un'implementazione più complicata, ma se l'iv è nel database che è rivolto verso il Web, ed è exfiltrato, tutto ciò che devono fare è scorrere i ivs per decrittografare l'intero indice.