Есть данные. Есть ключи шифрования этих данных. Ключи только у клиента. Вычленить фрагмент текста из зашифрованного блока невозможно по определению.
Вам нужно, чтобы пользователь мог с использованием индекса найти ссылку на нужное место в выбранной структуре хранения.
Так как индекс должен быть зашифрован, то доступ к нему может быть только у клиента. Т.е. задача обновления индекса падает на пользовательскую часть софта.
Ну вот Вам и ответ — индекс является отдельным зашифрованным документом пользователя. Каждый раз, как он вносит новые данные или меняет существующие он должен внести изменения в индекс.
Плюс — модуль для полного сканирования имеющихся документов для первого раза или для восстановления поврежденного индекса. Опять-же — работает только и исключительно на стороне клиента, ибо ключи только у него.
Если сервер вообще не участвует в шифровании, то как вы собираетесь вообще искать там, не очень понятно… Теоретически можно создавать индексы для открытого текста, а сам текст хранить зашифрованным. Но вроде как пользы от этого мало в плане секюрности, да и передавать надо открыто на сервер.
AES стоек к криптоатакам такого типа. Без смены алгоритма шифрования никак.
Ну или шифровать либо не все, либо частями. Но тогда политика конфиденциальности…
Пробовал решить схожую задачу:
— данные хранятся на сервере, шифруются на клиенте, сервер даже об алгоритме шифрования не знает, хотя вообще алгоритм симметричный, ключ один и закрытый как следствие
— необходимо было реализовать автодополнение на AJAX (строки относительно короткие, ФИО в общем)
Выкрутился пока так:
— при сохранении поля клиент шифрует данные и помешает в основную таблицу
— дополнительно для каждой подстроки (первая буква, две первых буквы, три первых буквы, ..., всё ФИО) формируется хэш (с солью) и помещается в другую таблицу, связанную с основной (много хэшей для каждой записи в основной)
— при вводе новой записи пользователем клиент отправляет хэш введенных букв на сервер, тот выдаёт зашифрованные записи для которых этот хэш есть (например, все записи, которые начинаются с 'А')
— клиент расшифровывает записи, уникализирует (дубли есть даже на относительно небольшой базе, в теории полных тёзок очень много) и показывает пользователю часть из них (на начальных буквах все показать если и реально, но смысла нет)
Глобальный недостататок:
— большая нагрузка на клиента, когда надо расшифровывать порядка пары сотен записей (при базе в 3000 человек) после ввода первой буквы — на JavaScript это, мягко говоря, не быстро, генерация порядка 20-40 хэшей при сохранении на этом фоне мелочь, как и несколько лишних килобайт на запись в хэше. Что будет когда возвращаться будут тысячи записей для расшифровки — страшно подумать, надо думать над тем, как ограничивать и уникализировать записи на сервере и как из JS браузера вызывать нативные библиотеки шифрования типа mhash и mcrypt
Ну пусть клиент вместе с шифрованными данными сам создает и передает незашифрованный массив из слов для построения индекса для этого документа. Все конфиденциальные данные отбрасываются (ну номера, пароли, легко регэкспом), остаются только обессмысленный набор простых слов, отсортированных по алфавиту.
Хэшировать каждое слово бессмысленно, ибо это не повышает безопасность: легко взять хэши у большого произвольного набора слов и сравнить с записями в существующем индексе.
My<cod/>.net
