Sicurezza della crittografia "interrogabile"?

Spring Security ha un metodo di utilità chiamato Encryptors.queryableText . spiegazione perché è:

The difference between a queryable TextEncryptor and a standard TextEncryptor has to do with initialization vector (iv) handling. The iv used in a queryable TextEncryptor#encrypt operation is shared, or constant, and is not randomly generated. This means the same text encrypted multiple times will always produce the same encryption result. This is less secure, but necessary for encrypted data that needs to be queried against. An example of queryable encrypted text would be an OAuth apiKey.

Guardando il sorgente, sembra che usi AES/CBC/PKCS5Padding con un IV costante tutto-zero. (Nota: in Java, PKCS5Padding significa davvero padding PKCS # 7).

Lo scopo di questo metodo sembra essere quello di utilizzare il testo cifrato come chiave (la "chiave in una mappa / indice / ecc." che significa, non il significato della "chiave di crittografia").

Le mie domande sono:

1. Che cosa è un uso pratico di tale schema? Ho provato a pensarne uno, ma sembra solo artificioso:
   1. Il sistema ha una chiave segreta (ad esempio una chiave primaria sequenziale che non vuole che un utente malintenzionato enumeri).
   2. Il sistema fornisce il testo cifrato a un utente che lo invierà in un secondo momento per richiedere informazioni ad esso correlate.
   3. Quando l'utente restituisce il testo cifrato, il sistema lo decodifica, interroga il databse e restituisce le informazioni.

Per lo scenario inventato sopra, posso pensare a molte migliori soluzioni al problema:

• Se il sistema lo decodificherà prima di eseguire una query, perché lo stesso testo cifrato per lo stesso testo in chiaro? Basta usare la crittografia corretta con IV casuale.
• Se il sistema non lo decrittografa, perché non utilizzare un ID generato a caso sufficientemente lungo e opaco?
• O meglio ancora, disponi di un controllo di accesso adeguato quando l'utente interroga le informazioni.
• Dalla precedente citazione sulla documentazione, perché un OAuth apiKey dovrebbe essere crittografato in primo luogo?

Quindi, a cosa serve esattamente questo metodo?

2. Quali sono le implicazioni di sicurezza di questa crittografia "meno sicura" (come la chiama la documentazione) se utilizzata come progettata?