Looking for suggestions on implementing a server-side lookup table, where the key is an email address.

Goal: Keep these email address private, even if data on the server is stolen.

Assumptions: The server does not need (and ideally should not know) the email address. Clients cannot directly talk to each other, but it's going to be a web/native app so they can can perform some calculations before making queries.

Is this achievable? Note: Just storing a hash of the email on the server would leave the keys vulnerable to a dictionary attack. The server also can't simply add a salt for each hash, because it would not know which salt to use when presented with a specific email address. I could encrypt the hashed emails with a global key stored separately, but I'm hoping there are better solutions than this.

2 Answers 2


There are two different cryptographic approaches to this problem, a hash function and asymmetric cryptography.

The client could hash the email address using a cryptographic hash function such as SHA-256 and send it to the server for lookup. There is still the problem of brute force. email addresses have their pros and cons. The domain name is kind of like a salt in that no two users will have the same resulting hash. The con is that its not a very strong salt, gmail is pretty popular. To make matters worse large list of email addresses would be a useful dictionary attack. The email address as a key may not be the best choice, but its not bad.

An alternate design is to use asymmetric cryptography. Generate a public private key-pair, then throw away the private key. Give the same public key to every client which is used to encrypt the email address and this cipher text is transmitted to the server as the lookup key. Note there is still the same problem as brute force, but asymmetric cryptography is a lot heavier than sha-256. If this a concern you could explore key stretching.

  • Using a public key in effect as a heavyweight hashing function is an intriguing idea. Perhaps using bcrypt with known salt/iteration counts might be a similar approach? However, for the (dictionary attack) reasons mentioned in the question and also in your note, I'd like to learn if there are additional solutions beyond this.
    – kbs
    Commented Jun 8, 2012 at 19:54

If you have no server-side secrets, the best you can do is to hash the email with a slow hash algorithm (one that is tuned to take a particular amount of time). For instance, you might iteratively hash it N times, with N chosen to ensure that hashing will take about 0.1 seconds. This is still susceptible to a dictionary attack, but it is less susceptible than using a fast hash.

If you can store a secret key on the server securely, you could encrypt the email address under the key or hash the combination of the email address and the key.

  • Thank you for the suggestions and appreciate the input. I see your point, which is that the least worst option with no server-side secrets is to use an expensive hashing function; or (as also indicated in the question) using a server-side secret key might be the pragmatic approach. I'd still like to leave the question open to see if other ideas come up.
    – kbs
    Commented Jun 8, 2012 at 20:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .