Практический риск использования stati c IV среди редко дублируемых значений? - PullRequest
0 голосов
/ 30 марта 2020

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

После долгих исследований я выбрал шифрование AES-256-CB C. Я выбрал жестко запрограммированный одиночный IV, потому что все шифруемые ключи абсолютно уникальны, и мы не можем позволить себе добавить дополнительные столбцы для хранения IV, если это не является абсолютно необходимым. Но теперь они хотят зашифровать дополнительный столбец, который содержит редко дублированные значения (например, 10000 строк, может быть 20-30 дубликатов).

По-видимому, наиболее очевидный недостаток в шифровании этого дополнительного столбца заключается в том, что дублирующиеся значения будут разделяют одно и то же зашифрованное значение, и, таким образом, взлом одного приводит к взлому дубликатов. Их это совсем не волнует, поскольку эта ценность не особенно «ценна». Но я читал, что существует риск того, что хакер сможет лучше предсказать, как вы шифруете свои данные, используя идентичную пару значений IV +, что впоследствии может привести к более легкой расшифровке несвязанных значений. Это законное беспокойство я должен передать им? Учитывая ограничения по времени разработки и возможности изменять существующую структуру базы данных, стоит ли учитывать этот слишком большой риск?

Ответы [ 2 ]

0 голосов
/ 05 апреля 2020

Разве это не должно быть вопросом для crypto.stackexchange.com, так как он не имеет прямого отношения к API программирования et c.?

В любом случае, мне интересно, против кого вы защищаете свой ( незашифрованные) данные?

  • злоумышленники вашего приложения, которые могут в какой-то момент использовать (SQL) инъекции
  • администраторы системы / базы данных или хостинг-провайдер, которые могут читать / изменять базу данных или резервные копии

И какие риски вы пытаетесь уменьшить с помощью этого шифрования, например:

  • злоумышленник дублирует записи из / в часть базы данных, к которой они могут получить доступ приложение, таким образом, обманывая приложение для его / расшифровки
  • статистический анализ (https://en.wikipedia.org/wiki/Frequency_analysis)

Эта функция шифрования может быть повторно использована в будущем месяцы и годы другими разработчиками для других областей баз данных или даже для других приложений, так почему бы не спроектировать его для безопасного повторного использования, получая необходимые биты IV из результата Функция ha sh (например, SHA-3) для следующих составных входов:

  1. Имя базы данных
  2. Имя схемы
  3. Имя таблицы
  4. Имя столбца
  5. Идентификатор / первичный ключ записи

Отказ от ответственности: я не специалист по криптографии, поэтому не верьте мне на слово, нет гарантирует что бы то ни было.

0 голосов
/ 01 апреля 2020

У вас есть, по крайней мере, пара вещей, которые вы можете сделать, каждая из которых требует разных усилий по реализации.

  1. Как уже упоминал Питер, вы можете склеить свой IV в начале своего зашифрованного текста. , Надеемся, что это не нарушит ограничение общей длины, установленное для столбца. Примечание: длина зашифрованного текста будет больше из-за: 1) режима CB C 2) длины IV 3) BASE 64 или любой другой используемой вами кодировки.

  2. Вы можете получить IV из другого ключевого атрибута из той же записи, который является уникальным и не изменяется.

  3. Иногда необходимо использовать шифрование детерминированного c в базах данных (шифрование с тем же самым, стати c IV). Обычно это происходит, когда значение столбца необходимо использовать в некоторых условиях SQL WHERE. Если это так, просто используйте некоторое значение stati c IV и примите последствия.

...