Comme décrit, vous ne pouvez pas. La réponse que vous avez donnée est la manière dont vous y parviendriez si vous n'aviez pas besoin de l'optimiser.
Si vous avez besoin de l'optimiser sans complètement compromettant la valeur cryptée, et avoir profilé pour trouver la quantité de données renvoyées et traitées par votre filtre est une cause majeure de retard, vous pouvez faire ce qui suit.
Ajoutez un nouveau champ à la table qui stockera un sous-ensemble d'un hachage. En fonction du nombre d'adresses e-mail uniques, vous pouvez régler la taille de ce sous-ensemble. Remarque :plus petit est le mieux, car vous divulguez des informations sur la valeur cryptée en utilisant cette approche. Par exemple, si vous stockez un hachage de 1 octet de l'adresse e-mail, vous réduisez l'entropie du cryptage d'environ 8 bits.
Lorsque vous interrogez, créez d'abord le sous-ensemble du hachage de l'e-mail et placez un where clause pour renvoyer uniquement ces lignes.
Tout cela suppose que la fonction de hachage est moins chère que l'étape de décryptage. Cette approche vous obligerait à recalculer tous les sous-ensembles de hachage si vous vouliez augmenter sa taille, donc choisir une taille qui augmente considérablement les performances, ne compromet pas indûment le cryptage et n'aura probablement pas besoin de changer à mesure que vous grandissez est important .
Remarque :Vous ne devez pas utiliser un hachage direct comme MD5 dans cette situation. Pas à cause de sa susceptibilité aux collisions, mais parce que l'espace clé sera si petit. Si les performances sont importantes et que vous stockez de grandes quantités de données, vous vous ouvrez à des attaques DOS par lesquelles l'attaquant crée de grandes quantités d'adresses e-mail qui hachent toutes vers le même sous-ensemble. Pour lutter contre ce problème, utilisez un HMAC fonctionner avec une clé secrète.
N'oubliez pas, à moins que vous n'ayez de véritables raisons de performance pour avoir besoin d'ajouter de la complexité - ne le faites pas
