Выработка двойственного ключа по алгоритму KEG (Страница 1 из 2)

Добрый день!

Уточните пожалуйста модель токена, которую Вы используете, версию SDK и драйверов

BeanSoup, добрый день!

Механизмы Кузнечик и Магма доступны только в Рутокен ЭЦП 3.0 NFC.

В следующей версии библиотеки PKCS#11 механизм CKM_VENDOR_GOST_KEG будет заменен на реализацию ТК26 (практически идентичную) - CKM_GOST_KEG.

BeanSoup, верно, для устройств ЭЦП 2.0 доступны механизмы VKO GOST R  34.10-2012 и KDF_TREE_GOSTR3411_2012_256 (с ключами ГОСТ-89).

Добрый день.

Прошу помочь разобраться в следующей ситуации.
Я продолжаю попытки реализовать алгоритм KEG с использованием устройств рутокен. При реализации стремлюсь опираться на документ ТК26 "Использование российских криптографических алгоритмов в протоколе безопасности транспортного уровня (TLS 1.2)".  Если я правильно понял представленное в нем описание, то:
- в качестве KEG для 512 бит можно использовать алгоритм VKO512;
- в качестве KEG для 256 бит можно использовать связку алгоритмов VKO256 + KDF_TREE;
- результатом работы KEG является последовательность длиной 64 байта.
Полноценного примера для использования механизма KDF_TREE_GOSTR3411_2012_256 на сайте или в SDK я не смог найти, однако заполнить структуру CK_KDF_TREE_GOST_PARAMS в соответствии с требованиями документа ТК26 и довести до рабочего состояния функцию C_DeriveKey (возвращает значение CKR_OK) удалось.
В итоге с вариантом KEG для 256 бит возникли следующие вопросы:
- при использовании механизма VKO_GOSTR3410_2012 в качестве параметра kdf следует передавать значение "CKM_KDF_GOSTR3411_2012_256" или значение "CKD_NULL"?
- почему при использовании механизма KDF_TREE_GOSTR3411_2012_256 при передаче параметру ulL (в качестве байтовой длины вырабатываемого ключевого материала) значения 64 байта функция C_DeriveKey вырабатывает последовательность длиной 32 байта?

Спасибо.

Благодарю за быстрый ответ.
В настоящий момент используются следующие параметры

CK_KDF_TREE_GOST_PARAMS x;
CK_MECHANISM y = { (CK_MECHANISM_TYPE)KDF_TREE_GOSTR3411_2012_256, NULL_PTR, 0 };
CK_UTF8CHAR z[] = { "kdf tree" };
BYTE k[8] = { 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF };

x.pLabel = (CK_BYTE_PTR)z;
x.ulLabelLength = 8;
x.pSeed = k;
x.ulSeedLength = 8;
x.ulR = 1;
x.ulL = 64;
x.ulOffset = 0;
x.pParameter = &y;
x.ulParameterLen = sizeof(y);

В качестве типа вырабатываемого ключа используется значение CKK_GOST28147.

Я попробую переформулировать вопрос.
В разделе 6.4.5.1 документа ТК26 "Использование российских криптографических алгоритмов в протоколе безопасности транспортного уровня (TLS 1.2)" регламентируется порядок получения ключа по алгоритму KEG. Результатом работы данного алгоритма является последовательность длиной 64 байта (этот результат затем предполагается передавать на вход алгоритма Kexp15). Итоговым выходом алгоритма KEG (256 бит) является результат работы механизма KDF_TREE_GOSTR3411_2012_256. Для определения длины вырабатываемой последовательности механизма KDF_TREE_GOSTR3411_2012_256 в соответствии с документацией рутокен используется переменная ulL, но при этом можно считать только 32 байта.
Пожалуйста поясните, можно ли каким-либо образом считать 64 байта выхода работы механизма KDF_TREE_GOSTR3411_2012_256?

Спасибо за подтверждение, именно так я и предполагал.

Понятно. Да, я пытался передавать ключи CKK_MAGMA_TWIN_KEY и CKK_KUZNECHIK_TWIN_KEY в шаблон и получал соответствующую ошибку от C_Derivekey. Без ошибки отрабатывало только для CKK_GOST28147.

Теперь в целом все понятно, спасибо. Хотелось бы только уточнить есть ли какие-либо токены/смарткарты ЭЦП 3.0, поддерживающие описанный функционал, кроме этих https://www.rutoken.ru/products/catalogue/id_114.html?