Entonces la primera advertencia primero:
Si los datos son seguros, no se pueden buscar, solo se pueden verificar
en contra.
Ahora con respecto a la búsqueda: No hay una buena manera de buscar campos cifrados o con hash, SIEMPRE consumirá CPU . Hay una razón para esto: sus datos están en una calle de sentido único. Se recupera en la memoria, se revisa, se destruye la versión en memoria y se envía la entrada menos los datos que no puede enviar. Esto es para fines de seguridad, así como para pruebas de ataque. Entonces, se plantea la pregunta "¿Cómo puedo buscar en contra de ella?" Literalmente, una entrada a la vez. Porque cada hash o cifrado debe ser único y nunca repetible a menos que se compare. con el valor inicial, tiene que recuperar todos los objetos cifrados, revisarlos hasta obtener una coincidencia y luego devolver el ID o la clave de esa entrada. ¿Es esto largo, prolongado, molesto y seguro? Sí. ¿Se puede hacer esto más rápido o mejor? En realidad no.
Más advertencias:
¡NUNCA GUARDE UNA MESA DE ARCO IRIS! Esas son vulnerabilidades fácilmente resquebrajadas ( ¿No me crees? )
¡NUNCA GUARDE SALES EN LA BASE DE DATOS! Si los datos en su totalidad son robados, este cifrado ahora es worthless
Si los datos necesitan ser * verdaderamente seguros **, cópielos a través de un algoritmo de hash de una manera (como bcrypt)
SI DEBE buscar contra datos encriptados, use un programa de descifrado separado para descifrar los datos, realice la búsqueda y envíelos nuevamente en una aplicación binaria compilada e independiente. De esta manera, si el servidor público tiene un visitante no deseado, no pueden obtener esa información, la clave sigue siendo segura y sus datos están seguros.