¿Seguridad del cifrado "consultable"?

Spring Security tiene un método de utilidad llamado Encryptors.queryableText . La explicación para ello es:

  

La diferencia entre un TextEncryptor consultable y un TextEncryptor estándar tiene que ver con el manejo del vector de inicialización (iv). El iv utilizado en una operación de cifrado TextEncryptor # cuestionable es compartido o constante y no se genera de forma aleatoria. Esto significa que el mismo texto cifrado varias veces siempre producirá el mismo resultado de cifrado. Esto es menos seguro, pero es necesario para los datos cifrados que deben consultarse. Un ejemplo de texto cifrado consultable sería una apiKey de OAuth.

En cuanto a la fuente, parece utilizar AES/CBC/PKCS5Padding con un IV todo-cero constante. (Nota: en Java, PKCS5Padding realmente significa PKCS # 7 padding).

El propósito de este método parece ser el uso del texto cifrado como clave (el significado de "clave en un mapa / índice / etc.", no el significado de "clave de cifrado").

Mis preguntas son:

1. ¿Qué es un uso práctico de tal esquema? Traté de pensar en uno, pero parece ideado:
   1. El sistema tiene una clave secreta (por ejemplo, una clave principal secuencial que no quiere que un atacante enumere).
   2. El sistema le da el texto cifrado a un usuario que lo enviará en un momento posterior para consultar la información relacionada con él.
   3. Cuando el usuario devuelve el texto cifrado, el sistema lo descifra, consulta la base de datos y devuelve la información.

Para el escenario artificial anterior, puedo pensar en muchas mejores soluciones al problema:

• Si el sistema lo descifra antes de consultar, ¿por qué tener el mismo texto cifrado para el mismo texto sin formato? Simplemente use el cifrado adecuado con IV aleatorio.
• Si el sistema no lo descifra, ¿por qué no usar una identificación opaca generada de forma aleatoria y suficientemente larga?
• O mejor aún, tenga un control de acceso adecuado cuando el usuario consulta la información.
• De la cita de la documentación anterior, ¿por qué se cifraría en primer lugar una apiKey de OAuth?

Entonces, ¿para qué sirve exactamente este método?

2. ¿Cuáles son las implicaciones de seguridad de este cifrado "menos seguro" (como lo llama la documentación) si se utiliza según lo diseñado?