Cifra i campi DB preservando la funzionalità di ricerca

Non è possibile utilizzare la modalità CBC AES perché richiederebbe l'utilizzo della stessa soluzione per ciascun ID utente o criptare l'ID più volte con ogni IV univoco nel DB e fare un confronto. Il primo annullerebbe lo scopo della modalità CBC e il secondo sarebbe estremamente lento.

Se davvero non hai altra scelta, usa la modalità AES-ECB, che cripta sempre lo stesso testo in chiaro con lo stesso testo cifrato, data la stessa chiave. Normalmente non è raccomandato perché conserva i pattern nei tuoi dati, come mostrato in questa risposta . Se i tuoi dati si adattano a una singola dimensione di blocco di 128 bit, questa non è una grande preoccupazione. Se l'ID è semplicemente un numero intero, quasi certamente si adatta a un singolo blocco. Se l'ID è una stringa, potrebbe cadere in 2 o più blocchi a seconda della lunghezza e della codifica (unicode per esempio). Più blocchi porterebbero al potenziale di ulteriori analisi di ciò che è all'interno dei blocchi in base ai modelli all'interno dei dati (come l'analogia dell'immagine nel collegamento). Non sono abbastanza qualificato in cripto per dirti i rischi di questo.

Raccomanderei strongmente di non archiviare l'hash del testo in chiaro ID ovunque, almeno se si desidera mantenere questo ID sicuro. Un ID che descrivi ha una quantità molto bassa di entropia. Sarebbe banale imbustare un ID di miliardi finché non corrisponde all'hash, annullando completamente lo scopo della crittografia.

Il tuo scenario è probabilmente OK, se il modello di minaccia sta solo proteggendo da DBA canaglia. Basta ricordare che l'applicazione DEVE in qualche modo ottenere l'accesso alla chiave di crittografia. Se l'applicazione viene eseguita sul computer client, è probabile che qualsiasi utente malintenzionato esperto possa accedervi.

In realtà non consiglierei di crittografare qualcosa come un utente id . Non dovrebbe esserci praticamente alcun rischio per chiunque lo veda e stai davvero facendo molto più lavoro per te del necessario. Un id di identificazione di un utente non è ciò che immagino che molte persone chiameranno "informazioni sensibili".

In realtà sto vivendo un momento difficile cercando di pensare a un caso di informazioni sensibili che ti piacerebbe utilizzare una clausola WHERE su in SELECT . Ad esempio, non vorrei mai effettuare una ricerca con SSNs .

Se desideri confrontare l'input dell'utente con qualcosa di simile a SSN , generalmente ci sono altre informazioni come name e DOB che vengono immesse insieme a SSN . Vorrei estrarre tutti i record in un array con quella corrispondenza che informazioni ( name , dob ) e quindi controllare le voci risultanti con SSN fornito e SSN dalla voce, decifrato.