вопрос по ГОСТ 28147-89

сейчас выходные, поэтому читать что- то позже буду. за книжку- спасибо.
kapger
Вопрос- у тебя получается расшифровать и получить изначальные данные?
Возможно, расшифровывать данные и не надо. Объясняю. Для режима гаммирования, нам важно получать ПСП двумя разными генераторами одинаковыми. Мы её и имеем. А зная ПСП, уже восстанавливаем начальное сообщение. Но, это для гаммирования.

Не согласен по поводу зашифровать все 32 раза. На последнем проходе, т.е. после 31-го, мы и придем к строке
2B2B2B2B 4B1E16B2
и? дальше как? если придем конечно.

вопрос открыт из топика 118.

У тебя как это в проге на Си реализоывано?

 

metcenger
При расшифровании на последнем проходе, т.е. после 31-го, мы придем к строке
4B1E16B2 2B2B2B2B (!!!)
А дальше все просто...

Прогу на Си пока приводить не буду здесь, т.к. и прога сырая пока, да и не Си это... Я же писал, что Си-подобный, да еще и 16-разрядный компилятор, так что разобраться в нем довольно сложновато...

 

irrona
Спасибо за книгу! Нашел и посмотрел, частично...
На странице 189 этой книги указано, что

А какую таблицу замен используют в этом примере? Явно не указано...

 

kapger
Повторю вопрос- у тебя в твоей проге получается вконце последнего шага 32-Р получить изначальные данные? Да. Нет.
если да, то скажи пож-ста, какие значения имели левая и правая части, если результат после одного прохода такой
22222222 9721D0F5
ключ и таблица прежние. Это проход один раз, ничего не переворачивал. Т.е. видно, что правая часть равна 22222222
иначе- не верю, что это возможно

Более того, утверждаю, что это не возможно. Сейчас докажу.
Как помнишь, на шаге 32-3 мы брали наши данные L & R , различными способами изменяли R, на последнем шаге 32-3 мы поXORили нашу измененную R с неизмененной частью L...

в Си это выглядит так
//XOR c data0
dataR = Srol ^ data0;

на этом шаг 32-3 закончен. Дальше мы там право пишем влево... не важно. на шаге 32-Р мы начинаем с того, что делаем обратный XOR. Задача- получить наш Srol. Для этого нам нужны все компоненты, в частности data0- я изначально части L присвоил data0, части R присвоил data1.

И??? где я её теперь возьму? а надо бы было так, чтобы получить Srol
Srol = dataR ^ data0;

Отвлеченный пример.
10 = 6+4 (dataR в роли 10)
4 у нас нету (левой части), а 6- у нас искомый результат, нам же надо дальше двигаться по шагу 32- Р, т.е. наш Srol

думаю, понятно, что 10 можно получить так:
2+8
1+9
3+7
.....

мысль ясна?
Возможно Evil's был прав в своей реализации?

 

metcenger
Отвечаю: у меня получается в конце последнего (32-го) шага базового цикла 32-Р (с учетом последней однократной перестановки левых и правых частей) получить изначальные данные! А иначе у меня бы не сошелся пример из ГОСТ 34.11!

Я, честно говоря, не понял после какого именно прохода и при расшифровании или зашифровании мы должны иметь результат 22222222 9721D0F5 - у меня нет такого...
Если имеется ввиду какие значения имели левая и правая части перед началом последнего прохода при расшифровании, то они были 4B1E16B2 2B2B2B2B, я это уже писал в сообщении №122. Нетрудно убедиться, что это значение, используемое при расшифровании на последнем 32-м шаге "соответствует" результату предыдущего зашифрования после 1-го шага, только с переставленными местами правой и левой части. И так будет всегда, я посмотрел специально, как-то:
- входное значение для расшифрования для 32-го шага "соответствует" выходному значению зашифрования после 1-го шага;
- входное значение для расшифрования для 31-го шага "соответствует" выходному значению зашифрования после 2-го шага;
- ...
- входное значение для расшифрования для 1-го шага "соответствует" выходному значению зашифрования после 32-го шага.
Здесь все фразы "соответствует" означают то, что левая и правая части переставлены местами. И так и должно быть, потому что последним (после 32-го шага шифрования или расшифрования) пунктом (один раз за весь цикл 32-Р или 32-З) идет перестановка левой и правой части. Она описана в ГОСТ и сделана как раз для того, чтобы результат шифрования можно было расшифровать! И, как мне кажется, совершенно не имеет смысла попытка расшифровывать значение, полученное на каком-либо шаге шифрования. Но если уж это надо сделать, то в уме поменяйте левую и правую части местами и убедитесь, что это так и есть...

 

kapger

Как это нет? Таблица 5-3 на стр.182 "Тестовые значения узлов замены"

 

metcenger

Мне кажется, что здесь у нас есть небольшое взаимное недопонимание... Во-первых, в терминах. Шаг - это то, что описано в статье Evil's. А базовый цикл 32-З (или же З2-Р) - это 32 таких шага по очереди с 32 определенными ключами и, обязательно, в конце цикла 32-З (или же З2-Р) однократной заменой старшей и младшей части. Так?
Во-вторых, в реализации... Как я немного понял, то Вы пытаетесь при расшифровании двигаться обратными арифметическими (логическими и другими) путями. Но это ведь не правильно. Базовый цикл расшифрования 32-Р почти ничем (!) не отличается от цикла зашифрования 32-З, за исключением порядка подачи в каждый из его 32 шагов ключей. И всё...
Поэтому, описанное у Вас

немножко не соответствует истине... Не нужно пытаться начинать с того, что делать обратный XOR. Делайте при расшифровании в цикле 32-Р точно тоже самое, что и в цикле 32-З, только ключи подавайте в другой последовательности...

 

irrona
То есть именно эта таблица используется во всех тестовых примерах?
Спасибо! Обязательно попробую. О результатах отпишусь.

Просто в том примере, который я предлагал для проверки гаммирования, есть очень интересная проверка на правильность сложения по модулю 2^32-1, а реализация этого вычисления не всегда правильная, т.к. я просмотрел кучу аналогичных примеров в исходных кодах

 

kapger
да, действительно я двигался от обратного. Я в шаге Р двигался обратно логически, и, это работало. Попробую сейчас.
Наверное, да, запутался с терминами.

 

kapger
да, слушай, работает! Просто ещё раз прогнал с тем же ключом. ГОСТ действительно не прост! Как- то мимо ушей я пропустил, что шаг один и тот же для шифр/расшифр. Делал логически наоборот. Вопрос- после всего цикла 32-3, я меняю половинки местами для 32-Р ?
Пока до книжек не дойти- может завтра почитаю.

 

metcenger
Базовый цикл 32-З (или же З2-Р) - это 32 таких шага по очереди с 32 определенными ключами и, обязательно, в конце цикла 32-З (или же З2-Р) однократной заменой старшей и младшей части.

 

Вообще-то это свойство любой сети Файштеля, использующей для замешивания ветвей XOR.
Именно для этого после последнего раунда делается размен ветвей.

Более того, есть схемы абсолютно симметричных сетей Файштеля, когда даже не требуется
менять порядок ключей на инверсный (в них используется обязательно четное число раундов,
а раундовые ключи заранее ставятся в симметричном порядке : k0, k1, k2, ... , k2, k1, k0).

 

OLS
да, действительно здорово. Только, сколько ни читал про ГОСТ и сети Файстеля, нигде на этом явный акцент не сделан, а вот она фишка главная то!

kapger
все исправил у себя в проге, теперь основным шагом все и шифрую и расшифровываю. Толко вот что-
после 32-3, я меняю ниблы местами, расшифровываю, и, чтобы получить исходные данные, надо снова их поменять местами.

т.е. по идее, в конце цикла 32-3 их надо менять, и в конце цикла 32-Р.
А правильно если режим ECB использовать, то надо в конце 32-3 менять ниблы местами? это и будет шифр? или цикл 32-3 включает в себя перестановку? А цикл 32-Р тоже включает в себя перестановку?
т.е. для гаммы правильнее подавать уже переставленные местами?

Разобрался с тестовой последовательностью из книжки что там должно быть?
Гамму проверям?

 

metcenger
Я уже не раз пытался цитировать, что

Замена старшей и младшей части делается один раз в конце цикла как в 32-Р, так и в 32-З.

И для гаммы не нужно думать на предмет того - менять что-либо местами или нет... Если в теле шифрования в режиме гаммирования есть указание (а оно есть, и не раз) на то, что этот элемент нужно зашифровать как 32-З, то берем и шифруем этот элемент Вашей конкретной функцией шифрования (например, она у Вас называется fCrypt32_Z). А уже эта перестановка младшей и старшей частей будет сделана в самом цикле 32-З (в его конце), то есть внутри Вашей функции fCrypt32_Z (например).

 

Из книжки "Прикладная криптография. Использование и синтез криптографических интерфейсов" плохо получается...
Во-первых, просто отвратительное качество сканирования этой книжки! При поиске скачал штук 7 разных архивов с разных сайтов - в итоге имеем несколько раз один архив около 16 Мб, а другой - вполовину меньше. Тот, что побольше объемом - он и получше, но все-равно очень плохо! А в том, что поменьше, там распознанная таблица замен на странице 182 - это вообще шедевр! Ну да, ладно, что уж имеем... В том файле, что получше в таблице замен в нескольких местах невозможно понять - 0xe там или 0xc! Вот и ломаю голову. Пытался и так, и эдак... Не получается тот результат, который указан в книге. И это при том, что пытаюсь проверять вариант простой замены, который я и так ранее протестировал на примере из ГОСТ 34.11, то есть должно все работать...

Если есть у кого возможность отсканировать из этой книги с хорошим качеством страницы 181-191, то прошу помочь... Или может кто подскажет где лежит эта же книга качеством получше.

 

metcenger
А тест провели, который описан в сообщении №79 этой темы? Все совпало? Просто чтобы двигаться дальше в режим гаммирования нужно убедиться, что у нас шифруется одинаково... Если все совпало, то давайте будем пробовать вариант теста режима гаммирования, изложенный в сообщении №110. Ок?

 

Пробуем вариант теста режима гаммирования, изложенный в сообщении №110.
Исходные данные: ключ приведены в указанном сообщении, таблица замен - в сообщении №79.
Открытые данные ABCDEF0123456789FEDCBA9876543210
Синхропосылку выбираем для начала по варианту №1, поэтому синхропосылка в открытом виде 104BD8E832B1A503.
1. Шифруем синхропосылку по циклу 32-З с указанными ключевыми данными, результат равен FEFEFEFB4DA15E7C.
2. Вырабатываем ГАММУ №1 для шифрования первого блока открытых данных (примем для нашего тестового варианта - младшей части исходных данных, если не согласны, то давайте здесь возьмем старшую - надо обсудить!):
входное значение для генерации гаммы FEFEFEFB4DA15E7C
выходное значение полученной гаммы FFFFFFFF4EA25F7D
зашифрованное значение полученной гаммы, которое и используется для наложения гаммы на первые 64 бит открытых данных - гамма равна 9D9BA7C74D32B3A9
3. Накладываем гамму на первые 64 бит открытых данных:
Входное значение открытых данных FEDCBA9876543210
Входное значение гаммы 9D9BA7C74D32B3A9
Результат (XOR) шифрования младшей части открытых данных с гаммой №1 равен 63471D5F3B6681B9.
4. Вырабатываем ГАММУ №2 для шифрования второго блока открытых данных (соответственно, старшей части исходных данных):
входное значение для генерации гаммы FFFFFFFF4EA25F7D
выходное значение полученной гаммы 010101044FA3607E
зашифрованное значение полученной гаммы, которое и используется для наложения гаммы на вторые 64 бит открытых данных - гамма равна D4449DF19F77FF81
5. Накладываем гамму на вторые 64 бит открытых данных:
Входное значение открытых данных ABCDEF0123456789
Входное значение гаммы D4449DF19F77FF81
Результат (XOR) шифрования старшей части открытых данных с гаммой №2 равен 7F8972F0BC329808.
6. Собираем результаты (зашифрованные соответствующие старшая и младшие части открытых данных)
Итог 7F8972F0BC32980863471D5F3B6681B9


Не факт, что правильно... Давайте разбираться.

 

kapger
ну ты, блин, писатель
проверяю, позже сегодня отпишусь. Двигаться дальше надо, согласен. На самом деле большое спасибо тебе, что затеял проверку реализации, т.к. выловили у меня две глобальные ошибки.

 

kapger
Да, тест проверил, все 4 ответа совпали. При условии, что ключи я использовал с 7 до 0. И У меня теперь в конце 32-3 происходит перестановка нибблов местами.
проверяем гамму. таблицу может прежнюю оставим из сообщ. 79 ?

 

metcenger
А таблицу замен так и предлагается оставить - из сообщения №79. Та же таблица, которой мы проверяли четыре примера из ГОСТ 34.11