Режим CTR с использованием начального вектора (IV)

Question

из того, что я знаю, режим CTR не использует начальный вектор. Он просто берет счетчик, шифрует его с помощью заданного ключа, а затем XOR - результат с открытым текстом, чтобы получить зашифрованный текст.

Другие режимы шифрования блоков, такие как CBC, перед выполнением шифрования, они имеют XOR открытый текст с начальным вектором.

Итак, вот моя проблема. У меня есть следующий код в Java (с использованием BouncyCastle библиотеки):

Cipher cipher = Cipher.getInstance("AES/CTR/PKCS5Padding", "BC"); 

cipher.init(Cipher.ENCRYPT_MODE, key); 

byte[] result = cipher.doFinal("Some plaintext"); 

Каждый вызов отличается от приведенного выше кода с тем же ключом дает другой выход! Но при выполнении:

byte[] IV = new byte[]{0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}; 

Cipher cipher = Cipher.getInstance("AES/CTR/PKCS5Padding", "BC"); 

cipher.init(Cipher.ENCRYPT_MODE, key, IV); 

byte[] result = cipher.doFinal("Some plaintext"); 

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

Любые идеи были бы очень полезными. Спасибо

Answer 1

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

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

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

Обратите внимание, что это только соглашение о маркировке. Математически это то же самое, что назвать все «счетчик» и запустить счетчик с случайным кратным некоторого целого для каждого сообщения.

Я не знаю, как конкретно работает реализация Bouncy Castle - это, возможно, позволяет вам установить весь начальный блок, счетчик и все с использованием значения IV. По-видимому, он создает для вас разумный IV, если вы его не поставляете, поэтому вы получаете разные результаты с одним и тем же входом. Суть в том, что это хорошо, и именно то, что вы хотите - поставка всех нулей - bad, а не то, что вы хотите.

Answer 2

Режим CTR использует то, что по сути эквивалентно IV, и это начальное значение счетчика.

Answer 3

CTR работает путем шифрования последовательных значений счетчика. Первое значение для этой последовательности : IV (IV означает «начальное значение» ...). Таким образом, CTR действительно использует IV.

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

«легкий» способ избежать повторения счетчика, чтобы всегда выбирать IV с криптографически безопасного генератора случайных чисел в (вспомним «java.security.SecureRandom») среди множества возможных IV, то есть всех последовательностей 16 байт. Это пространство достаточно велико, что вашим риском повторного использования значения счетчика в какой-то момент можно пренебречь.

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