Cifrar campos de base de datos conservando la funcionalidad de búsqueda

No puede usar el modo AES CBC porque requeriría que use el mismo IV para cada ID de usuario, o cifrar el ID varias veces con cada IV único en la base de datos y hacer una comparación. El primero anularía el propósito del modo CBC, y el segundo sería extremadamente lento.

Si realmente no tiene otra opción, use el modo AES-ECB, que siempre cifra el mismo texto sin formato con el mismo texto cifrado, dada la misma clave. Normalmente no se recomienda porque conserva patrones en sus datos, como se ve en esta respuesta . Si sus datos se ajustan a un tamaño de bloque único de 128 bits, esto no es una gran preocupación. Si la ID es simplemente un número entero, es casi seguro que se ajusta a un solo bloque. Si la ID es una cadena, puede caer en 2 o más bloques dependiendo de la longitud y la codificación (Unicode, por ejemplo). Más bloques conducirían a la posibilidad de un mayor análisis de lo que está dentro de los bloques en función de los patrones dentro de los datos (como la analogía de la imagen en el enlace). No estoy lo suficientemente calificado en criptografía para decirle los riesgos de esto.

Recomiendo encarecidamente que no se almacene el hash del texto sin formato de la ID en cualquier lugar, al menos si desea mantener esta ID segura. Una identificación que usted describe tiene una cantidad muy baja de entropía. Sería trivial hacer hash de miles de millones de ID hasta que coincidan con el hash, anulando por completo el propósito del cifrado.

Su escenario probablemente esté bien, si el modelo de amenaza solo protege de los DBA deshonestos. Simplemente recuerde que la aplicación DEBE obtener acceso a la clave de cifrado. Si la aplicación se ejecuta en la computadora del cliente, es probable que cualquier atacante cualificado pueda obtener acceso a ella.

No recomendaría en realidad cifrar algo como un usuario id . Prácticamente no debería haber riesgo de que alguien lo vea, y realmente está haciendo mucho más trabajo de lo necesario. Un id de identificación de un usuario no es lo que imagino que mucha gente va a llamar "información confidencial".

En realidad, me cuesta mucho pensar en un caso de información confidencial en el que le gustaría usar una cláusula WHERE en SELECT . No me gustaría nunca buscar contra SSNs , por ejemplo.

Si desea comparar la entrada del usuario con algo como SSN , generalmente hay otra información como name y DOB que se ingresó junto con SSN . Extraería todos los registros en una matriz que coincida con esa información ( name , dob ) y luego verificaría cualquier entrada resultante con el SSN provisto y el SSN de la entrada, descifrado.