I need to save user email on a public database but I don't want to do it in plaintext, so I need to hash it. If somebody wants to verify if some email exists in the public database, he or she can calculate hash and check if the hash is there.

I don't want any other user to find out what the email is by knowing only a hash. I know that SHA256 is fast to compute so it will be easy to brute force those hashes.

The question is: is HMAC-SHA256 more secure for "hidding" email? Every email will be associated with a 256-bit random key, the verifier will know the email and it's secret so it will be feasible for him or she to calculate the hash and see if it exists on blockchain.

I believe, HMAC-SHA256 will be more secure in this case than SHA256 because the attacker who wants to brute force the email needs not only to brute force email but also the key which is a 256-bit long.

  • I know I can use scrypt or bcrypt but I am curious about the HMAC-SHA256 Commented May 28, 2020 at 7:22
  • ... or you could add a long salt to SHA256 and get the same effect.
    – schroeder
    Commented May 28, 2020 at 7:34
  • But what about length extension attack in this case? Commented May 28, 2020 at 7:41
  • I'm not sure what kind of attack you envision here. Do you expect that somebody will brute force all possible mails to check if these are in the database? Are these mails even more or less predictable so that such brute-forcing could actually be successful? How would the "valid" user know the additional random key you envision and why couldn't this just be treated as part of the mail so that brute-forcing will not work? Commented May 28, 2020 at 8:11
  • Let's say the email is [email protected]. With a SHA256 you need to iterate and "hit" [email protected] but with HMAC-SHA256 you need to "hit" [email protected] PLUS a 256-bit long random value. So with HMAC-SHA256 even if you calculate a hash for a email that exists in the public database the hash won't be equal because you still have to guess that very long 256-bit random value - which is hard to guess. This is how I understand it, but I know I may be wrong so that's it where my question came from. Commented May 28, 2020 at 9:13

1 Answer 1


Yes, using an HMAC with a sufficiently long secret key should prevent third-parties from being able to brute-force the hashed values and identify their original values. For HMAC-SHA256, a 256-bit key would be sufficient.

Note that you do not even have to associate a unique key per email. As long as you can ensure that the key never leaks, you can use a single key to HMAC all emails. An attacker that knows their email, and the HMAC of their email, should still not be able to brute-force the key. Nor should they able to derive the HMAC of related emails.


You must log in to answer this question.

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