Есть система, в которую поступают текстовые сообщения. На клиенте с помощью публичных/приватных ключей они шифруются и отправляются на сервер.
На сервере они хранятся в шифрованном виде и никаких ключей для дешифрования на сервере нет принципиально.
У меня есть задача искать на сервере по каким-то запросам или ключевым словам текст в зашифрованных сообщениях.
Как это у меня работает сейчас. Я запрашиваю порции шифротекста с сервера, расшифровываю на клиенте приватными ключами. И уже в расшифрованном тексте на клиенте я делаю нужный мне поиск.
Недостаток очевиден - поиск производится крайне медленно и безо всякой оптимизации, никакой Sphynx тут не поможет.
Вопрос. Можно ли как-то ускорить поиск в шифрованном тексте?
P.S. Это, кстати, пинок в сторону Телеграма как доказательство, что там ничто не шифруется, поскольку поиск за огромный период времени там происходит моментально. И на сервере, а не на клиенте.
P.P.S. Кстати, я вспомнил, что когда-то на Андроиде работал с SqlCypher - версия для Sqlite, но с шифрованием. Вся база зашифрована, но обращение к ней шло да, чуть медленнее, но вполне быстро на тестах для больших объёмов. Как там это реализовано, интересно...
Как идея... А что, если на этапе шифрования на клиенте делать парсинг по ключевым словам, шифровать их и передавать вместе с шифротекстом тоже в зашифрованном виде. На сервере сохранять эти слова-тэги в виде индексов.
Тогда при поисковом запросе можно так же в зашифрованном виде обращаться к этим шифрованным тэгам, ключевым словам...
Николай Савельев, звучит интересно.
Но тут есть небольшая проблемка. Когда я шифрую алгоритмом RSA с помощью одних и тех же неизменяемых ключей, то сообщение каждый раз получается в разном виде. Хотя и без проблем дешифруется одними и теми же ключами. Это особенность алгоритма.
Таким образом, получается, что для одного и того же текста/ключевых слов каждый раз будет разный шифротекст. А значит, невозможно построить однозначный индекс для быстрого поиска
пинок в сторону Телеграма как доказательство, что там ничто не шифруется, поскольку поиск за огромный период времени там происходит моментально
достаточно другого - push уведомления. Их текст отправляется с сервера, т.е. текст сообщения расшифровывается до отправки клиенту
и поиск в тг очень и очень паршивый. Что по чатам, что внутри чатов. Как так хреново можно было сделать не понимаю. думаю, дело в сложной архитектуре репликации и географическом распределении серверов.
mayton2019, да, я сделал шифрование на клиенте, чтобы защитить сервер.
После шифрования обычные POST/GET для отправки сообщений и их получения, как в обычном мессенджере. Только весь текст зашифрован
Индекс на стороне клиента
Xapian, например https://xapian.org/
Индекс на стороне браузера, например https://medium.com/@Runbox/indexing-and-searching-... https://github.com/runbox/runbox-searchindex
Upd
Эти ребята на 1G клиентских данных на сервере хранят 100M индексов на клиенте.
То есть 1 к 10.
"Since the typical index size constitutes 5–10% of the email corpus size, the size of the index for 1 GB of email rarely exceeds 100 MB which is negligible on most devices."
Например, продолжить твое "сейчас" и на клиенте хранить индекс всех сообщений (если такое возможно). А так гугли "searchable symmetric encryption" и "полностью гомоморфное шифрование"
"Быстро" не получится.
Ваш подход максимально верный - поиск должен осуществляться на клиенте.
Есть гомоморфное шифрование, позволяет буквально проводить вычисления над зашифрованными данными без их расшифровки. Но это адский треш, вся база данных на каждую операцию должна проходить через вычисления. Помню был аддон для postgres (давно, маловероятно что поддерживается), так же помню была статья про компилятор типа C языка (без циклов)
Возможно стоит посмотреть в сторону поиска по изначально сохраненным хешам информации до шифрования в соответствие с шифрованными данными.
Тогда на клиенте вычислять хэш запроса, на сервере из бд отдавать шифрованные данные на основании хеша.
Нет, так не получится.
Хэш делается по всему сообщению целиком.
Но пользователи ищут текст по словам, да ещё и с учётом морфологии. Поэтому никак не получится
Сложный
Простой
Простой
