2

Sorry for my dumb question, but it's better to ask dumb question than to do dumb things silently.

I want to encrypt user email in my DB so that if someone stole the DB (and not the key) - he won't be able to restore the email adresses. But I need to be able to find user by email in my DB. And I can't iterate over all the emails in the DB, decrypt each and compare - this is too slow (minutes, hours).

If I encrypt emails with AES with random IV - then each time I encrypt the same email - the encrypted value is different. This is great for security but this way I can't just encrypt the given email and search for a value. If the IV is the same each time - then as far as I understand if attacker have enough encrypted values - he can easily find the key, right?

I was thinking about storing original email hash alongside the encrypted value, but this way attacker will be able to recover original email values by encrypting emails from some dictionary with the same hash algorithm and comparing hash values with values in the DB.

I thought about storing hash of original email+some_fixed_secret. Is this secure? If not - is there a secure solution to my problem?

Mikhail
  • 41
  • 4
  • While you say "find user by email", it seems like you're describing finding emails by username. $\hspace{.12 in}$ –  May 28 '13 at 17:39
  • 1
    Why not just eschew the IV altogether and use a deterministic scheme? There are lots of recent results showing good provable security for deterministic schemes. Look at Boldyreva's CV for a couple of them. – pg1989 May 28 '13 at 17:40
  • Ricky Demer, email is used not only as a login, e.g. for finding user friends already registered in the system (given the exported list of his contacts from other system), for ensuring email uniqueness etc. – Mikhail May 28 '13 at 17:50
  • pg1989, thanks! Using your advice I found some links at http://en.wikipedia.org/wiki/Deterministic_encryption including Boldyreva's work. Need to study them. – Mikhail May 28 '13 at 17:57
  • A fixed IV doesn't allow to find the key, but might allow decrypting other ciphertexts, depending on the encryption scheme. But you actually only need a one-way function. – Paŭlo Ebermann May 28 '13 at 17:58
  • Paŭlo Ebermann, why one-way? I send messages to the users, so I need to be able to encrypt/decrypt emails. But if there is a secure deterministic one-way function, then I can use AES for encryption/decryption and this one-way function for index-based search. Can you please suggest such a one-way function? Also what do you mean "depending on the encryption scheme"? What encryption scheme can I use with fixed IV? – Mikhail May 28 '13 at 18:37
  • hash of original email+some_fixed_secret is not a secure one-way function, is it? – Mikhail May 28 '13 at 18:44
  • Found out the scheme called Synthetic Initialization Vector (SIV) and related question on stackoverflow: http://stackoverflow.com/questions/10734782/aes-rijndael-search-on-encrypted-data-static-salt-and-iv and also related video 8 - 3 - Deterministic Encryption SIV and wide PRP (21 min) on coursera crypto class – Mikhail May 28 '13 at 20:26
  • OK, I see such possibilities: (1) Use first 16 bytes of SHA256(email+key) as IV in AES in CBC mode. (2) Use random IV in AES in CBC mode for encryption, use separate db field with SHA256(email+key) as a search-able field. (3) Implement SIV AES RFC 5297 on my own and use it as deterministic encryption. Going to use (1) because it requires less storage in DB than (2) and because I can use already available and trusted implementations of AES and SHA256 and I can't tell why it's bad. Please tell me if this is bad decision and why. – Mikhail May 29 '13 at 14:48
  • No, better will go with (2) for now, this way encryption and hashing is completely separate. – Mikhail May 29 '13 at 19:44
  • and also use HMAC instead of SHA256(email+key) – Mikhail May 30 '13 at 05:56

1 Answers1

2

I ended up with the following solution:
For each email store two values: encrypted email and signature for the email.
For encryption I used AES in CBC mode with random IV.
For signing I used HMAC SHA256.
The keys used for encryption and for signing are different.

Later on I found the following link: docs.oracle.com. So looks like this is pretty standard approach.

Mikhail
  • 41
  • 4