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

metcenger
После 8-го прохода: CB2CCCA1EF638967
После 16-го прохода: 0409014DFE8B0F53
После 24-го прохода: 75335B61850D4E23
После 32-го прохода: 1CE5E699E9E99D39
Замена младшей и старшей части: E9E99D391CE5E699

 

metcenger
Пишу для микропроцессора Neuron Chip 3150 и/или 3120, применяемого в промышленных сетях LON (общее название Fieldbus), соответственно используется язык Neuron C (Си-подобный) со своим специфичным компилятором и прошивальщиком. Причем все это добро 16-разрядное... Ну и ничего, изгаляюсь вычислениями 32-битных чисел в 16-разрядной реализации

 

OLS

То есть мы сформировали гамму №1 из 64 бит и ждем биты данных, поступающие на вход и шифруем их (образно говоря) по мере поступления каждого бита, пока их количество не перевалит за 64, после чего формируем новую гамму и т.д.? А слева направо означает со старших бит к младшим? То есть шифруются сначала, при их наличии, впередистоящие (впередиидущие) старшие нулевые биты?

По поводу соответствия бит: для шифрования младшего бита данных используется младший бит гаммы и, соответственно, для старшего - старший? Так?

 

Большая просьба к участникам - сильно ногами не пинать за откровенное непонимание некоторых понятий и т.д. Хотя в математике когда-то хорошо разбирался, да и сейчас потихоньку разбираюсь
Программистом я был давно (Паскаль, VB, Perl), а на Си и, тем более asm'е, вообще никогда не писал. Данная работа входит составной частью в мою будущую кандидатскую диссертацию.

 

OLS
Большая к Вам просьба: каким примером лучше всего воспользоваться, чтобы проверить свою реализацию ГОСТ при шифровании в режиме гаммирования без обратной связи? Ваша подсказка по проверке режима простой замены была просто идеальная!

 

kapger
сходятся первые три преобразования. 3*8
последнее четвертое дает др. результат.
я его делаю так

for(i = 8; i > 0; i--) {
dataR = code (data1, k);
dataL = data1;
data0 = dataL;
data1 = dataR;
}

там ключ наоборот идет от К[7] до К[0]

может я не правильно задал цикл for ?
Мне кажется, что все норм.

 

именно так

это зависит от реализации - если Вы хотите совместимости с какой-то уже существующей версией, написанной не Вами - ищите как сделано у них

Применительно к гамме субъективно я не привык использовать термины "старший-младший" : гамма - это потенциально бесконечная последовательность бит, порождаемая криптостойким ГПСЧ. У нее есть "предыдущие" и "последующие" биты.

Когда входной поток - суть битовый - например, по последовательному порту, вопросов как Вы понимаете не возникает. А вот когда входной поток - файл, т.е. блочный, не важно с каким размером блока, появляется проблема - откуда начинать брать биты для поочередной подачи их в скремблер - со старших бит или с младших. Это вопрос реализации.

Уважаю. Какой ВУЗ ? (я защищался в 2004-м по 05.13.19)

Если бы что-то навскидку вспомнил, то ответил бы еще на первую Вашу просьбу.

 

metcenger
Давай последний блок проверим по каждому шагу:
Входное значение на шаг 25 равно 75335B61850D4E23
Шаг 25, ключ 7 = ACDDFDC4, результат = 850D4E2371431EA3
Шаг 26, ключ 6 = A179C1AB, результат = 71431EA30C1632EB
Шаг 27, ключ 5 = 2255452B, результат = 0C1632EB749AA38D
Шаг 28, ключ 4 = F5A68268, результат = 749AA38D3F5685E6
Шаг 29, ключ 3 = FE3087A3, результат = 3F5685E6169FF62A
Шаг 30, ключ 2 = 8E9A6321, результат = 169FF62AC3B5E482
Шаг 31, ключ 1 = DB56279F, результат = C3B5E4821CE5E699
Шаг 32, ключ 0 = 931A21D5, результат = 1CE5E699E9E99D39
Замена младшей и старшей части: E9E99D391CE5E699

 

Вы уверены что в Вашем цикле счетчик не идет
как 8, 7, 6, 5, 4, 3, 2, 1
вместо 7, 6, 5, 4, 3, 2, 1, 0
?

 

Попробую предложить свой вариант для обсуждения и проверки собственной реализации шифрования в режиме гаммирования без обратной связи. Сразу скажу, что в своей реализации данного режима я абсолютно не уверен, поэтому разбираться будем вместе!

Итак, таблица замен берется из сообщения №79 данной темы. Ключ шифрования используем один из тех, что описаны в этом же сообщении №79, а именно:
K1=0x733D2C20 65686573 74746769 79676120 626E7373 20657369 326C6568 33206D54
(порядок расположения элементов в ключе: k7, k6, ... ,k0)
Шифровать будем 128-битное значение, равное 0xABCDEF0123456789FEDCBA9876543210 с тремя вариантами синхропосылок.
Начальное значение генератора гаммы (синхропосылка), варианты (по очереди, естественно, чтобы в итоге получить три различных зашифрованных ответа):
1 вариант: синхропосылка 0x104BD8E832B1A503
2 вариант: синхропосылка 0x3C934975C61C34AD
3 вариант: синхропосылка 0x2566CB8DF34836FC
Такие значения синхропосылок были выбраны специально для того, чтобы при шифровании их указанным ключом и с указанной таблицей замен получить шифрованные значения синхропосылок (по вариантам):
0xFEFEFEFB4DA15E7C
0xFEFEFEFC4DA15E7C
0xFEFEFEFD4DA15E7C
Здесь наиболее важна левая часть шифрованной синхропосылки (по вариантам):
0xFEFEFEFB
0xFEFEFEFC
0xFEFEFEFD
А важна она тем, что позволяет проверить правильность сложения по модулю 2^32-1, особенно в случае с 0xFEFEFEFC
Правая часть шифрованной синхропосылки взята с потолка, она не так важна для проверки.

У кого что в итоге получилось?

 

OLS
Спасибо! Буду думать и размышлять

ВУЗ - ПГТУ (Пермь), 05.13.06

 

На сегодня хватит... Завтра продолжим?

 

kapger
ОК до завтра

 

да, ошибся я в последнем цикле. надо было так делать
for(i = 8; i > 0; i--) {
dataR = code (data1, k[i-1]); ...

Хотя, когда расшифровываю обратно, так и делаю. Опечатался, хотя данные расшифровываются. странно.

Ещё вопрос- после последнего 32-го преобразования, зачем ниблы местами менять? разве это надо. т.е. старшую и младшую части.

 

очень странно, но изначально в моем варианте- я ведь скопировал то, над чем сейчас упражняюсь- была строчка
dataR = code (data1, k[i-1]);
потом эта 1 куда- то исчезла ??? Может по запаре стер. В общем, вопрос отпал.

 

что- то я засел с расшифровкой обратно к изначальному виду.
ведь в базовом 32-3 у нас последняя строчка

//XOR c data0
dataR = Srol ^ data0;

т.е. ХОR нашей измененной правой части с левой, пока что не измененной.

а дальше- не понятно при расшифровке. по идее, имея зашифр. значение, у меня dataR, зная левую часть, у меня data0, получаем наше Srol, и едем дальше. Но, где я теперь возьму data0? Раньше мог- без проблем, а теперь там правая часть. ???
В общем, или вечер уже, или я в тупике....

 

metcenger
Мне кажется, что ноги у тупика растут как раз потому, что после последнего 32-го преобразования нужно было местами менять старшую и младшую части...

 

kapger
это описано в стандарте?
хорошо, я только один раз шифранул, у меня результат
2B2B2B2B 4B1E16B2

как мне его расшифровать? т.е. как сделать обратное операции
//XOR c data0
dataR = Srol ^ data0;

???

 

metcenger
да, описано в стандарте.

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

 

Почитал все предыдущие топики. Улыбнуло.
Однако сложно, как мне кажется, сделать правильную реализацию, не имея хотя бы правильных тестовых данных. За скобки можно, конечно условно, вынести режим блочной замены, где в качестве тестовых данных можно использовать данные из ГОСТ Р 34.11-94. Но добиться однозначной реализации режима гаммирования врядли удастся. Всё таки автор (авторство вроде принадлежит КГБ СССР) оставил за собой право решать какая реализация является единственно верной.
А любителям поломать голову могу посоветовать примеры приведенные в главе 5 книги "Прикладная криптография. Использование и синтез криптографических интерфейсов" авторы А.Щербаков и А.Домашев. В сети эта книга есть.