Come descritto, non puoi. La risposta che hai dato è il modo in cui lo raggiungeresti se non avessi bisogno di ottimizzarlo.
Se è necessario ottimizzarlo senza completamente compromettere il valore crittografato e avere profilato per trovare la quantità di dati restituiti ed elaborati dal tuo filtro è una delle principali cause di ritardo, puoi procedere come segue.
Aggiungi un nuovo campo alla tabella che memorizzerà un sottoinsieme di un hash. A seconda del numero di indirizzi e-mail univoci, puoi regolare le dimensioni di questo sottoinsieme. Nota:più piccolo è, meglio è, poiché stai perdendo alcune informazioni sul valore crittografato utilizzando questo approccio. Ad esempio, se memorizzi un hash di 1 byte dell'indirizzo email, riduci l'entropia della crittografia di circa 8 bit.
Quando esegui una query, crea prima il sottoinsieme dell'hash dell'e-mail e inserisci un where clausola per restituire solo quelle righe.
Tutto ciò presuppone che la funzione hash sia più economica del passaggio di decrittazione. Questo approccio richiederebbe di ricalcolare tutti i sottoinsiemi di hash se si desidera aumentarne le dimensioni, quindi scegliere una dimensione che aumenti significativamente le prestazioni, non comprometta indebitamente la crittografia e molto probabilmente non sarà necessario modificarla man mano che cresci è importante .
Nota:in questa situazione non dovresti usare un hash semplice come MD5. Non per la sua suscettibilità alle collisioni, ma perché lo spazio chiave sarà così piccolo. Se le prestazioni sono importanti e si archiviano grandi quantità di dati, si aprono attacchi DOS in base ai quali l'attaccante crea grandi quantità di indirizzi e-mail che eseguono tutti l'hashing sullo stesso sottoinsieme. Per approfondire questo problema, utilizza un HMAC funzione con una chiave segreta.
Ricorda, a meno che tu non abbia vere ragioni di prestazioni per la necessità di aggiungere complessità, non farlo
