Заполнение - алгоритм шифрования

Question

Я пишу реализацию алгоритма шифрования XXTEA, который работает на «потоках», т. Е. Может использоваться как: crypt mykey output.

Одним из необходимых условий является то, что он вообще не имеет доступа к файлу (он читает только блок фиксированного размера, пока не найдет EOF). Алгоритм требует, чтобы байты данных были кратны 4, поэтому необходимо добавить заполнение.

Для простого текста хорошим решением является заполнение значениями NULL, а при расшифровке просто игнорируйте NULL, но эту же стратегию нельзя использовать для двоичных потоков (которые могут содержать встроенные значения NULL).

Я читал общие решения, такие как заполнение количеством пропущенных символов (если пропущено 3 символа, затем добавьте 3, 3, 3 в конце) и т. Д., Но мне интересно: есть более элегантное решение

Answer 1

Чтение: http://msdn.microsoft.com/en-us/library/system.security.cryptography.paddingmode.aspx

У него есть список распространенных методов заполнения, например:

PKCS7 - Строка заполнения PKCS # 7 состоит из последовательности байтов, каждый из которых равен общему числу добавленных байтов заполнения.

Строка заполнения ANSIX923 состоит из последовательности байтов, заполненных нулями перед длиной.

Строка заполнения ISO10126 состоит из случайных данных до длины.

Примеры:

Необработанные данные: 01 01 01 01 01

PKCS # 7: 01 01 01 01 01 03 03 03

ANSIX923 01 01 01 01 01 00 00 03

ISO10126: 01 01 01 01 01 CD A9 03

Answer 2

Читайте о краже зашифрованного текста . Это возможно намного более изящно чем дополнение открытого текста. Кроме того, я бы предложил использовать размер блока, превышающий 4 байта - 64 бита - это, наверное, минимум.

Строго говоря, криптография своими руками - опасная идея; трудно победить алгоритмы, которые все крипто-сообщество пыталось и не смогло сломать. Повеселитесь и подумайте о чтении этого или хотя бы чего-нибудь из раздела "связанных чтений" Шнайера.

Answer 3

Чтение вопроса выглядит так, как будто это вопрос безопасности. Проще говоря, у вас есть API, который ожидает в качестве входных данных кратное 4 байта, что у вас не всегда есть.

Добавление до 3 байтов в любой двоичный поток опасно, если вы не можете гарантировать, что двоичному потоку все равно. Добавление 0 в конец exe-файла не имеет значения, так как exe-файлы имеют заголовки, указывающие соответствующие размеры всех оставшихся битов. Добавление 0 в конец файла pcx приведет к его разрыву, поскольку файлы pcx имеют заголовок, начинающийся с определенного числа байтов в конце файла.

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

Answer 4

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

Если требуется заполнение, это не потоковый шифр ИМХО. Как если бы вы дополняли число, кратное 4, или 16, то какая огромная разница? И если он дополняется кратным 16 байтам, вы можете использовать практически любой блочный шифр. На самом деле ваш шифр является блочным шифром, он работает только с 4-байтовыми блоками. Это был потоковый шифр в системе, где каждый «символ» составляет 4 байта (например, при шифровании текста UTF-32, в этом случае данные всегда будут кратны 4, таким образом, заполнение никогда не будет). *