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

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

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


aes cryptography initialization-vector
person tryeng    schedule 04.03.2011    source источник

Ответы (3)


arrow_upward
9
arrow_downward

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

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

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

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

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

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

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

person Thomas Pornin    schedule 04.03.2011
comment
Спасибо за ответ, это было именно то, что я хотел знать! У меня нет репутации, чтобы проголосовать за вас, я надеюсь, что это сделает кто-то другой. :-) - person tryeng; 04.03.2011

arrow_upward
0
arrow_downward

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

person KeithS    schedule 04.03.2011
comment
Сборка не находится в открытом доступе. Мой главный вопрос здесь заключается в том, безопасно ли использовать постоянный IV. Если кто-то получит доступ ко всей базе данных, будет ли легче взломать шифрование, чем если бы я использовал уникальный (случайный) IV для каждой строки? - person tryeng; 04.03.2011
comment
Это не более и не менее безопасно, чем любой метод, использующий случайный IV, за одним исключением: если они знают за одного, они знают за всех. Вы (и любой злоумышленник) должны знать два секрета — ключ и IV — для расшифровки шифротекста AES, зашифрованного с помощью одного и того же. Если вы используете постоянный IV, вы можете скрыть его так же, как и свой ключ. Если вы используете случайный IV, вы должны каким-то образом включить IV в зашифрованный текст, чтобы его можно было использовать для расшифровки этого сообщения; это означает, что два секрета становятся ключом, и то, как вы включаете IV в зашифрованный текст. Этот второй секрет теперь гораздо легче раскрыть. - person KeithS; 04.03.2011
comment
Хорошо, тогда все так, как я и думал. Спасибо за ответы! :-) - person tryeng; 04.03.2011
comment
@tryeng IV не имеет значения - имея только один блок и фиксированный ключ, вы также можете использовать ECB, как рекомендует Томас, и вообще пропустить IV. - person Nick Johnson; 08.03.2011

arrow_upward
0
arrow_downward

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

person RunHolt    schedule 10.01.2012