Зашифруйте ключи хеш-карты, сохраняя постоянную скорость поиска

Question

Я бы хотел зашифровать ключи и значения хеш-карты с помощью AES256 CBC, индивидуально.Задача состоит в том, чтобы зашифровать ключи, поддерживая постоянную скорость поиска и безопасность (в основном от атак по словарю).

Я читал о слепых индексах, но они требуют некоторой случайности при создании (соль, одноразовый номер), и это невозможнодля функции поиска, чтобы воссоздать одноразовый номер при поиске.При поиске нам нужно знать, откуда можно извлечь одноразовый номер для определенного ключа, что в итоге означало бы быть уязвимым в другом месте.

Пока что я могу думать только о двух вариантах.

Первый можно было бы просто не шифровать ключи, хотя я бы предпочел это сделать.

второй один - получить слепые индексы путем примененияпреобразование наподобие

blind_index(key) = encrypt(digest(key))

, но проблема здесь в том, что вам необходим уникальный вектор инициализации для каждого шифрования ключа, что вновь возвращает нас к проблеме, описанной выше: использование таблицы IV для того, чтобыфункция поиска, позволяющая восстанавливать слепой индекс при поиске, который перемещает ту же проблему в другом месте.

Для второго подхода я подумал: поскольку я всегда шифрую уникальные значения (ключи уникальны и даже если ониявляются подстроками друг друга, например, «awesome» и «awesome_key», они хешируются перед шифрованием, поэтому они выглядят совершенно иначеhed & unicrypted 'form) Я мог бы использовать глобальный IV для всех шифрований, которые могут быть легко доступны для функции поиска.Поскольку для функции поиска требуется ключ шифрования, только владелец сможет правильно рассчитать слепой индекс, и в самой карте не будет видимых сходств между ключами, которые похожи в открытом тексте.

Большая проблема IВторой подход заключается в том, что он нарушает идею никогда не использовать IV для более чем одного шифрования.Я мог бы запутать IV «чтобы сделать его более безопасным», но это опять-таки плохая идея, так как предполагается, что IV должны быть открытым текстом.

Подробнее об обстоятельствах:

• приложение длякарта для мобильного
• будет выгружена в файл * карта 1027 *
• будет доступна для поиска через REST API

Возможно, мне следует использовать другой алгоритм (например, EBC)?

Заранее спасибо!

Answer 1

Это полностью в области шифрования с сохранением формата (FPE).Однако применять его сложно, и библиотеки, которые хорошо с ним справляются, не так уж часто встречаются.FPE принимает количество бит или даже диапазон, а затем возвращает зашифрованное значение того же размера или в том же диапазоне.Этот зашифрованный текст является псевдослучайным в данной области, если входные значения являются уникальными (что для ключей в хэш-таблице они по определению).

Если вы можете расширить свой зашифрованный текст по сравнению с открытым текстомтогда вы также можете посмотреть на режимы SIV (AES-SIV или AES-GCM_SIV, которые гораздо проще обрабатывать. Они возвращают байтовый массив, который может превратиться в String, например, с использованием кодировки base64. В противном случае вы можете обернутьбайтовый массив и предоставьте свой собственный метод equals и * 1005. * Обратите внимание, что они относительно значительно расширяют ваш открытый текст, это режимы аутентификации. Преимущество: IV вычисляется на основе ввода, и любое изменение на входе снова случайным образом зашифровывает зашифрованный текст.

Наконец, вы, конечно, можете просто использовать IV или одноразовый номер для создания своего зашифрованного текста и добавить к значению префикс к нему. Однако следует помнить, что повторное шифрование измененных значений с использованием того же IV будет довольно опасным, так как вы можете утечьинформация через повторение. В некоторых режимах это может привестинарушить предложенную конфиденциальность.Таким образом, вы должны были бы предотвратить повторное использование IV.

Использование ECB, конечно, не рекомендуется для строк.Разумеется, шифрование одного блока будет работать, если входные данные (или могут быть расширены до) одного блока.