Autosuggestion on encrypted Data(AES-256 GCM Mode) - aes-gcm

Question

For PII purposes, we are encrypting the database fields like email etc.
Now for exact match queries we are also keeping a hashed form(HMAC) for the fields.
But how to run the autosuggestion from Solr / like queries from MySQL.
My encryption code is
public String encrypt(byte[] plaintext, byte[] dataKey, String version) throws Exception {
long startTime = System.currentTimeMillis();
// Generate Initialization Vector
byte[] IV = generateIV();
// Get Cipher Instance
Cipher cipher = getCipher();
// Store Version
byte[] versionArr = new byte[3];
versionArr = version.getBytes();
// Generate Key
SecretKeySpec keySpec = new SecretKeySpec(dataKey, "AES");
// Create GCMParameterSpec
GCMParameterSpec gcmParameterSpec = new GCMParameterSpec(GCM_TAG_SIZE_BYTES * 8, IV);
// Initialize Cipher for ENCRYPT_MODE
cipher.init(Cipher.ENCRYPT_MODE, keySpec, gcmParameterSpec);
// Perform Encryption
byte[] cipherText = cipher.doFinal(plaintext);
int capacity = 3 + GCM_IV_SIZE_BYTES + plaintext.length + GCM_TAG_SIZE_BYTES;
// Create ByteBuffer & add IV & CipherText
ByteBuffer buffer = ByteBuffer.allocate(capacity);
buffer.put(versionArr);
buffer.put(IV);
buffer.put(cipherText);
long endTime = System.currentTimeMillis();
// return the final encrypted cipher txt
return Base64.getEncoder().encodeToString(buffer.array());
}
private static byte[] generateIV() {
final Random r = new SecureRandom();
byte[] IV = new byte[GCM_IV_SIZE_BYTES];
r.nextBytes(IV);
return IV;
}
private static Cipher getCipher() {
try {
return Cipher.getInstance("AES/GCM/NoPadding");
} catch (NoSuchAlgorithmException | NoSuchPaddingException e) {
e.printStackTrace();
}
return null;
}

Answer 1

Short answer, it’s possible, but quite difficult.
Long answer:
One of the basics of hashes is that the hash changes a lot, by changing the input only a little, so there is no way to know if a hash is close to matching the input value.
Now you might think inputting the hash into the search engine might work and with some customization to the tokenizer (the thing that takes the search input and splits it into small parts for the engine to match), this would actually work. However, you did just make it possible to reverse the hash, let me explain:
For autocomplete of a single field, the tokenizer would use an edge n-gram. What this does is splitting a single string into multiple tokens that can be exactly matched, for example john#gmail.com would be split into:
j, jo, joh, john, john#, …, john#gmail.c, john#gmail.co, john#gmail.com
Now the search engine can search for exact matches on all the tokens and recommend the closest matches as possible values.
If you would customize the tokenizer, to hash everything before it is stored, and then hased the input upon search, this would absolutely work, but now lets look at what happens when an attacker gets the hashed tokenized data.
As in the example with john#gmail.com the first stored value would be the hash of j, which by brute force would take a fraction of a second to reverse. Since you now know the first letter, the second letter would go just as fast and so on. Rendering the whole point of using the hash in the first case obsolete.
ps. A secure hashing algorithm with a salt might work, but the tokenization is almost always done by the search engine, so the compute part of the search engine has to be "secure"
Sources:
https://en.wikipedia.org/wiki/N-gram