Zoals beschreven, kan dat niet. Het antwoord dat u hebt gegeven, is de manier waarop u het zou bereiken als u het niet hoeft te optimaliseren.
Als u het moet optimaliseren zonder volledig het compromitteren van de versleutelde waarde en hebben geprofileerd om te zien dat de hoeveelheid gegevens die wordt geretourneerd en verwerkt door uw filter een belangrijke oorzaak van vertraging is, kunt u het volgende doen.
Voeg een nieuw veld toe aan de tabel waarin een subset van een hash wordt opgeslagen. Afhankelijk van het aantal unieke e-mailadressen, kunt u afstemmen hoe groot deze subset is. Opmerking:hoe kleiner hoe beter, omdat u met deze benadering informatie over de versleutelde waarde lekt. Als u bijvoorbeeld een hash van 1 byte van het e-mailadres opslaat, vermindert u de entropie van de codering met ~8 bits.
Wanneer u een query uitvoert, maakt u eerst de subset van de e-mailhash en plaatst u een where clausule om alleen die rijen te retourneren.
Dit alles veronderstelt dat de hash-functie goedkoper is dan de decrypt-stap. Deze aanpak vereist dat je alle hash-subsets opnieuw berekent als je de grootte ervan wilt vergroten, dus het is belangrijk om een grootte te kiezen die de prestaties aanzienlijk verhoogt, de codering niet onnodig in gevaar brengt en hoogstwaarschijnlijk niet hoeft te veranderen als je groeit. .
Opmerking:in deze situatie moet je geen straight hash zoals MD5 gebruiken. Niet vanwege de gevoeligheid voor botsingen, maar omdat de sleutelruimte zo klein zal zijn. Als performance belangrijk is en je slaat grote hoeveelheden data op, dan open je zelf DOS-aanvallen waarbij de aanvaller grote hoeveelheden e-mailadressen creëert die allemaal naar dezelfde subset worden gehasht. Gebruik een HMAC om dit probleem aan te pakken. functie met een geheime sleutel.
Onthoud, tenzij je echte prestatieredenen hebt om complexiteit toe te voegen - niet doen