Тогда дальнейший вопрос к уважаемым посетителям форума: как проверить реализацию этого ГОСТ теперь уже в режиме гаммирования (без обратной связи)?
проверил. результат у нас одинаковый. Но, дальше- вопрос- что делать с этими двумя половинками ? Я шифровал правую часть- 2B2B2B2B получил вмечто нее результат 4B1E16B2. тут у нас все ок. теперь я должен был бы шифровать опять дальше, но опять правую часть. Но до того надо было поменять половинки, а имеено для второго шага сделать так- 4B1E16B2 1F1F1F1F т.е. выход с твоим не тот. Или я может не догоняю?
Ну вот у Винокурова написано так (для этого примера): N2=N1=2B2B2B2B, N1=S=4B1E16B2 выход: 2B2B2B2B 4B1E16B2 То есть результат шифрования заносится в младшую часть, а первоначальная младшая часть заносится в старшую. Мне кажется, что у меня правильно, т.к. пример от уважаемого OLS, показанный в ГОСТ 34.11, у меня совпал...
в общем, вопрос открыт. То, что совпало- не факт, что правильно. То, что надо шифровать правую часть- здесь у нас одинаково. Значит, это так. Дальше, после того как зашифровали. Что делаем? Исходя из сетей Файстеля, да и из статьи кот. я приводил, правую часть пишем влево, а левую- вправо. И, снова шифруем правую часть. Т.е. раньше она была левой. Т.о. за два прохода шифруем все 64 бита. А у тебя что шифруется во втором проходе? 2B2B2B2B 4B1E16B2 снова правая часть? глупо же. В общем, если я не прав, то почему?
На самом деле мы не правую часть шифруем... В шифровании участвуют обе части, если посмотреть хоть на сам ГОСТ, хоть на статью Винокурова, хоть на рисунок в статье Elvis,а. Присмотритесь... А потом правую часть пишем влево, а вправо пишем результат шифрования... Я даже все для себя на бумажке расписывал и с калькулятором все 32 шага считал - было познавательно!
kapger разобрался в чем дело. Действительно, по сетям Файстеля, вероятно и в описании Винокура, должно быть как у тебя получилось. Т.е. в левую часть пишем то, что было справа, а в правую- что у нас и получилось- результат вычислений, конечно там и левая часть и правая часть исходника задействована была. Но, я сделал так, как в описании у Evil`s Interrupt там изначальные данные такие L = 01020304h, R =05060708h ну и под конец что получаем 5. Это действие итоговое и мы просто присваиваем, чисти R значение части L, а часть L инициализируем значением Sxor. Конечный результат: L = 091b2b8bh, R = 01020304h что я и сделал. Понятно, что это не совсем по стандарту, но имеет ли такой вариант право на существование? Не думаю, что криптостойкость тут слабее.
metcenger А в этой же статье у Evil`s Interrupt на рисунке 1 ведь более понятно нарисовано, да и в первом (маленьком) примере указано, что: А вот дальше в этой же статье получается ошибочка вышла в статье... Последнее утверждение противоречит рисунку 1 этой же статьи и самому ГОСТу. Ну, насчет криптостойкости ничего утверждать не буду, однако это уже не ГОСТ 28147-89, однозначно...
metcenger Проверьте тестовый пример из сообщения №79 этой темы на своей реализации. Если все сделано по ГОСТ, то должны получиться указанные в том сообщении результаты. Согласны?
kapger да, именно так. первая приведенная цитата наглядно правильно это демонстрирует. я описал тут эту несостыковку http://www.wasm.ru/comment.php?artcode=gost29147-89
kapger не против на ты меня называть? я не такой и старый, думаю не сильно большая разница у нас в возрасте ))) после обеда исправлю в программе своей. Будет у меня два варианта. Потом и гамму тогда проверим уже.
metcenger Не против Только у меня обращение на Вы совершенно автоматически происходит... Жду результатов! Готовлю примеры для тестирования по гамме без обратной связи...
kapger после первого прохода получается 2B2B2B2B 4B1E16B2 после всех 8-ми проходов какой результат? и после 4 *8 проходов- полный цикл 32-3 какой результат?
Кто-либо может прояснить ситуацию по некотором вопросам, касающимся гаммирования (без обратной связи)? Вопрос в следующем: Цитата из Винокурова: Эти порции берутся с начала файла или наоборот? А если вместо файла рассматривать переменную большого размера (например 128 бит), то порции берутся начиная со старшей части? А если эта переменная (или файл) содержит данные размером 66 бит, то мы сначала должны взять первые 64 бита считая от старших разрядов (или с начала файла) а потом оставшиеся 2 бита или наоборот? И как именно производить сложение по модулю 2 этих двух бит с очередной гаммой размером 64 бита - от гаммы брать только 2 младших бита? А почему тогда при наложении гаммы на первые 64 бита впередистоящие (старшие) нули участвуют в наложении гаммы, а в случае с двумя оставшимися битами нули не должны участвовать - чтобы не изменился размер зашифрованных данных?
metcenger В моем примере (не в ТЕСТЕ по ГОСТ 34.11-94): После первого прохода - 2B2B2B2B4B1E16B2 После первых 8-ми проходов - CB2CCCA1EF638967 После всех 32-х проходов и с последней заменой старшей на младшую - итог E9E99D391CE5E699
kapger после первых 8-ми проходов сошлось, а после всех 32-х не хочет. давай искать ошибку. какой результат после 2*8 3*8 4*8 проходов?
Давай начнем с того, что гаммирование - это режим побитной и потенциально асинхронной обработки потока бит (а не файла : файл - это уже его частный случай). Т.е. заранее ты не знаешь, когда поступит следующий бит для шифрования - через секунду или через час, а предыдущий бит естественно нужно было отправить сразу же как только его зашифровали. Поэтому вся обработка ведется побитно слева направо. Твой вопрос я переформулирую следующим образом : "когда мы получили очередные 64 бита гаммы для шифрования очередных (неизвестно еще когда придущих бит данных), для шифрования самого первого бита данных использовать самый старший или самый младший бит гаммы ?" В тексте ГОСТ : "Значение 1-го бита зашифрованного блока равно сумме по модулю 2 1-го бита открытого блока с 1-м битом переменной N1" - по моему субъективному мнению это означает "с самым младшим битом N1". Я надеюсь ответ понятен из вышенаписанного.