По сути, у меня есть таблица, содержащая пользовательские данные, все из которых зашифрованы AES (в полях BLOB).
Это означает, что ни одно из этих полей не может быть проиндексировано, что замедлит любые запросы к этомуtable - тем более, что вся таблица должна быть дешифрована, прежде чем будут сделаны какие-либо совпадения ...
... WHERE AES_DECRYPT(`user`.`email`, '{$sSomeKeyHere}') = '{$sSubmittedEmail}'
Итак, мне нужно поле, которое просто содержит хеш-значение, незашифрованное, которое может быть проиндексировано дляиспользовать в качестве быстрого поиска.Наилучшим поиском, вероятно, будет некоторая производная от адреса электронной почты (строчные, перевернутые и хэшированные или какой-либо другой реплицируемый процесс), чтобы вы могли эффективно выполнять поиск по адресу электронной почты без необходимости расшифровывать адрес электронной почты ... но мне нужно сохранить этоsecure.
Итак, варианты, которые я обдумываю:
1: просто строчные буквы и SHA-256 (или 512) хешируют адрес электронной почты перед его вставкой в базу данных
2: немного более запутанный;строчная буква плюс некоторая другая реплицируемая функция скремблирования адреса электронной почты перед его хэшированием.
3: создание строки соли из user.last_login_date (которая не зашифрована) и использование ее для создания соленого хэша садрес электронной почты - и обновление поля поиска каждый раз, когда пользователь входит в систему (потому что соль будет меняться).Однако для этого требуется чуть более сложный оператор SELECT, ограниченный какими-либо функциями хеширования, встроенными в движок MySQL, поскольку для выполнения поиска мне потребуется воссоздать хэш, используя дату последнего входа в систему.
Итак, вопрос в том, можно ли просто выбрать вариант 1?
Является ли вариант 2 лучше?
Является ли вариант 3 таким же излишним, как мне кажется?
Или я пропустил что-то совершенно очевидное и, на самом деле, естьгораздо лучшее решение?