Padding - алгоритм шифрования

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

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

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

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

4 ответа

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

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

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


Читайте: 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


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

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


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

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

licensed under cc by-sa 3.0 with attribution.