Регистрация Войти
Рейтинг:1
DADi590 avatar Crypto

Безопасность AES-256/CBC/PKCS#7 + рандомизация и повторное использование IV

флаг es
DADi590

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

Имея это в виду, я создал класс шифрования/дешифрования AES-256/CBC/PKCS#7 + HMAC-SHA512 в приложении-помощнике Android, которое я делаю (предположительно, локально (очень?) личные вещи, и я мог бы опубликовать это в Play Store, так что это не только для меня). Предполагается, что эта комбинация будет очень надежной в течение следующих ??(?) лет. Может быть немного медленнее, но я не возражаю, по крайней мере, сейчас (очень мало данных). Хотя я также читал, что с этим есть одна проблема, когда вектор инициализации используется повторно. Кажется, что с CBC невозможно вернуть данные (правильно?), как это возможно с другими режимами, и поэтому я выбрал этот. [Если есть какие-либо другие проблемы с этим методом, я буду рад узнать о них.]

Но через некоторое время можно обнаружить шаблоны и увидеть, где сообщения равны (равные блоки по 16 байт). Зная, что означает этот блок, можно было бы знать, что он не изменился с течением времени, например, после различных зашифрованных версий.

Поэтому у меня возникла идея: все данные, которые я шифрую, должны быть закодированы с использованием UTF-7. Остальные значения байтов (128-255) используются как случайные значения, которые помещаются по одному на каждые 16 байтов в случайной позиции. Например, в индексе 4 добавляется 154 байта, а в индексе 19 добавляется 234 байта. Таким образом, это всегда случайно, и на самом деле равные блоки данных будут другими, если один и тот же IV используется повторно («случайные» могут повторять значения, и я не могу проверить, использовал ли я их уже в этом случае, поэтому я подумал на этом, чтобы предотвратить проблемы).

Хороший ли это подход? Может ли это смягчить проблему? Может быть, решить его полностью за следующие бесконечные годы, и теперь метод станет полностью безопасным или, по крайней мере, намного более безопасным?

Кроме того, если я что-то сказал не так, я буду рад, если меня поправят! Спасибо!

93
0 + 0
cbc
Рейтинг:1
Maarten Bodewes avatar Crypto
флаг in
Maarten Bodewes

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

Предполагая полностью случайный IV, который вы можете зашифровать $2^{64}$ блоки в AES-CBC и до сих пор есть только один в $~2^{64}$ вероятность столкновения (приблизительно). Обратите внимание, что проблема повторного ввода не ограничивается IV; в конце концов, каждый зашифрованный текст используется как «вектор» для следующего шифрования блока AES.

Ваша идея состоит в том, чтобы немного рандомизировать блоки открытого текста, чтобы предотвратить коллизии IV, что происходит реже, чем коллизии в выводе AES (при условии, что сообщения больше одного блока). Но на самом деле это не поможет, поскольку коллизия все еще может иметь место, и если злоумышленник знает, что находится в большей части открытого текста, ему будет легко догадаться, что находится в другом блоке.

Однако есть еще одна проблема. Теперь у вас есть случайная информация для рандомизации блоков. Если бы вы просто использовали эти случайные данные для создания безопасного случайного IV, вы, скорее всего, не столкнулись бы с проблемой.

Если вы хотите защитить свои данные, вам лучше получить или инкапсулировать конкретные ключи сообщений из вашего «главного ключа».

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

Чего вам точно не следует делать, так это нарушать протокол, пытаясь скрыть недостатки алгоритмов. Это вряд ли удастся, и это добавляет всевозможные ненужные сложности. Шифрование AES не должно требовать чечетки, если используются правильные конструкции.

Примечания по безопасности:

  • Для защиты от будущих изменений я бы рекомендовал также включить IV в расчет MAC. Использование MAC поверх IV добавит к вычислению только 16 байтов, что относительно незначительно.В настоящее время ваш IV не может быть изменен злоумышленником, но изменение протокола может привести к тому, что IV и, следовательно, ваше сообщение уязвимы для изменений.
  • Я также хотел бы предупредить вас, что если данные имеют MAC-адрес, вы уязвимы для атак подстановки: замена данных одного файла другим. Вам понадобится что-то поддающееся проверке / уникальное в заголовке / метаданных и MAC вместе с вашим зашифрованным текстом (у нас есть схемы AEAD, чтобы помочь с этим).
0 + 0
DADi590 avatar
флаг es
DADi590
Ну, моя идея заключалась в том, что, поскольку я уже использовал безопасный генератор случайных чисел (SecureRandom в Java) для IV, я мог бы использовать его снова для рандомизации данных. Поскольку случайные значения могут повторяться, я подумал об этом. Кроме того, то, что вы сказали, «в конце концов, каждый зашифрованный текст используется в качестве« вектора »для следующего шифрования блока AES» также может быть смягчен, поскольку все это было в основном случайным в каждом блоке сообщения, которое составляет 16 байтов (в моем случае голова вообще не эксперт, ха-ха). Но я не думал о том, как часто хотя бы столкновения могут происходить.... Просто "они будут, так что я усложню".
0
Ответить
DADi590 avatar
флаг es
DADi590
Но если вероятность коллизии действительно мала и моя идея мало что даст, я уберу ее и вернусь к обычной кодировке UTF-8. Кроме того, насчет AES-SIV я не могу продолжать.Это не реализовано в Android (Cipher для разработчиков Android - выше сводка, если вам интересно). Часть инкапсуляции, если я правильно понял из Википедии, это не мой случай. Я нигде не храню ключ (по крайней мере, пока - нет сервера, просто небольшой проект). Он получен из пароля, который необходимо вводить вручную — это то, что должно быть достаточно безопасным (лучше, чем локальное хранение ключа).
0
Ответить
Maarten Bodewes avatar
флаг in
Maarten Bodewes
Запустите Argon2 или — если хотите использовать уже реализованный — PBKDF2.Имейте в виду, что вы принимаете ASCII только в том случае, если хотите сохранить совместимость с Java SE, и что вы используете хеш, который имеет достаточно большой размер вывода (не извлекайте из функции больше, чем размер вывода хэша). Безопасная случайная 16-байтовая соль и максимально возможное количество итераций, и все готово (вы можете включить номер версии в свой протокол на случай, если вы когда-нибудь захотите его обновить, или количество итераций). `new SecureRandom()` обычно подходит и должен дать вам хорошо подготовленный PRNG.
1
Ответить
DADi590 avatar
флаг es
DADi590
Что касается примечаний по безопасности, я уже включаю IV в расчет MAC (я вычисляю MAC с зашифрованным текстом, IV и ключом MAC). Я также использую AEAD для этого. Я прочитал именно то, что вы сказали, что можно поменять местами 2 зашифрованных файла, и они все равно будут прочитаны. Хотя, если бы я включил заголовок в файл, это могло бы не сработать. Но в любом случае, да, я буду использовать AAD, чтобы предотвратить это. Спасибо за всю информацию! Отмечу как ответ!
0
Ответить
флаг Moldova
Admin
Этот вопрос на других языках:

Ответить или комментировать

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