режимы шифрования
Реализовываю в программе шифрование, и возникли некоторые вопросы, связанные с режимами.
ECB дает одинаковые выходные данные, при одинаковых входных.
CBC избавляет от появления на выходе одинаковых последовательностей данных, если одинаковые последовательности есть на входе. Но если два раза зашифровать одни и те же данные, то и выходные будут совпадать. Также если шифровать последовательности, у которых начало одинаковое, а отличия имеются где-нибудь в середине, то у зашифрованного текста начала тоже будут совпадать, а различаться они начнут с того места, где в входных данных появились отличия.
Я сделал следующим образом.
Входная последовательность дополняется "мусором" до выравнивания по размеру блока (64бита).
Генерируется 4-х байтный случайный ключ.
Этим ключом XORится ключ шифрования.
Входная последовательность разбивается на блоки по 64 бита, которые шифруются алгоритмом RC5. (Реализация RC5 взята из одной криптобиблиотеки).
К полученным зашифрованным данным в начало добавляется 4 байта сгенерированного ключа и 1 байт размера "мусора".
При дешифрации соответственно извлекается XOR-ключ, которым ксорится ключ шифрования, разбивается на блоки, дешифруется, из последнего блока удаляется "мусор", по размеру, указанному в начале.
В результате при шифровании одних и тех же данных зашифрованные получаются всегда разные (точнее, количество вариантов определяется размером XOR-ключа и в данном случае составляет 4294967295).
Хотелось бы узнать, что вы думаете об этой схеме.
Ничего, что XOR-ключ и размер "мусора" открыто лежат в выходных данных?
По каким критериям выбирать размер XOR-ключа?
Влияет ли как то на стойкость алгоритм его генерации, подойдет ли здесь стандартный Random?
Каким образом лучше получать "мусор", генерировать случайно, или можно вставлять один и тот же?
Извиняюсь, если немного путанно.. :?
комментариев: 5 документов: 0 редакций: 0
К чему это? Лучше бы посмотрели исходнег, указали на недочеты, посоветовали пути улучшения...
Сначала забыл пароль и email, на который регистрировался, и некоторое время пользовался гостевым входом с логином "celeron" с русской буквой. На новом форуме решил зарегистрироваться снова.
комментариев: 11558 документов: 1036 редакций: 4118
Это в смысле CBC. Я тут по соседству начинал тему о правилах крипторазработки. При выборе режима шифрования исходите из критериев простоты, целесообразности, соответствия необходимым требованиям. Вот, например, к чему реализовывать CBC? Я, конечно, не знаю Вашего ТЗ, поэтому могу ошибаться, но в Вашем случае он может что-то, чего не может счётчик? Если так, то реализация режима разумна, если нет — тогда зачем?
Да, могут быть неочевидные причины, например, желания попрактиковаться. Это вполне понятно. Если дело в этом — скажите, и я тут же заткнусь. :-)
комментариев: 5 документов: 0 редакций: 0
Именно желание попрактиковаться, получше разобраться :) По ТЗ, честно говоря, подошел бы и простой XOR, но хочется, чтобы все было "на уровне".
Затыкаться совсем не нужно :), наоборот, лучше скажите, можно ли для генерирования VI применять API функцию CoCreateGuid?
А вообще, Вы конечно правы, незачем тратить драгоценное время на реализацию еще и CBC..
комментариев: 9796 документов: 488 редакций: 5664
PRNG1 xor P xor (C k <– (PRNG1 xor Counter))
PRNG2 xor P xor (C k <– (PRNG2 xor Counter))
Может я не понял Вашу картинку, но зачем делать PRNG xor дважды? И на вход шифра и на выход?
По моему это пустая трата ресурсов и уменьшает стойкость схемы опять таки в K^(n/2) раз,
потому увеличивается вероятность того что по парадоксу дней рождения
у Вас случайно совпадёт Ck=PRNG и вы получите 32-битовый уровень безопасности вместо 64-битового.
Посмотрите как устроен режим счётчика в соотв. стандартах.
Я бы вот не взялся изобретать новый режим шифрования. Или придумывать RSA с нуля. Sattva правильно сделал набор рекоммендаций по этому поводу. Особенно добавить нечего, хотя по этой теме большие книги пишут.