Использование постоянного IV с одноблочным шифрованием

Question

У меня есть много маленьких секретов, которые я хочу хранить в зашифрованном виде в базе данных. У клиента базы данных будут ключи, а сервер базы данных не будет заниматься шифрованием и дешифрованием. Все мои секреты составляют 16 байтов или меньше, что означает только один блок при использовании AES. Я использую константу IV (и ключ), чтобы сделать шифрование детерминированным, и моя причина для того, чтобы делать детерминированное шифрование, состоит в том, чтобы иметь возможность легко запрашивать базу данных с использованием зашифрованного текста и убедиться, что один и тот же секрет не сохраняется дважды (делая столбец УНИКАЛЬНЫМ ). Насколько я вижу, это не должно быть проблемой, пока ключ является секретным. Но я хочу быть уверен: я прав или нет? В случае, если я ошибаюсь, какие атаки могут быть сделаны?

Кстати: хэши здесь совершенно бесполезны из-за относительно небольшого числа возможных открытых текстов. С хэшем было бы тривиально получить исходный текст.

Answer 1

Идеальный шифр для сообщений длиной n битов - это перестановка 2 ⁿ последовательностей n битов, выбран случайным образом в 2 ⁿ ! таких перестановок. «Ключ» - это описание того, какая перестановка была выбрана.

Предполагается, что защищенный блочный шифр неотличим от идеального шифра, а n - размер блока. Для AES n = 128 (то есть 16 байтов). AES должен быть безопасным блочным шифром.

Если все ваши секреты имеют длину ровно 16 байтов (или менее 16 байтов, с некоторыми соглашениями о заполнении, чтобы однозначно расширить их до 16 байтов), тогда вам нужен идеальный шифр, и AES «как сам по себе» должен подойти. , В обычных реализациях AES, в которых требуется применять заполнение и обрабатывать произвольно длинные потоки, вы можете получить одноблочное шифрование, запросив режим ECB или режим CBC с нулевым IV.

Все проблемы, связанные с IV, и то, почему режимы цепочки, такие как CBC, были необходимы в первую очередь, связаны с многоблочными сообщениями. AES шифрует 16-байтовые сообщения (не больше, не меньше): режимы цепочки предназначены для эмуляции идеального шифра для более длинных сообщений. Если в вашем приложении все сообщения имеют длину ровно 16 байтов (или они короче, но вы добавляете заполнение), то вам просто нужен «сырой» AES; и фиксированный IV - достаточно близкая эмуляция необработанного AES.

Обратите внимание на следующее:

• Если вы храните зашифрованные элементы в базе данных и вам требуется уникальность на протяжении всего срока службы вашего приложения, то ваш секретный ключ является долгоживущим. Сохранение секретного ключа в течение длительного времени может быть сложной проблемой. Например, долгоживущим секретным ключам нужно какое-то хранилище (которое сопротивляется перезагрузкам). Как вы управляете мертвыми жесткими дисками? Вы уничтожаете их в заполненном кислотой котле?

• Шифрование обеспечивает конфиденциальность , а не целостность . В большинстве моделей безопасности злоумышленники могут быть активными (т. Е. Если злоумышленник может прочитать базу данных, он, вероятно, может записать в нее). Активные атаки открывают целый ряд проблем: например, что может произойти, если злоумышленник обменяет некоторые ваши секреты в базе данных? Или изменяет некоторые случайно? Шифрование, как всегда, легкая часть (не то, что она действительно «легкая», но она намного проще, чем остальная часть работы).

Answer 2

Статический IV сделает вашу реализацию уязвимой для частотных атак. См. Для шифрования AES CBC, какое значение имеет IV?

Answer 3

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