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

Question

Я пишу реализацию алгоритма шифрования XXTEA, который работает с " streams " т.е. может использоваться следующим образом: crypt mykey < myfile > выход.

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

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

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

Answer 1

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

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

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

Answer 2

Читать: http://msdn.microsoft .com / EN-US / библиотека / 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 3

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

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

Answer 4

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

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