хэш код 512 бит гост

Об open-source реализациях хэш-функции ГОСТ Р 34.11-2012 и их влиянии на электронную подпись ГОСТ Р 34.10-2012

В свое время реализация отечественных криптографических алгоритмов в библиотеке libgcrypt очень меня вдохновила. Стало возможным задействовать эти алгоритмы и в Kleopatra и в Kmail и в GnuPg в целом, рассматривать библиотеку libgcrypt как алтернативу openssl с ГОСТ-ым engine. И все было замечательно до прошлой пятницы.

Меня попросили проверить электронную подпись ГОСТ Р 34.10-2012-256 для документа, созданного в Microsoft Office на MS Windows. И я ее решил проверить в Kleopatra (у меня стоит Linux). И что вы думаете, подпись оказалась неверной. Закрались сомнения. Решил проверить на openssl с ГОСТ-овым engine. Подпись успешно была проверена. Срочно переподписал файл в Kleopatra и он не прошел проверку на MS Windows. Попробовали другие файлы подписать и проверить, все было нормально. Встал вопрос в чем беда? Поскольку при подписании участвует хэш документа, было решено проверить вычисление хэш разными программами. Прежде всего были задействованы open-source реализации для stribog:

Как был прав ru_crypt, когда в начале своей статьи написал:

Сразу предупреждаю, что корректность реализаций не проверял.

Кстати, в самом стандарте на ГОСТ Р 34.10-2012 тоже написано, что контрольные примеры носят справочный характер. Надо четко понимать, что контрольные примеры не гарантирует, что разные реализации дают один и тот же результат на все случаи жизни.

Для вычисления хэш-значений использовались утилиты следующего вида:

4) Знаменитая реализация Дегтярева

Вот тоже интересная вещь: в латинской транскрипции стрибог пишут то stribog, то streebog. Неплохо бы прийти к единообразию. А так кажется, что это разные функции. Лично мне предпочтительней первый вариант – stribog.

Нужен был третейский судья, чтобы решить кто вычисляет хэш верно.

К тому же токен РУТОКЕН ЭЦП-2.0 широко распространен и многие на нем хранят сертификаты для доступа на Госуслуги и другие порталы.
Для вычисления значения хэша на токене воспользуемся скриптом test_digest.tcl на языке Tcl:

Когда проявляется это расхождение в реализации? Пока что удалось определить, что данное расхождение возникает при подсчете хэш doc-файлов, созданных в MS Office. Причем хэш от первых 143 байтов считается одинаково, а уже при подсчете хэш от 144 байтов значения получаются разные.

Первые 143 байта в шестнадцатиричном виде выглядят так:

Сохраним их в файле Doc1_143_hex.txt.

Первые 144 байта в шестнадцатиричном виде выглядят так:

Сохраним их в файле Doc1_144_hex.txt.

Для перевода из шестнадцатеричного вида в бинарный удобно воспользоваться скриптом hex2bin.tcl:

Преобразуем шестнадцатеричный код в бинарный:

Теперь можно проверить как вычисляется хэш различными реализациями:
Сначала посчитаем хэш для файла Doc1_143,bin:

Наступил самый важный момент, момент проверки на сертифицированном СКЗИ:

Как видим, все завершилось для файла Doc1_143.bin хорошо, все хэши совпали.

Посмотрим, что будет для файла Doc1_144.bin:

Всё, значения хэшей не совпадают. Для чистоты эксперимента проверим и оставшиеся реализации:

Хэш, подсчитанный «знаменитой реализацией Дегтярева» совпадает с хэшом, подсчитанным в openssl с ГОСТ-овым engine, но не совпадает со значением хэша, посчитанным с помощью libgcrypt и libressl.

Аналогичный результат мы получим, если будем считать хэш stribog512.

Источник

Хэш код 512 бит гост

КРИПТОГРАФИЧЕСКАЯ ЗАЩИТА ИНФОРМАЦИИ

Information technology. Cryptographic data security. Hash-function

Дата введения 2019-06-01

Предисловие

Цели, основные принципы и основной порядок проведения работ по межгосударственной стандартизации установлены в ГОСТ 1.0-2015 «Межгосударственная система стандартизации. Основные положения» и ГОСТ 1.2-2015 «Межгосударственная система стандартизации. Стандарты межгосударственные, правила и рекомендации по межгосударственной стандартизации. Правила разработки, принятия, обновления и отмены»

Сведения о стандарте

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 26 «Криптографическая защита информации»

3 ПРИНЯТ Межгосударственным советом по метрологии, стандартизации и сертификации (протокол от 29 ноября 2018 г. N 54)

За принятие проголосовали:

Краткое наименование страны
по МК (ИСО 3166) 004-97

Сокращенное наименование национального органа по стандартизации

Минэкономики Республики Армения

4 Приказом Федерального агентства по техническому регулированию и метрологии от 4 декабря 2018 г. N 1060-ст межгосударственный стандарт ГОСТ 34.11-2018 введен в действие в качестве национального стандарта Российской Федерации с 1 июня 2019 г.

5 Настоящий стандарт подготовлен на основе применения ГОСТ Р 34.11-2012

ВНЕСЕНА поправка, опубликованная в ИУС N 1, 2021 год

Поправка внесена изготовителем базы данных

Введение

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

Необходимость разработки настоящего стандарта вызвана потребностью в создании на межгосударственном уровне хэш-функции, соответствующей современным требованиям к криптографической стойкости и требованиям межгосударственного стандарта ГОСТ 34.10.

Настоящий стандарт терминологически и концептуально увязан с международным стандартом ИСО 2382* [1], а также международными стандартами серий ИСО/МЭК 9796 [2], [3], ИСО/МЭК 14888 [4]-[6] и ИСО/МЭК 10118 [7]-[10].

1 Область применения

Настоящий стандарт определяет алгоритм и процедуру вычисления хэш-функции для любой последовательности двоичных символов, которые применяются в криптографических методах обработки и защиты информации, в том числе для реализации процедур обеспечения целостности, аутентичности, электронной цифровой подписи (ЭЦП) при передаче, обработке и хранении информации в автоматизированных системах.

Определенная в настоящем стандарте функция хэширования используется при реализации систем электронной цифровой подписи на базе асимметричного криптографического алгоритма по ГОСТ 34.10.

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

2 Нормативные ссылки

В настоящем стандарте использована нормативная ссылка на следующий стандарт:

ГОСТ 34.10-2018 Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи

3 Термины, определения и обозначения

3.1 Термины и определения

В настоящем стандарте применены следующие термины с соответствующими определениями:

3.1.1 дополнение (padding): Приписывание дополнительных бит к строке бит.

3.1.2 инициализационный вектор (initializing value): Вектор, определенный как начальная точка работы функции хэширования.

3.1.3 сообщение (message): Строка бит произвольной конечной длины.

3.1.4 функция сжатия (round function): Итеративно используемая функция, преобразующая строку бит длиной и полученную на предыдущем шаге строку бит длиной в строку бит длиной .

1 Адаптировано из ИСО/МЭК 10118-1 [7].

2 В настоящем стандарте понятия «строка бит длиной L» и «двоичный вектор-строка размерности L» считаются тождественными.

3.1.5 хэш-код (hash-code): Строка бит, являющаяся выходным результатом хэш-функции.

3.1.6 хэш-функция (collision-resistant hash-function): Функция, отображающая строки бит в строки бит фиксированной длины и удовлетворяющая следующим свойствам:

1) по данному значению функции сложно вычислить исходные данные, отображаемые в это значение;

2) для заданных исходных данных сложно вычислить другие исходные данные, отображаемые в то же значение функции;

3) сложно вычислить какую-либо пару исходных данных, отображаемых в одно и то же значение.

1 Адаптировано из ИСО/МЭК 10118-1 [7].

2 В настоящем стандарте в целях сохранения терминологической преемственности по отношению к нормативным документам, действующим на территории государства, принявшего настоящий стандарт, и опубликованным ранее на русском языке научно-техническим изданиям установлено, что термины «хэш-функция», «криптографическая хэш-функция», «функция хэширования» и «криптографическая функция хэширования» являются синонимами.

3.1.7 [электронная цифровая] подпись (signature); ЭЦП: Строка бит, полученная в результате процесса формирования подписи.

1 Адаптировано из ИСО/МЭК 14888-1 [4].

2 В настоящем стандарте в целях сохранения терминологической преемственности по отношению к нормативным документам, действующим на территории государства, принявшего настоящий стандарт, и опубликованным ранее на русском языке научно-техническим изданиям установлено, что термины «электронная подпись», «цифровая подпись» и «электронная цифровая подпись» являются синонимами.

3.2 Обозначения

В настоящем стандарте применены следующие обозначения:

— операция покомпонентного сложения по модулю 2 двух двоичных векторов одинаковой размерности;

— конкатенация экземпляров вектора А;

— кольцо вычетов по модулю ;

— операция сложения в кольце ;

— биективное отображение, сопоставляющее элементу кольца его двоичное представление, т.е. для любого элемента z кольца представленного вычетом , где , j=0. n-1, выполнено равенство ;

Источник

Импортозамещенное шифрование глазами программиста. Хешируем по ГОСТ 34.11—2012

Содержание статьи

Славянский бог ветра Стрибог (сайт myfhology.info)

Xakep #210. Краткий экскурс в Ethereum

Хеш-функция «Стрибог» может иметь две реализации с результирующим значением длиной 256 или 512 бит. На вход функции подается сообщение, для которого необходимо вычислить хеш-сумму. Если длина сообщения больше 512 бит (или 64 байт), то оно делится на блоки по 512 бит, а оставшийся кусочек дополняется нулями с одной единичкой до 512 бит (или до 64 байт). Если длина сообщения меньше 512 бит, то оно сразу дополняется нулями с единичкой до полных 512 бит.

Немного теории

Основу хеш-функции «Стрибог» составляет функция сжатия (g-функция), построенная на блочном шифре, построенном с помощью конструкции Миягучи — Пренеля, признанной одной из наиболее стойких.

Блочный шифр в режиме Миягучи — Пренеля. Здесь m — очередной блок исходного сообщения, h — значение предыдущей функции сжатия

В целом хеширование производится в три этапа. Первый этап — инициализация всех нужных параметров, второй этап представляет собой так называемую итерационную конструкцию Меркла — Дамгорда с процедурой МД-усиления, третий этап — завершающее преобразование: функция сжатия применяется к сумме всех блоков сообщения и дополнительно хешируется длина сообщения и его контрольная сумма.

Общая схема вычисления хеш-суммы по ГОСТ 34.11—2012

WARNING

Итак, после краткого и небольшого погружения в теорию начинаем кодить.

Базовые функции стандарта

Поскольку при вычислении хеша мы имеем дело с 64-байтовыми блоками (в стандарте они представлены 512-разрядными двоичными векторами), для начала определим этот самый двоичный вектор:

Сложение двух двоичных векторов по модулю 2

Здесь все предельно просто. Каждый байт первого вектора ксорится с соответствующим байтом второго вектора, и результат пишется в третий (выходной) вектор:

Побитовое исключающее ИЛИ над 512-битными блоками

В тексте ГОСТа название данной операции звучит как сложение в кольце вычетов по модулю 2 в степени n. Такая фраза кого угодно может вогнать в уныние, но на самом деле ничего сложного и страшного в ней нет. Два исходных 64-байтовых вектора представляются как два больших числа, далее они складываются, и переполнение, если оно появляется, отбрасывается:

Нелинейное биективное преобразование (преобразование S)

При биективном отображении каждому элементу одного множества соответствует ровно один элемент другого множества (более подробно про биекцию можешь почитать в Википедии). То есть это просто банальная подстановка байтов в исходном векторе по определенному правилу. В данном случае правило задается массивом из 256 значений:

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

Итак, если в исходном векторе у нас встречается какой-либо байт со значением, например, 23 (в десятичном выражении), то вместо него мы пишем байт из массива Pi, имеющий порядковый номер 23, и так далее. В общем, код функции преобразования S получается такой:

Перестановка байтов (преобразование P)

Преобразование P — простая перестановка байтов в исходном массиве в соответствии с правилом, определяемым массивом Tau размером в 64 байта:

Здесь, так же как и в предыдущем случае, для экономии места показаны не все значения массива Tau.

Перестановка выполняется следующим образом: сначала идет нулевой элемент исходного вектора, далее — восьмой, потом — шестнадцатый и так далее до последнего элемента. Код функции напишем так:

Линейное преобразование (преобразование L)

Это преобразование носит название «умножение справа на матрицу A над полем Галуа GF(2)» и по сравнению с первыми двумя будет немного посложнее (по крайней мере, вкурить всю суть от и до с первого прочтения стандарта удается далеко не всем). Итак, есть матрица линейного преобразования A, состоящая из 64 восьмибайтовых чисел (здесь приведена не в полном объеме):

Исходный вектор делится на порции размером по 8 байт, каждая из этих порций интерпретируется в виде 64-разрядного двоичного представления. Далее берется очередная порция, каждому биту из этой порции ставится в соответствие строка из матрицы A. Если очередной бит равен нулю, то соответствующая ему строка из матрицы A вычеркивается; если очередной бит равен единице, то соответствующая ему строка из матрицы A остается. После всего этого оставшиеся строки из матрицы линейного преобразования ксорятся, и получившееся число записывается в виде очередной восьмибайтовой порции в результирующий вектор. Код выглядит следующим образом:

Схема линейного преобразования L

Пишем все остальное

Имея в наличии все необходимые базовые преобразования, определенные стандартом, можно приступить непосредственно к реализации алгоритма «Стрибог» в целом.

Для начала определим структуру, в которую будем складывать все исходные, промежуточные и конечные результаты вычислений:

Для этой функции необходимо описать итерационные константы, которых, как мы уже говорили, двенадцать штук (для краткости здесь эти константы показаны не в полном объеме):

Если ты попытаешься сравнить приведенные выше константы с текстом стандарта, то увидишь, что эти самые константы записаны «задом наперед». Дело в том, что все байтовые массивы (в том числе и строки тестовых примеров) в тексте стандарта описаны таким образом, что нулевой их элемент находится в конце массива, а не в начале, как мы привыкли, поэтому строки перед использованием надо «переворачивать».

Далее пишем саму функцию преобразования E:

И, используя эти функции, пишем самую главную функцию алгоритма «Стрибог» — функцию сжатия g:

Схема функции сжатия g

В самом начале мы говорили, что хеширование выполняется блоками по 64 байта, а последний блок, если он меньше 64 байт, дополняется нулями с одной единичкой. Для этой операции вполне подойдет функция GOSTHashPadding :

Теперь открываем руководящий документ на шестой странице и внимательно разбираемся с этапами вычисления столь нужной нам хеш-функции.

Первый этап (инициализация)

Как ясно из названия, этот этап необходим для первоначального задания значений всех переменных:

Второй этап

На этом этапе мы хешируем отдельные блоки размером в 512 бит (или 64 байта) до тех пор, пока они не кончатся. Этап состоит из функции сжатия и двух операций исключающего ИЛИ (с их помощью формируется контрольная сумма):

Третий этап

На третьем этапе мы хешируем остаток, который не попал в очередной 64-байтный блок из-за того, что его размер меньше. Далее формируем контрольную сумму всего сообщения с учетом его длины и вычисляем окончательный результат. Выглядит это все так:

Разобравшись со всеми этапами, сложим все в единое целое. Весь процесс будет описан в трех функциях:

Функция GOSTHashUpdate

Объявим эту функцию таким образом:

Как уже неоднократно говорилось, хеширование производится блоками по 64 байта, поэтому в начале функции напишем следующее:

Поскольку при чтении файла мы его будем читать по кусочкам, длина которых задается при использовании функции fread, то при слишком длинном файле мы можем потерять остаток файла и, соответственно, неправильно посчитать хеш-сумму. Чтобы этого избежать, необходимо в нашу функцию GOSTHashUpdate добавить следующий код:

Функция GOSTHashFinal

Считаем хеш-сумму файла

Вот мы и подошли к завершающему этапу написания кода, позволяющего посчитать хеш-сумму по алгоритму «Стрибог». Осталось считать нужный файл в заранее отведенный участок памяти и поочередно вызвать функции GOSTHashUpdate и GOSTHashFinal :

После завершения в зависимости от нужной нам длины хеш-суммы берем значение CTX->hash полностью (длина хеша 512 бит) либо берем от CTX->hash последние 32 байта.

Не забудь про исходники

Весь код: классическую реализацию алгоритма (в полном соответствии с ГОСТом), усовершенствованную реализацию (с предварительным расчетом значений преобразований S и L), а также код предварительного расчета значений преобразований S и L — ты найдешь в приложении к этому номеру.

Заключение

Наверняка у тебя промелькнула мысль о ресурсоемкости данного алгоритма и возможных способах увеличения быстродействия. Очевидные приемы типа применения выравнивания при описании всех используемых структур, переменных и участков памяти, скорее всего, ощутимого эффекта не дадут, но в этом алгоритме есть возможность заранее посчитать некоторые значения и использовать при написании кода в дальнейшем именно их.

Если внимательно почитать стандарт (особенно страницы 3 и 4), то выяснится, что преобразования S и L можно выполнить заранее и сформировать восемь массивов по 256 восьмибайтовых чисел, в которых будут содержаться все возможные значения этих двух преобразований. Помимо этого, при вычислении хеш-суммы с использованием заранее рассчитанных значений можно сразу сделать и нужные перестановки в соответствии с преобразованием P. В общем, весь нужный код (вычисление хеша классическим алгоритмом, предварительный расчет значений преобразований S и L и вычисление хеша с помощью заранее просчитанных значений) найдешь в приложении к этой статье. Бери, разбирайся, пользуйся.

Источник

Стрибог (хеш-функция)

Из Википедии — свободной энциклопедии

«Стрибог» (англ. STREEBOG [1] ) — криптографический алгоритм вычисления хеш-функции с размером блока входных данных 512 бит и размером хеш-кода 256 или 512 бит.

Описывается в ГОСТ 34.11-2018 «Информационная технология. Криптографическая защита информации. Функция хэширования» — действующем межгосударственном криптографическом стандарте.

Стандарт ГОСТ Р 34.11-2012 разработан и введён в качестве замены устаревшему стандарту ГОСТ Р 34.11-94:

Необходимость разработки вызвана потребностью в создании хеш-функции, соответствующей современным требованиям к криптографической стойкости и требованиям стандарта ГОСТ Р 34.10-2012 на электронную цифровую подпись.

Название хеш-функции — «Стрибог», по имени славянского божества, — часто используется вместо официального названия стандарта, хотя в его тексте явно не упоминается (см. ниже).

Источник

Стрибог (хеш-функция)

Из Википедии — свободной энциклопедии

«Стрибог» (англ. STREEBOG [1] ) — криптографический алгоритм вычисления хеш-функции с размером блока входных данных 512 бит и размером хеш-кода 256 или 512 бит.

Описывается в ГОСТ 34.11-2018 «Информационная технология. Криптографическая защита информации. Функция хэширования» — действующем межгосударственном криптографическом стандарте.

Стандарт ГОСТ Р 34.11-2012 разработан и введён в качестве замены устаревшему стандарту ГОСТ Р 34.11-94:

Необходимость разработки вызвана потребностью в создании хеш-функции, соответствующей современным требованиям к криптографической стойкости и требованиям стандарта ГОСТ Р 34.10-2012 на электронную цифровую подпись.

Название хеш-функции — «Стрибог», по имени славянского божества, — часто используется вместо официального названия стандарта, хотя в его тексте явно не упоминается (см. ниже).

Источник