Друзья! Вот статья. https://wasm.in/blogs/algoritm-shifrovanija-gost-28147-89-metod-prostoj-zameny.359/ А вот, собственно, ошибка в ней: Возьмем блок информации N = 0102030405060708h, здесь части L и R равны: L = 01020304h, R =05060708h Дальше идёт работа с двумя блоками L = 01020304h, R =05060708hНо это неправильно ведь! Читаем стандарт: Открытые данные, подлежащие зашифрованию, разбивают на блоки по 64 бита в каждом. Ввод любого блока T0 = (a1(0), a2(0), ..., a31(0), a32(0), b1(0), b2(0), ..., b31(0), b32(0)) двоичной информации в накопители N1 и N2 производится так, что значение a1(0) вводится в 1-ый разряд N1, значение a2(0) вводится во второй разряд N1 и т. д., значение a32(0) вводится в 32-й разряд N1; значение b1(0) вводится в 1-й разряд N2, значение b2(0) вводится во 2-й разряд N2 и т. д., значение b32(0) вводится в 32-1 разряд N2. В результате получают состояние (a32(0), a31(0), ... , a2(0), a1(0)) накопителя N1 и состояние (b32(0), b31(0), ... , b2(0), b1(0)) накопителя N2 На практике это означает вот что. Число 0102030405060708h суть 0000000100000010000000110000010000000101000001100000011100001000b И вот если мы все эти ноли и единицы перевернём, как сказано в стандарте, то получим такое число: 10E060A020C04080h И именно с этим числом и нужно работать в дальнейшем! То есть разбивать его на две части, левую и правую 10E060A0h 20C04080h И с ними и работать. Почему так не делается, ума не приложу. Ведь в дальнейшем мы складываем правую часть с ключевым элементом (который тоже преобразовывается с такой же ошибкой), а потом обращаемся к таблице замен. И вот там-то мы совсем неправильно всё заменяем! Может мне кто-нибудь разъяснить этот момент? Спасибо, кто откликнется.
Ну вот я жирным шрифтом и выделил, там именно это и сказано. . было (a1(0), a2(0), ..., a31(0), a32(0), стало (a32(0), a31(0), ... , a2(0), a1(0)) Жду уточняющих вопросов в стиле "где там такое сказано?", давно что-то их не было.
amvoz, Это обычное словоблудие. Под данными они имеют в виду qword, в котором биты нумеруются справа налево, а под "накопителем" - массив с привычной нумерацией элементов слева направо. На уровне машинных инструкций это просто: Код (ASM): mov eax, [esi] mov ebx, [esi+4]
В Википедии как то вообще по другому(и открытый текст и ключ разбиваются на блоки, потом генерится подключ и т.д.) https://ru.wikipedia.org/wiki/ГОСТ_28147-89
rmn, я вот не понимаю, но ведь какое-то должно быть объяснение кроме простого словоблудия! Ведь схематично если стандарт выглядит так: берём сообщение A и преобразовываем его, преобразовываем, преобразовываем, потом ещё преобразовываем... Потом получаем сообщение B. Оно исходное и с ним и работаем. И это вот понял и автор статьи, которую мы обсуждаем, и в википедии поняли и ещё автор вот этой вот проги тоже понял (разархивировать и проверить на вирусы), и авторы прилагающегося документа тоже поняли. И Винокуров тоже понял. Только я один не понял. Но для чего вот эти вот предварительные преобразования, чтобы получить исходное сообщение? (Даже сама фраза режет слух- исходное сообщение не получается преобразованием, оно на то и исходное)
В этой стране техническая документация должна быть объемной и звучать "научно", чтобы высокое начальство видело, за что программисту платят такие "огромные" деньжищи. Даже самые элементарные определения и понятия заменяются многоэтажными мозговыносящими словесными конструкциями. Если что-то не понятно, бери сорцы openssl или другой криптолибы и смотри работу нужного алгоритма на лаконичной сишечке
я там не нашёл, что байты переворачиваются с конца на начало. Плюс этого же не нашёл в обсуждаемой статье. Плюс НИГДЕ не нашёл, кроме как в стандарте. Противоречие стандарту! Но не буду же я в вопросе ссылаться на реализацию какого-нибудь Васи Пупкина, типа почему Вася Пупкин в своём сишном коде не переворачивает байты с конца на начало? Даже если был бы код какой-нибудь солидной проги (openssl?) вопрос-то всё равно бы остался- противоречие стандарту. Хорошо хоть на этом форуме нашлась соотвествующая статья! Типа можно спросить и на местную статью сослаться.
В стандарте этого тоже нет. Просто там используются разные формы представления для данных и накопителей, с различным порядком следования элементов. В реальности же, когда в качестве накопителей используются регистры или переменные в памяти (вместо массивов), никакого изменения в порядке бит не происходит, просто копируем из одного в другое как есть.
amvoz, Еще раз: переворот есть только из-за разных представлений объектов. Один объект - битмап, где нумерация битов справа налево, а другой - массив, где нумерация элементов слева направо. В реальности никакого массива нет, а в качестве накопителя используется такой же битмап, с таким же порядком следования бит, поэтому никакого переворота нет, а есть просто прямое копирование.
rmn, правильно ли я понял, что: Вот допустим, был у меня порядок бит такой (То, что в стандарте называется T0): a0, a1...a28, a29, a30,a31Я его перевернул (я ведь реализую стандарт, а значит, следую писанному) так: чтобы было как в стандарте (В стандарте это называется N): a31, a30, a29, a28...,a1, a0То же самое проделал c ключевым элементом (В стандарте это называется X): w31, w30, w29, w28...,w1, w0Потом сложил ключевой элемент W и N по модулю 32 (фактически XOR), получаю: k31, k30, k29, k28...,k1, k0++++++++++++++++++++++++++++++++++++++++++++++++++++ Вот до сей поры вопросов не было. Ну пусть байты расположены как угодно, всегда ведь можно прочесть их как удобно, то есть справа налево! Но вот дальше пошло интересно. Нужно разбить получившийся массив на 4-хбитовые массивы и обратиться к таблице замен. А это операция не обратимая. Вот где тут брать ключевые элементы? Правильно ли я понимаю, что они такие (То есть читаем справа налево): k0, k1, k2, k3, ... k28, k29, k30, k31? ++++++++++++++++++++++++++++++++++++++++++++++++++++ Я вообще не так искал столбцы в таблице замен, я брал слева направо, то есть если k31, k30, k29, k28 было равно 1101, то я искал D, а надо было (?) B ++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++