Обзор

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

Причина, по которой мне нужна эта возможность, заключается в том, что я использую шифрование AES для реализации одноразового пароля (OTP) схема. Когда клиент входит на сервер, ему дается семя. Первый OTP генерируется путем шифрования этого начального числа. Для каждого последующего запроса клиент шифрует последний OTP, используя общий ключ AES между сервером и клиентом. Следовательно, даже если злоумышленник прослушал последний OTP без общего ключа, он не смог бы получить следующий OTP. OTP шифруется с помощью AES в режиме CBC. Проблема возникает, если сервер и клиент не синхронизируются. Я планировал справиться с этим путем создания нескольких одноразовых паролей в будущем на стороне сервера и проверки того, соответствует ли какой-либо из них клиентскому. Однако без способа детерминированного расчета IV для каждой итерации шифрования это невозможно.

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

Теория

ECB

Я знаю, что ECB выдаст тот же результат для идентичных блоков открытого текста, зашифрованных с одинаковыми ключами. Следовательно, его не следует использовать для нескольких блоков данных, потому что информацию об открытом тексте можно различить путем статистического анализа данных. Исходя из этого, казалось бы, если бы вы могли гарантировать, что ваши данные всегда меньше 16 байт (128 бит), это устранило бы проблему статистической атаки.Кроме того, если бы вы также могли гарантировать, что никогда не шифруете один и тот же открытый текст одним и тем же ключом, вы никогда не получите одинаковый результат. Поэтому мне кажется, что использование ECB безопасно, если ваша система всегда будет соответствовать этим очень строгим критериям.

CBC и IV

Я знаю, что CBC предназначен для устранения обеих этих проблем. Объединяя блоки в цепочку, он устраняет многоблочную статистическую атаку ECB. Никогда не используя один и тот же IV для одного и того же ключа AES, вы устраняете проблему шифрования одним и тем же открытым текстом одного и того же вывода с одним и тем же ключом.

Key Uniqueness

Если каждый клиент получает сгенерированный ключ AES, то пока существует малая вероятность того, что несколько пользователей имеют один и тот же ключ, шансы крайне малы. Поэтому можно с уверенностью предположить, что никакие два клиента не будут использовать один и тот же ключ AES.

Предлагаемое решение

Мое предлагаемое решение состоит в том, чтобы дать каждому клиенту уникальный ключ AES. Когда ключ сгенерирован, счетчик будет инициализирован случайным числом. Каждый раз, когда что-то необходимо зашифровать, счетчик будет увеличиваться на единицу. Этот номер будет добавлен в блок, а затем зашифрован с использованием AES в режиме ECB. Результатом этого будет мой IV для шифрования данных с использованием CBC.

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

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

Мои вопросы

Верно ли мое фундаментальное понимание технологий, описанных в предлагаемом решении? Что-то явно не так с предложенным мной решением? Есть ли какой-либо недостаток безопасности в использовании одного и того же ключа для генерации IV предложенным способом, а также для шифрования с использованием CBC?

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

Заранее спасибо.