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

Национальный стандарт РФ ГОСТ Р 34.11-2012 «Информационная технология. Криптографическая защита информации. Функция хэширования» (утв. приказом Федерального агентства по техническому регулированию и метрологии от 7 августа 2012 г. N 216-ст)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[ИСО/МЭК 10118-1, статья 3.9]

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

[ИСО/МЭК 10118-1, статья 3.7]

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

[ИСО/МЭК 14888-1, статья 3.10]

[ИСО/МЭК 10118-1, статья 3.10]

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

[ИСО/МЭК 14888-1, статья 3.6]

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

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

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

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

[ИСО/МЭК 14888-1, статьи 3.2, 3.7]

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

[ИСО/МЭК 14888-1, статья 3.12]

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

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

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

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

операция присваивания переменной а значения b;

произведение отображений, при котором отображение действует первым;

функция хэширования, отображающая вектор (сообщение) М в вектор (хэш-код) Н(М);

Настоящий стандарт определяет две функции хэширования с длинами хэш-кода n = 512 бит и n = 256 бит.

5 Значения параметров

5.1 Инициализационные векторы

5.2 Нелинейное биективное преобразование множества двоичных векторов

Нелинейное биективное преобразование множества двоичных векторов задается подстановкой

Значения подстановки записаны ниже в виде массива :

= (252, 238, 221, 17, 207, 110, 49, 22, 251, 196, 250, 218, 35, 197, 4, 77, 233, 119, 240, 219, 147, 46, 153, 186, 23, 54, 241, 187, 20, 205, 95, 193, 249, 24, 101, 90, 226, 92, 239, 33, 129, 28, 60, 66, 139, 1, 142, 79, 5, 132, 2, 174, 227, 106, 143, 160, 6, 11, 237, 152, 127, 212, 211, 31, 235, 52, 44, 81, 234, 200, 72, 171, 242, 42, 104, 162, 253, 58, 206, 204, 181, 112, 14, 86, 8, 12, 118, 18, 191, 114, 19, 71, 156, 183, 93, 135, 21, 161, 150, 41, 16, 123, 154, 199, 243, 145, 120, 111, 157, 158, 178, 177, 50, 117, 25, 61, 255, 53, 138, 126, 109, 84, 198, 128, 195, 189, 13, 87, 223, 245, 36, 169, 62, 168, 67, 201, 215, 121, 214, 246, 124, 34, 185, 3, 224, 15, 236, 222, 122, 148, 176, 188, 220, 232, 40, 80, 78, 51, 10, 74, 167, 151, 96, 115, 30, 0, 98, 68, 26, 184, 56, 130, 100, 159, 38, 65, 173, 69, 70, 146, 39, 94, 85, 47, 140, 163, 165, 125, 105, 213, 149, 59, 7, 88, 179, 64, 134, 172, 29, 247, 48, 55, 107, 228, 136, 217, 231, 137, 225, 27, 131, 73, 76, 63, 248, 254, 141, 83, 170, 144, 202, 216, 133, 97, 32, 113, 103, 164, 45, 43, 9, 91, 203, 155, 37, 208, 190, 229, 108, 82, 89, 166, 116, 210, 230, 244, 180, 192, 209, 102, 175, 194, 57, 75, 99, 182).

5.3 Перестановка байт

= (0, 8, 16, 24, 32, 40, 48, 56, 1, 9, 17, 25, 33, 41, 49, 57, 2, 10, 18, 26, 34, 42, 50, 58, 3, 11, 19, 27, 35, 43, 51, 59, 4, 12, 20, 28, 36, 44, 52, 60, 5, 13, 21, 29, 37, 45, 53, 61, 6, 14, 22, 30, 38, 46, 54, 62, 7, 15, 23, 31, 39, 47, 55, 63).

5.4 Линейное преобразование множества двоичных векторов

Источник

Информационная безопасность и защита информации (архив ИПМ бакалавры 2010-2021г, Богомолов)

4 Лекция. Контроль целостности данных. Хеш-функции. Имитовставка. ЭЦП

Контроль целостности данных.

Методы контроля целостности данных:

Полная копия данных.

Создаются полные копии данных и потом сверяются.

Рис. Контроль целостности с помощью полной копии данных

Контрольная сумма.

Рис. Контроль целостности с помощью контрольной суммы

Примеры контрольных сумм: CRC8, CRC16, CRC32

исходный текст: Контроль целостности данных

crc32 (длина 32 бита)

Рис. Основная задача хеш функций

Вычисляют хеш шифрованием данных блочным алгоритмом в режимах CBC, но со стандартным (известным) ключом. Хешем является последний шифрованный блок.

ГОСТ Р 34.11-94

Рис. Вычисление хеш по ГОСТ Р 34.11-94 (сравните с CBC)

h — значение хеш-функции сообщения M

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

исходный текст: Контроль целостности данных

sha1 (длина 160 бит)

sha224 (длина 224 бит)

sha256 (длина 256 бит)

sha384 (длина 384 бит)

sha512 (длина 512 бит)

ГОСТ Р 34.11-94 (длина 256 бит)

Имитовставка (MAC, message authentication code — код аутентичности сообщения)

Вычисляют имитовставку шифрованием данных блочным алгоритмом в режимах CBC. Имитовставкой является последний шифрованный блок.

Рис. Вычисление имитовставки

Имитовставка по ГОСТ 28147-89

Длина имитовставки от 1 до 32 бит.

Открытый текст T_O разбивается на блоки длиной 64 бита. Последний блок в случае необходимости дополняется нулями.

Первый блок шифруется, что и сообщение, но с применением 16 циклов вместо 32. Результат по битам по модулю 2 складывается с вторым блоком и так же шифруется. Результат складывается с третьим блоком. и так далее.

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

Рис. Проблема имитовставки

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

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

Рис. Создание и проверка ЭЦП

Источник

Импортозамещение в I2P: подпись по ГОСТ Р 34.10-2012

Типы подписей в I2P

В настоящий момент в I2P существует 9 типов подписей, где указывается тип подписи, затем тип хэша и, если необходимо, кривая или ее набор параметров.

Для ГОСТ-а нам, по моей просьбе, выделено два типа:
9 — GOSTR3410_GOSTR3411_256_CRYPTO_PRO_A
10 — GOSTR3410_GOSTR3411_512_TC26_A
для 256 и 512-битных ключей соответственно.

Длина публичного ключа для 9 составляет 64 байта (по 32 байта на каждую координату точки) и 128 байт для 10.

Реализация подписи ГОСТ Р 34.10

Предполагается, что подписывается и проверяется хэш длиной 256 или 512 бит. Подробно и с примерами описан здесь.

Используется обычная эллиптическая кривая, поэтому для работы с ней могут использоваться функции из криптографической библиотеки. В частности это EC_GROUP_* и EC_POINT_* из openssl, главная из которых это:

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

Для кривой задаются 6 параметров: p — модуль, a и b — коэффициенты уравнения кривой, P(x,y) — базовая точка, q — простое число, умножение на которое базовой точки дает нуль.

p и q должны быть большими и близкими к максимальным, поскольку p ограничивает диапазон всех чисел, а q — диапазон секретных ключей. Базовая точка и q вычисляются одновременно.
Как правило используются общеизвестные и хорошо протестированные наборы параметров.

В нашей реализации мы будем использовать 2 набора параметров:

Для подписи (r,s) выбирается случайное число k, и вычисляется точка R=k*P, координата x которой становится компонентой r подписи. Компонента s = r*d + h*k, где d — секретный ключ, h — хэш подписи сообщения в Big Endian.

Для проверки подписи умножим обе части равенства на базовую точку P.

Хэш функция ГОСТ Р 34.11-2012(стрибог)

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

Подробное описание и примеры. Отметим основные моменты:

Подпись внешним криптопровайдером по протоколу I2CP

Если адрес подключается к маршрутизатору по протоколу I2CP, то знание секретного ключа подписи маршрутизатором не требуется.

Вместо этого маршрутизатор отправляет сообщение RequestLeaseSetMessage (или RequestVariableLeaseSetMessage), ожидая в ответ сообщение CreateLeaseSetMessage, содержащее LeaseSet, подписанный секретным ключом адреса. Как можно заметить из описания протокола, в старых версиях I2P требовалось передавать этот ключ в сообщении, больше этого не требуется.
Таким образом, приложение, реализующее I2P адрес, может использовать для подписи API одного из существующих криптопровайдеров с ГОСТ, позволяя эффективно встроить I2P решение в существующую инфраструктуру.

Источник

ГОСТ Р 34.11-2012 Информационная технология. Криптографическая защита информации. Функция хэширования

ФЕДЕРАЛЬНОЕ АГЕНТСТВО
ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

НАЦИОНАЛЬНЫЙ
СТАНДАРТ
РОССИЙСКОЙ
ФЕДЕРАЦИИ

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

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

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

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 7 августа 2012 г. № 216-ст

4 ВЗАМЕН ГОСТ Р 34.11-94

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

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

Приложение A (справочное) Контрольные примеры.

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

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

Information technology. Cryptographic data security. Hash-function

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

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

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

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

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

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

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

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

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

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

заполнение (padding): Приписывание дополнительных бит к строке бит.
[ИСО/МЭК 10118-1, статья 3.9]

инициализационный вектор (initializing value): Вектор, определенный как начальная точка работы функции хэширования.
[ИСО/МЭК 10118-1, статья 3.7]

сообщение (message): Строка бит произвольной конечной длины.
[ИСО/МЭК 14888-1, статья 3.10]

функция сжатия (round-function): Итеративно используемая функция, преобразующая строку бит длиной L₁ и полученную на предыдущем шаге строку бит длиной L₂ в строку бит длиной L₂.
[ИСО/МЭК 10118-1, статья 3.10]

хэш-код (hash-code): Строка бит, являющаяся выходным результатом хэш-функции.
[ИСО/МЭК 14888-1, статья 3.6]

хэш-функция (collision-resistant hash-function): Функция, отображающая строки бит в строки бит фиксированной длины и удовлетворяющая следующим свойствам:
1) по данному значению функции сложно вычислить исходные данные, отображаемые в это значение;
2) для заданных исходных данных сложно вычислить другие исходные данные, отображаемые в то же значение функции;
3) сложно вычислить какую-либо пару исходных данных, отображаемых в одно и то же значение.
[ИСО/МЭК 14888-1, статьи 3.2, 3.7]

электронная цифровая подпись (signature); ЭЦП: Строка бит, полученная в результате процесса формирования подписи.
[ИСО/МЭК 14888-1, статья 3.12]

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

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

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

конкатенация векторов А, В V*, т. е. вектор из V_|A|+|B|, в котором левый подвектор из V_|A| совпадает с вектором А, а правый подвектор из V_|B| совпадает с вектором В;

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

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

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

отображение, обратное отображению , т. е. = ;

отображение, ставящее в соответствие вектору , , вектор

операция присваивания переменной а значения b;

произведение отображений, при котором отображение действует первым;

двоичный вектор, подлежащий хэшированию, М V*, |М| 512 ;

функция хэширования, отображающая вектор (сообщение) М в вектор (хэш-код) Н(М);

инициализационный вектор функции хэширования, IV V₅₁₂.

4 Общие положения

Настоящий стандарт определяет две функции хэширования Н: V* V_n с длинами хэш-кода п = 512 бит и п = 256 бит.

5 Значения параметров

5.1 Инициализационные векторы

5.2 Нелинейное биективное преобразование множества двоичных векторов

Нелинейное биективное преобразование множества двоичных векторов V₈ задается подстановкой

= Veс₈ Int₈: V₈ V₈,

где

Значения подстановки записаны ниже в виде массива = ( (0), (1),…, (255)):

5.3 Перестановка байт

τ = (0, 8, 16, 24, 32, 40, 48, 56, 1, 9, 17, 25, 33, 41, 49, 57, 2, 10, 18, 26, 34, 42, 50, 58, 3, 11, 19, 27, 35, 43, 51, 59, 4, 12, 20, 28, 36, 44, 52, 60, 5, 13, 21, 29, 37, 45, 53, 61, 6, 14, 22, 30, 38, 46, 54, 62, 7, 15, 23, 31, 39, 47, 55, 63).

5.4 Линейное преобразование множества двоичных векторов

Источник

Инфраструктура открытых ключей: библиотека GCrypt как альтернатива OpenSSL с поддержкой российской криптографии

использование схемы подписи ГОСТ Р 34.10-2001 для формирования подписи после 31 декабря 2018 года не допускается!

Уже сегодня не имеет смысла получать сертификаты с подписью по ГОСТ Р 34.10-2001.
В то же время очень много сервисов или приложений разработано на базе OpenSSL, который поддерживал работу с ГОСТ Р 34.10-2001.

Но сегодня в стандартной версии openssl отсутствует поддержка как ГОСТ Р 34.11-2012, так и ГОСТ Р 34.10-2012. Более того, в версии 1.1 поддержка криптографии ГОСТ исключена из стандартной поставки («The GOST engine was out of date and therefore it has been removed.»).

Все это заставляет искать альтернативные пути для работы с сертификатами, с электронной подписью («сообщениями формата CMS») и другими объектами ИОК на базе новой российской криптографии.

Одним из таких возможных путей является использование библиотеки GCrypt. В этой библиотеке реализована поддержка новых алгоритмов ГОСТ Р 34.11-2012 (алгоритмы хэширования) и ГОСТ Р 34.10-2012 (алгоритмы подписи).

Генерация ключевой пары

— ГОСТ Р 34.10-2001 с длиной ключа 256 бит, oid 1.2.643.2.2.19 (0x2a, 0x85, 0x03, 0x02, 0x02, 0x13);
— ГОСТ Р 34.10-2012 с длиной ключа 256 бит (далее ГОСТ Р 34.10-12-256), oid 1.2.643.7.1.1.1.1 (0x2a, 0x85, 0x03, 0x07, 0x01, 0x01, 0x01, 0x01);
— ГОСТ Р 34.10-2012 с длиной ключа 512 бит (далее ГОСТ Р 34.10-12-512), oid 1.2.643.7.1.1.1.2 (0x2a, 0x85, 0x03, 0x07, 0x01, 0x01, 0x01, 0x02).

— 1.2.643.2.2.3 (0x2a, 0x85, 0x03, 0x02, 0x02, 0x03) — алгоритм подписи ГОСТ Р 34.10-2001 с ключом 256 с хэшированием ГОСТ Р 34.11-94;
— 1.2.643.7.1.1.3.2 (0x2a, 0x85, 0x03, 0x07, 0x01, 0x01, 0x03, 0x02) — алгоритм подписи ГОСТ Р 34.10-2012 с ключом 256 с хэшированием ГОСТ Р 34.11-2012;
— 1.2.643.7.1.1.3.3 (0x2a, 0x85, 0x03, 0x07, 0x01, 0x01, 0x03, 0x03) — алгоритм подписи ГОСТ Р 34.10-2012 с ключом 512 с хэшированием ГОСТ Р 34.11-2012.

Таким образом, имеется некоторый перебор с oid-ами, но что есть, то есть.

Ключи семейства ГОСТ относятся к семейству ключей на эллиптических кривых. Для генерации ключевой пары необходимо указать базовую точку на эллиптической кривой.

Техническим комитетом по стандартизации «Криптографическая защита информации» (ТК 26) рекомендованы для использования две базовые точки для ключей ГОСТ Р 34.10-2012-512:

— GOST2012-tc26-A (nickname в терминологии libgcrypt) с oid-ом 1.2.643.7.1.2.1.2.1 (0x2a, 0x85, 0x03, 0x07, 0x01, 0x02, 0x01, 0x02, 0x01);
— GOST2012-tc26-B с oid-ом 1.2.643.7.1.2.1.2.2 (0x2a, 0x85, 0x03, 0x07, 0x01, 0x02, 0x01, 0x02, 0x02);

— GOST2001-CryptoPro-A с oid-ом 1.2.643.2.2.35.1 (0x2a, 0x85, 0x03, 0x02, 0x02, 0x23, 0x01);
— GOST2001-CryptoPro-B с oid-ом 1.2.643.2.2.35.2 (0x2a, 0x85, 0x03, 0x02, 0x02, 0x23, 0x02);
— GOST2001-CryptoPro-C с oid-ом 1.2.643.2.2.35.3 (0x2a, 0x85, 0x03, 0x02, 0x02, 0x23, 0x03).

— GOST2001-CryptoPro-XchA с oid-ом 1.2.643.2.2.36.0 (0x2a, 0x85, 0x03, 0x02, 0x02, 0x24, 0x00);
— GOST2001-CryptoPro-XchB с oid-ом 1.2.643.2.2.36.1 (0x2a, 0x85, 0x03, 0x02, 0x02, 0x24, 0x01).

Однако в реальности эти oid-ы ссылаются на базовые точки GOST2001-CryptoPro-A с oid-ом 1.2.643.2.2.35.1 и GOST2001-CryptoPro-C с oid-ом 1.2.643.2.2.35.3 соответственно.
И это следует учитывать при обработке базовых точек с этими oid-ами.

Для генерации ключевой пары используется функция gcry_pk_genkey следующего вида:

В переменной parms должны быть установлены параметры для генерации ключевой пары в формате внутреннего S-выражения (sexp). Для генерации ключевой пары по ГОСТ параметры задаются в виде следующего S-выражения:

ecc определяет генерацию ключевой пары на эллиптических кривых, а базовая точка должна указывать конкретную точку, рекомендуемую ТК-26. Именно указанная базовая точка определяет, какая ключевая пара будет сгенерирована. Если указать, например, GOST2012-tc26-A или GOST2012-tc26-В, то будет сгенерирована ключевая пара по ГОСТ Р 34.10-2012 с длиной ключа 512 бит. Вместо nickname базовой точки можно указывать напрямую oid:

В последнем случае предполагается генерация ключевой пары по ГОСТ Р 34.10 с длиной ключа 256 бит и базовой точкой GOST2001-CryptoPro-C.

Ниже приведен пример программы на языке C, который демонстрирует генерацию ключей

Для трансляции примера необходимо выпонить команду:

После запуска модуля GenKey получим

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

Хэширование документа

— 1.2.643.2.2.3 (0x2a, 0x85, 0x03, 0x02, 0x02, 0x03) — алгоритм подписи ГОСТ Р 34.10-2001 с ключом 256 с хэшированием по ГОСТ Р 34.11-94 с длиной хэша 256 бит;
— 1.2.643.7.1.1.3.2 (0x2a, 0x85, 0x03, 0x07, 0x01, 0x01, 0x03, 0x02) — алгоритм подписи ГОСТ Р 34.10-2012 с ключом 256 с хэшированием по ГОСТ Р 34.11-2012 с длиной хэша 256 бит;
— 1.2.643.7.1.1.3.3 (0x2a, 0x85, 0x03, 0x07, 0x01, 0x01, 0x03, 0x03) — алгоритм подписи ГОСТ Р 34.10-2012 с ключом 512 с хэшированием по ГОСТ Р 34.11-2012 с длиной хэша 512 бит.

Эти алгоритмы определяют не только тип закрытого ключа, который будет использован для получения ЭП, но и алгоритм хэш-функции. В библиотеке GCrypt реализованы все три типа функций. Алгоритм хэширования ГОСТ Р 34.11-94 (с oid-ом параметра 1.2.643.2.2.30.1 — 0x2a, 0x85, 0x03, 0x02, 0x02, 0x1e, 0x01) реализован под nickname-ом GOSTR3411_CP, алгоритм ГОСТ Р 34.11-2012 с длиной 256 бит (oid 1.2.43.7.1.1.2.2 — 0x2a, 0x85, 0x03, 0x07, 0x01, 0x01, 0x02, 0x02) реализован под nickname-ом STRIBOG256 и алгоритм ГОСТ Р 34.11-2012 с длиной 512 бит (oid 1.2.43.7.1.1.2.3 — 0x2a, 0x85, 0x03, 0x07, 0x01, 0x01, 0x02, 0x03) реализован под nickname-ом STRIBOG512.

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

Транслируем этот модуль и получаем утилиту вычисления хэш:

Формирование электронной подписи и ее проверка

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

Все готово для получения подписи и ее просмотра …
gcry_sexp_t sig_r, sig_s;
…
/*Подписываем хэш*/
err = gcry_pk_sign (&sig, data, sec_key);
if (err) <
fprintf(stderr, «signing failed: %s\n», gcry_strerror (err));
exit(1);
>
/* Печатаем подпись */
show_sexp («ECC GOST SIG:\n», sig);
/*Выбираем и печаем составные части подписи r и s*/
sig_r = gcry_sexp_find_token (sig, «r», 0);
if (!sig_r) <
fprintf(stderr, «r part missing in sig\n»);
exit(1);
>
show_sexp («ECC GOST Sig R-part:\n», sig_r);
sig_s = gcry_sexp_find_token (sig, «s», 0);
if (! sig_s) <
fprintf(stderr, «s part missing in sig\n»);
exit(1);
>
show_sexp («ECC GOST Sig S-part:\n», sig_s);
…Проверить подпись можно следующим образом:

Проверка электронной подписи ГОСТ Р 34.10 в сертификатах

Одними из главных объектов инфраструктуры открытых ключей (ИОК) являются сертификаты X509. Рекомендации ТК-26 по составу и структуре сертификатов изложены в документе «ТЕХНИЧЕСКАЯ СПЕЦИФИКАЦИЯ ИСПОЛЬЗОВАНИЯ АЛГОРИТМОВ ГОСТ Р 34.10, ГОСТ Р 34.11 В ПРОФИЛЕ СЕРТИФИКАТА И СПИСКЕ ОТЗЫВА СЕРТИФИКАТОВ (CRL) ИНФРАСТРУКТУРЫ ОТКРЫТЫХ КЛЮЧЕЙ X.509 (Утверждена решением заседания технического комитета по стандартизации «Криптографическая защита информации» (Протокол N13 от 24.04.2014 г.) ». Именно в соответствии с этими рекомендациями выпускают сертификаты все аккредитованные в Минкомсвязи России УЦ.

Процедура parse_gost_cert предназначена для разбора сертификатов на базе российской криптографии.
В этом файле находится также процедура присвоения nickname-мов oid-ам российской криптографии с учетом проекта GCrypt:
Процедура parse_gost_cert позволяет получить TBS-сертификат, подпись сертификата, тип подписи, открытый ключ. Если мы рассматриваем самоподписанный сертификат, то этого достаточно для проверки подписи. Если же мы проверяем подпись сертификата, подписанного (выпущенного) другим сертификатом (issuer и subject сертификата не совпадают), то процедура получения информации для проверки подписи выглядит следующим образом:

— из проверяемого сертификата извлекаем его TBS-сертификат, тип подписи и саму подпись;
— из корневого сертификата извлекаем открытый ключ.

Самое ответственное при подготовке исходных данных для проверки подписи сертификата, это строгое следование рекомендациям TK-26. Для значения открытого ключа они звучат так:

Представление открытого ключа GostR3410-2012-256-PublicKey идентично представлению открытого ключа ГОСТ Р 34.10-2001 [IETF RFC 4491], и ДОЛЖНО содержать 64 октета, где первые 32 октета содержат координату x в представлении little-endian, и вторые 32 октета содержат координату y в представлении little-endian.

Представление открытого ключа GostR3410-2012-512-PublicKey ДОЛЖНО содержать
128 октетов, где первые 64 октета содержат координату x в представлении little-endian, и вторые 64 октета содержат координату у в представлении little-endian.

Алгоритм подписи ГОСТ Р 34.10-2012 с длиной хэш-кода 256 бит используется для формирования цифровой подписи в форме двух 256-битных чисел, r и s. Её представление в виде строки октетов (OCTET STRING) идентично представлению подписи ГОСТ Р 34.10-2001 [IETF RFC 4491] и состоит из 64 октетов; при этом первые 32 октета содержат число s в представлении big-endian (старший октет записывается первым), а вторые 32 октета содержат число r в представлении big-endian.

Алгоритм подписи ГОСТ Р 34.10-2012 с длиной хэш-кода 512 используется для формирования цифровой подписи в форме двух 512-битных чисел, открытые ключи согласно r и s. Её представление в виде строки октетов (OCTET STRING) состоит из 128 октетов; при этом первые 64 октета содержат число s в представлении big-endian (старший октет записывается первым), а вторые 64 октета содержат число r в представлении big-endian.

С учетом этих рекомендаций Tcl-модуль parse_certs_for_verify_load.tcl подготовки исходных данных для проверки подписи сертификата

Для тестирования возьмем два реальных сертификата:

Подготовим исходные данные для проверки сертификата «УЦ 1 ИС ГУЦ.pem»:

Проверка подписи сертификата выполняется модулем:

Транслируем и выполняем утилиту TEST_from_TCL:

Как видим, проверка подписи сертификата «УЦ 1 ИС ГУЦ.pem» прошла успешно. Осталось проверить сам корневой сертификат «ГУЦ Минкомсвязь.pem». Все просто, достаточно выполнить команду:

Если кто захочет проверить сертификаты с другими ГОСТ-овыми ключами (ГОСТ Р 34.10-2012-256 или ГОСТ Р 34.10-2012-512), то может воспользоваться УЦ CAFL63 и подготовить любые сертификаты:

Итак, проделанные изыскания показали, что библиотека GCrypt вполне может использоваться для работы с российской криптографией. Ближайшая перспектива видится в доработке библиотеки KSBA и расширении пакета pki скриптового языка Tcl (а может и Python) поддержкой российской криптографии.

Те, кто хочет использовать библиотеку GCrypt для шифрования, рекомендую заглянуть сюда.

Источник