Secure hashing when the input comes from a small space

Question

I have a problem that I'll simplify here. Let's say I want to store a table of {person, fav color}. Only, I don't want anyone to ever be able to look up a person't favorite color; the only thing someone should be able to do is group people if their favorite color is exactly the same (not just merely similar). The obvious solution would be to not store the favorite color, but {person, hash(fav color)} using a good crypto hash(). Only, turns out that there is a very small list of color names, and anyone can easily enumerate all the colors, and compute the hash thereby reversing the hash and extracting the fav color for a person. I can stretch, but that makes computing hash() slow -- it needs to be a fast operation.

Basically, I have input x chosen from a small, easily enumerated space. I want a fast-to-compute function H that will guarantee x==y <=> H(x)==H(y) (with high probability). But knowing H(x) does not allow one to easily compute x.

I'm creating a secret key, and using H(x) as Hmac-Sha256(x, key).

Does this work? Is there a better, more accepted way of doing this?

Answer 1

What you want is that the below query is possible but the database is secure against Frequency/Inference attacks.

Select * FROM users WHERE 'fav_color' = RED

What we have: small values space for the color names as people's favorite colors. We can consider this as an example of the small message space like gender, age, weight, scale, the illnesses they have, etc. The more the information is leaked, the easier to identify a target.

1. Case: Cryptographic Hash: Hash functions are considered a candidate for a one-way function. This means that they are hard to invert. In hash terms, they need to have pre-image resistance. Keep in mind that they are deterministic in the sense that one gets the same hash value whenever the same input is hashed again.

   Select * FROM users WHERE 'fav_color' = Hash(RED)
   

   • Pre-image resistant: for essentially all pre-specified outputs, it is computationally infeasible to find any input which hashes to that output, i.e., to find any preimage $x'$ such that $h(x') = y$ when given any $y$ for which a corresponding input is not known.

   In a normal pre-image attack, the success of the attack requires around $\mathcal{O}(2^n)$ search to be successful. This can be executed random $2^n$ input search for the hash value. Since the input space is small, once the attacker accesses the database they can infer the input values very easily. If one assumes that they have all the knowledge of the system, they can prepare a hash table beforehand.

   Using slow and memory hard hashing like Scrypt/Argon2id will not much against this attack. It will only make the attack time slower and very small input spaces like color will be still an easy target.

   Using salt can kill the hash table / rainbow tables, however, one cannot execute the query anymore since the same color name will have different values.

2. Case: Cryptographic Keyed Hash: Keyed hash function like HMAC and KMAC requires a key to operate and the security also relies on the key. They are also deterministic.

   Select * FROM users WHERE 'fav_color' = HMAC-SHA256(RED)
   

   In this case, the attacker has no chance of executing a search as in unkeyed hash function since the key prevents it. This is not preventing them to infer data from the tables. The frequency attack is possible as in the case of the CryptDB.

3. Case Encryption: We can remove the case of stream cipher since the no padding option will leak information about the data as $\color{Blue}{\textbf{Blue}}$ will be longer than $\color{Red}{\textbf{Red}}$. We may assume that with proper padding all the colors have the same plaintext size that result in the same block size.

   Select * FROM users WHERE 'fav_color' = ENC(RED)
   

   One can use ECB mode that enables equal queries like in CryptDB since it is not Ind-CPA secure. In this case, the attack same as in the HMAC case, look for the frequency.

   Using Ind-CPA secure ciphers modes like CBC and CTR will hide the frequencies, however, that will remove the equality query.

4. Other options These are slow, however, can hide the frequency on the data at rest since these are using randomized encryptions.

   • Once can use PIR (private information retrieval) schemes to access the data with the required fav_color. This may need a special design to access all.
   • FHE (fully homomorphic encryption) base database; we will see.