Spring Security has a utility method called Encryptors.queryableText. The explanation for it is:

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.

Looking at the source, it seems to use AES/CBC/PKCS5Padding with a constant all-zero IV. (Note: In Java, PKCS5Padding really means PKCS#7 padding).

The purpose of this method seems to be for using the ciphertext as a key (the "key into a map/index/etc." meaning, not the "encryption key" meaning).

My questions are:

  1. What is a practical use of such scheme? I tried to think of one, but it just seems contrived:
    1. The system has a secret key (for example, a sequential primary key that it doesn't want an attacker to enumerate).
    2. The system gives the ciphertext to a user that will send it back at a later time to query information related to it.
    3. When the user sends back the ciphertext, the system will decrypt it, query the databse, and return the information.

For the above contrived scenario, I can think of many better solutions to the problem:

  • If the system will decrypt it before querying, why have the same ciphertext for the same plaintext? Just use proper encryption with random IV.
  • If the system will not decrypt it, why not use an opaque sufficiently-long randomly-generated ID?
  • Or better yet, have proper access control when the user queries the information.
  • From the documentation quote above, why would an OAuth apiKey be encrypted in the first place?

So what exactly is this method good for?

  1. What are the security implications of this "less secure" (as the documentation calls it) encryption if used as designed?
  • 1
    I have no idea what it is good for. As for security implications, as long as all the encrypted data are different and attacker can't encrypt arbitrary text, then it may be ok. If there are the same tokens, it would be visible to the attacker. If they begin with the same prefix (I believe the size of at least blocksize) this would be visible to the attacker. If the attacker can get to encrypt stuff, he could have the system emcrypt many possible prefixes to figure out the plaintext much faster, though if the encrypted data is random, this could be still slow. – Peter Harmann Apr 23 '18 at 6:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.