id: Гость   вход   регистрация
текущее время 15:54 28/03/2024
Автор темы: Гость, тема открыта 25/09/2006 15:14 Печать
https://www.pgpru.com/Форум/Криптография/РежимыШифрования
создать
просмотр
ссылки

режимы шифрования


Реализовываю в программе шифрование, и возникли некоторые вопросы, связанные с режимами.
ECB дает одинаковые выходные данные, при одинаковых входных.
CBC избавляет от появления на выходе одинаковых последовательностей данных, если одинаковые последовательности есть на входе. Но если два раза зашифровать одни и те же данные, то и выходные будут совпадать. Также если шифровать последовательности, у которых начало одинаковое, а отличия имеются где-нибудь в середине, то у зашифрованного текста начала тоже будут совпадать, а различаться они начнут с того места, где в входных данных появились отличия.


Я сделал следующим образом.
Входная последовательность дополняется "мусором" до выравнивания по размеру блока (64бита).
Генерируется 4-х байтный случайный ключ.
Этим ключом XORится ключ шифрования.
Входная последовательность разбивается на блоки по 64 бита, которые шифруются алгоритмом RC5. (Реализация RC5 взята из одной криптобиблиотеки).
К полученным зашифрованным данным в начало добавляется 4 байта сгенерированного ключа и 1 байт размера "мусора".
При дешифрации соответственно извлекается XOR-ключ, которым ксорится ключ шифрования, разбивается на блоки, дешифруется, из последнего блока удаляется "мусор", по размеру, указанному в начале.


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


Хотелось бы узнать, что вы думаете об этой схеме.
Ничего, что XOR-ключ и размер "мусора" открыто лежат в выходных данных?
По каким критериям выбирать размер XOR-ключа?
Влияет ли как то на стойкость алгоритм его генерации, подойдет ли здесь стандартный Random?
Каким образом лучше получать "мусор", генерировать случайно, или можно вставлять один и тот же?


Извиняюсь, если немного путанно.. :?


 
На страницу: 1, 2 След.
Комментарии
— _celeron_ (16/10/2006 17:14, исправлен 16/10/2006 17:16)   профиль/связь   <#>
комментариев: 5   документов: 0   редакций: 0


К чему это? Лучше бы посмотрели исходнег, указали на недочеты, посоветовали пути улучшения...

Сначала забыл пароль и email, на который регистрировался, и некоторое время пользовался гостевым входом с логином "celeron" с русской буквой. На новом форуме решил зарегистрироваться снова.
— SATtva (16/10/2006 18:57, исправлен 02/08/2007 23:54)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
К чему это? Лучше бы посмотрели исходнег, указали на недочеты, посоветовали пути улучшения...

Это в смысле CBC. Я тут по соседству начинал тему о правилах крипторазработки. При выборе режима шифрования исходите из критериев простоты, целесообразности, соответствия необходимым требованиям. Вот, например, к чему реализовывать CBC? Я, конечно, не знаю Вашего ТЗ, поэтому могу ошибаться, но в Вашем случае он может что-то, чего не может счётчик? Если так, то реализация режима разумна, если нет — тогда зачем?

Да, могут быть неочевидные причины, например, желания попрактиковаться. Это вполне понятно. Если дело в этом — скажите, и я тут же заткнусь. :-)
— _celeron_ (19/10/2006 00:48)   профиль/связь   <#>
комментариев: 5   документов: 0   редакций: 0


Именно желание попрактиковаться, получше разобраться :) По ТЗ, честно говоря, подошел бы и простой XOR, но хочется, чтобы все было "на уровне".
Затыкаться совсем не нужно :), наоборот, лучше скажите, можно ли для генерирования VI применять API функцию CoCreateGuid?

А вообще, Вы конечно правы, незачем тратить драгоценное время на реализацию еще и CBC..
— unknown (19/10/2006 08:57)   профиль/связь   <#>
комментариев: 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 правильно сделал набор рекоммендаций по этому поводу. Особенно добавить нечего, хотя по этой теме большие книги пишут.
На страницу: 1, 2 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3