Essentially I've got a table holding user data, all of which is AES encrypted (in BLOB fields).

This means that none of those fields can be indexed which will slow down any queries on that table - especially since the entire table will need decrypting before any matches can be made...

... WHERE AES_DECRYPT(`user`.`email`, '{$sSomeKeyHere}') = '{$sSubmittedEmail}'

So, what I want is a field that just contains a hash value, unencrypted, that can be indexed to use as a quick lookup. The best lookup will probably be some derivative of the email address (lowercase, reversed and hashed or some other replicable process) so that you can effectively search on the email address without having to decrypt the email address... but I need to keep that secure.

So, options I'm mulling over:

1: just lower-case and SHA-256 (or 512) hash the email address before inserting it into the database

2: slightly more convoluted; lower-case plus some other replicable function of scrambling the email address before hashing it.

3: creating a salt string from user.last_login_date (which isn't encrypted) and using that to create a salted hash with the email address - and updating the lookup field every time the user logs in (because the salt will have changed). However this requires a slightly more convoluted SELECT statement, limited to whatever hashing functions are built into the MySQL engine, as I'll need to recreate the hash using the last login date to perform the search.

So the question is, is it OK to just take option 1?

Is option 2 better?

Is option 3 as totally overkill as I think it is?

Or have I missed something totally obvious and there is, in fact, a much better solution?

解决方案

Option 1.

Your data can be indexed for searching and comparison, but only against encrypted search terms.