Suppose that the data in question is a card PAN. According to PCI-DSS, you have to store it with extra security (encrypt it before storing in database and store the secret key elsewhere with more restricted access).
But what if you had to support searching based on PAN?
A. The straight forward solution would be receive a plain PAN, send it to the backend which goes through all the PANs in database, decrypts them, sees if they match the input, and then return the record with the needed data based on what is attached to that PAN (which sounds bad performance-wise).
B. Would hashing be a solution? When a new PAN is created, encrypted and stored encrypted, a hash for the PAN can also be calculated (not reversible but still hiding the real sensitive PAN). - should it have a salt? - can the salt be stored same place as the hash? or does it have to be store in a more secure place, like a secret key? - is the salt shared with the searcher? should the searcher do the hash and pass the hash around ? or should it just pass the plain PAN around and let the hashing be re-done close to where the original hashed PAN (PAN digest) is?
C. Is the entire concept of supporting search by encrypted data bad from start (and it should not even be supported because there is no good solution for it without compromising on the extra security)?
D. Is there any other secure way to do indexing of sensitive data?