Comments 12
Первое что в голову приходит это всё таки раскрыть какоето количество символов в начале ключа. Ну например если разговор про фамилии то пару символов вполне можно. Если обратиться надо по номеру счета или например паспорта то наверное можно просто хэш. Вообще непонятно както в каких условиях может потребоваться такая сортировка и для чего...
В моем случае речь шла про названия различных документов. Все они были достаточно длинные и разнообразные, да и строгость сортировки была не критична. Так что пожертвовать первыми несколькими символами было приемлемо.
Тогда просто индексировать по хэшу названия. Но зачем это вообще? Название целиком врядли ктото знает точно а начало названия это вообще обычно стандартные "распоряжения" "соглашения" "контракты" то есть абсолютно неинформативные вещи. По смыслу индексы надо строить по номеру, дате и тегам.
Ситуация была немного нестандартная: "документ" - было собирательное название сущности, к которой были приаттачены разнообразные сканы, фотографии и прочее. То есть это был не столько "документ" в общем понимании, сколько "одна бизнес-операция" (уж такую выбрали терминологию). Например, "Закупка барахла январе, Китай". А внутри - сканы таможенных и бухгалтерских документов, фотографии барахла при приемке.
а кто или что обращалось за информацией из этой сущности по зашифрованному индексу полного наименования сущности?... или клиент с ключом просто получает весь список и ищет что нужно?... тогда зачем сортировать пусть он сам в экселе отсортирует...
возможно я чтото лишнее уже спрашиваю инфобез дело такое тогда лучше не отвечайте
Когда-то столкнулся с подобным, и путь был похож на ваш: заранее вычисленный индекс -> подозрение на ухудшение криптостойкости. Затем пришел к тому, чтобы зашифровать и сам индекс. Поскольку записей было немного, сортировку сделал на стороне клиента.
Очень понравился ход мыслей автора. Иногда именно шаг назад помогает найти лучшее решение.
В теории позволяет выполнять широкий спектр вычислений над зашифрованными данными без их предварительной расшифровки.
Всё так, но большая часть реализаций гомоморфного шифрования не поддерживает операцию коммутативного сравнения, поэтому для вашей задачи оно бы вряд ли подошло (за исключением отдельных вычислительноёмких реализаций). Кстати, не поделитесь ссылочками на реализацию с поддержкой сравнения зашифрованных строк произвольной длинны? Я такие реализации просто видел и использовал только над множеством чисел, а вот для строк произвольной длинны как-то не встречал.
Вы правы. У меня этот вариант быстро отпал по другим причинам (из-за вычислительного оверхеда и огромной сложности реализации), поэтому я не углублялся в поддерживаемые операции. Ошибочно предположил, что сравнение тоже относится к их числу. Сейчас почитал подробнее и понял, что это не так. Похоже, что обходные пути есть, но это именно обходные пути, которые увеличивают и без того безумный оверхед. Этот фрагмент статьи стоит поправить. Спасибо, что обратили внимание.
Как я решал задачу сортировки зашифрованных строк