0

I have a senario like " I want to save a email (like [email protected]) encrypted in Database (For example as 'asdjasjdna') after that I want to check when User enter this email and compare in database.

Till now findings :

  1. I can't lookup in database using that email directly
  2. I can't convert incoming email to existing encryption as it changes every time depending upon timestamp.

So am I going right ? Is there anyway or workaround ? kindly guide any suggestion would be highly appreciated

TNN
  • 101
  • Welcome to Cryptography. The current style of the question is a programming mistake (first part) is off-topic here. This question tons of time asked and answered in [so]. This one might help you from [security.se]. Note that what you use is not clear, too!. – kelalaka Oct 18 '20 at 20:28
  • What do you want to do with the email? Just to for user login? A hash of the email (optionally with a pepper) might then solve your needs. – Ángel Oct 18 '20 at 20:31
  • @Ángel I think using hash I can't get my email in real form ? like hash is one way – TNN Oct 18 '20 at 20:33
  • @FawadRana as I said, it depends what you want to do with the email. If you only need it on login or password reset, it would be provided by the user. If you want to use the encrypted emails for a mailing, it obviously wouldn't work. – Ángel Oct 18 '20 at 20:41

1 Answers1

1

It looks like it is asked for deterministic symmetric encryption (and authenticated, because we can and should) in a decisively applied context. There are options for this, including some that can be built easily on top of primitives available now in most cryptographic libraries.

One would be: after normalizing the email (which is a difficult task of its own), build an IV from it using some MAC (HMAC-SHA-512 truncated to 128-bit will do¹), then AES-CBC² encrypt the email using that IV. In theory you need separate keys for the MAC and encryption, but with the stated algorithms disaster won't strike if you don't. Store the concatenation of IV and ciphertext with Base64 encoding in the database.

Decryption is just as normal for AES-CBC, and after decryption you can check the MAC.

Since the encryption is deterministic, you can search by encrypting again and searching the ciphertext (case sensitive).

That solves the problems of search, and protects in case of database leak only slightly³ poorly than normal encryption. But is does not solve two wider IT security issue:

  • securely storing the key(s)
  • preventing their abuse

Note: I have asked here if AES-GCM-SIV with fixed public IV would do.

¹ Using HMAC-SHA-256 could be less than academically correct for more than 128-bit key, but would most likely be OK in practice.

² With some standard padding like PKCS#7. AES-OFB would simplify padding, but is uncommon. AES-CTR would simplify padding too, and is common, but it's uncommon that a 128-bit IV can be used and that would be a problem here.

³ In the context, the loss of security due to use of deterministic encryption is that it allows comparison of emails in database dump(s), including between different users in the database, and between revisions including if a user changed email then went back to the original.

Community
  • 1
fgrieu
  • 140,762
  • 12
  • 307
  • 587