Могу ли я использовать половину 256-битного ключа в качестве AES 256 IV?

После некоторых исследований в Google я обнаружил, что IV, используемый в 256-битном шифровании AES, должен быть 128-битным ключом.

Мое шифрование AES256 обрабатывается с помощью ключа случайного 256-битного ключа и IV, сгенерированного из текстовой строки.

Я думаю о MD5 для создания такого ключа, но MD5 кажется устаревшим.

Итак, должно ли быть нормально, если я использую SHA256 для создания 256-битного ключа, а затем разделяю шестнадцатеричную строку ключа поровну на 2 части и использую первую часть в качестве IV в 256-битном шифровании AES?

Итак, должно ли быть нормально, если я использую SHA256, генерирую 256-битный ключ, а затем разделяю шестнадцатеричную строку ключа поровну на 2 части и использую первую часть в качестве IV в 256-битном шифровании AES?

Нет, есть способы лучше.

Прежде всего, когда вы создаете ключ, вам нужен криптографически безопасный генератор случайных чисел. если ты вывести ключ из главного секрета — иногда называемый начальным числом — вам нужна функция деривации ключа или KDF. В последнем случае вы могли бы, например. используйте HKDF с хорошим хэшем, например SHA-256. В принципе, вы можете создать, например. 384-битный вывод с использованием HKDF - даже при использовании SHA-256, но я не думаю, что это хорошая идея из-за следующей части ответа.

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

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

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

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

Наконец, клавиши не буквенно-цифровые; они состоят из битов. Каждый раз, когда ключ переводится в текст, вы открываете проблему безопасности. Так что не делайте этого: сохраняйте ключи бинарными.Я бы предпочел использовать AES-128 с полностью случайным ключом и использовать остальные 128 бит для IV, чем вернуться к использованию шестнадцатеричных чисел.

Шестнадцатеричные числа полезны только для потребления человеком, например. во время тестирования или отладки, когда речь идет о секретных ключах.

Я предполагаю, что вы не раскрываете этот IV. Зависит от того, что вы хотите и какой режим вы используете. IV для AES должен быть 128-битным для таких режимов, как OFB, CBC или CFB, но обычно он короче для таких режимов, как CTR или его варианты с проверкой подлинности, где наиболее распространенным способом создания блока, используемого для генерации потока, будет конкатенация IV (одноразовый номер) и прилавок. Может быть много проблем с использованием части ключа в качестве IV:

На этот раз я не знаю огромного риска, связанного с безопасностью, связанного с раскрытием $E_k(k_{0..|k|/2})$ или же $E_k(k_{0..|k|/2} \oplus P)$ или же $E_k(k_{0..m} || контроль)$ для некоторого известного сообщения $P$ для полного AES (пожалуйста, исправьте, если я ошибаюсь). Это функции, которые вы можете увидеть в зависимости от используемых режимов. Однако фактическое использование может быть небезопасным.

1. По существу делает ваше шифрование детерминированным. Таким образом, это не полностью скрывает сообщение. Для таких режимов, как CBC или CFB, вы можете обнаружить общие префиксы (префиксы полного блока в сообщении). Для CFB это также может позволить вам вывести взаимосвязь между простыми текстами, соответствующими первым расходящимся блокам, в частности $P_{1_i} \oplus P_{2_i}$ где шифротексты расходятся в $ я ^ {й} $ блокировать. Для таких режимов, как CTR или OFB, если вы когда-нибудь повторно используете ключ, это может быть разрушительным, вы можете вывести отношение xor для всего открытого текста для этих двух. Эта проблема сохраняется, даже если вы используете MD5 для IV. Следовательно, это делает его очень непригодным для повторного использования, даже случайно, что легче сказать, чем сделать.

2. В некоторых протоколах, если злоумышленник находит способ получить $E_k(k_{0..|k|/2})$ например, обманом в шифровании $0^{|к|}$ в режиме CBC, а затем обмануть их в шифровании $p_i||c_{i}$ где он получил $с_{я}$ от предыдущего взаимодействия, чтобы выявить $E_k(0^{|k|})$, он может обманом заставить их раскрыть половину ключа, попросив расшифровать $E_k(0^{|k|})$. Это не моя первоначальная идея, поэтому я предлагаю вам посмотреть ответ fgrieu на Здесь, см. недостаток 2.

3. Его использование может быть безопасным, если вы не используете повторно ключ или другие подобные протоколы. Для таких режимов, как CBC или даже ECB с некоторой высокой энтропией (случайные) сообщения без известной структуры также могут подойти, если вы используете их более одного раза.