Это требуется для механизма KDF_TREE_GOSTR3411_2012_256 https://tc26.ru/standard/rs/%D0%A0%2050.1.113-2016.pdf. Как видно из документа, параметр L, отвечающий за длину вырабатываемого ключевого материала, может принадлежать некоторому интервалу. И, честно говоря, я ожидала, что если задам его равным 64, то результирующий ключ будем иметь размер 64. Однако наблюдала, что мне возвращается 32 байта.

Большое спасибо за подробные ответы!

Мы немного запутались. Изначально вы говорили о CKM_GOSTR3410_12_DERIVE, получается у вас есть ключевая пара? Суть вашей задачи перейти с выработки KEK с алгоритмом 28147 (== сделать vko 2012-256) на выработку KEK с алгоритмом магма? Если да, похоже, что вам все-таки стоит использовать CKM_GOST_KEG.

Если все же требуется непосредственно диверсифицировать 28147 для получения ключа с типом CKK_KUZNECHIK_TWIN_KEY/CKK_MAGMA_TWIN_KEY, то пока это не поддерживается; расскажите, пожалуйста, для какой криптосхемы это требуется?

Конечная задача: выработка сеансового симметричного ключа по механизму KDF_TREE_GOSTR3411_2012_256 со следующими условиями:
    1. Результирующий размер ключа должен быть 64 байта
    2. Применить механизм необходимо к ключу, выработанному ранее по механизму CKM_GOSTR3410_12_DERIVE, где значение KDF равно CKD_NULL, а тип ключа - CKK_GOST28147 (под "применить механизм к ключу" я подразумеваю, что речь идёт о том ключе, который будет являться третьим аргументом функции C_DeriveKey)

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

Расскажите, пожалуйста, какую конечную задачу вы решаете?

Порядок действий, приведённый в пункте 1) выбран Вами, поскольку отсутствует пример выработки ключа для kexp/kimp в Рутокен SDK?

CKM_GOST_KEG есть в текущем релизе библиотеки PKCS#11 2.3.2, которая пока еще не вошла в Рутокен SDK. Ссылка для загрузки библиотеки и хедеров: https://download.rutoken.ru/Rutoken/PKCS11Lib/Current

При необходимости сможем предоставить более полный пример.

Возникли следующие вопросы, на которые я в документации к PKCS11 ответа не нашла:
    1. Верно ли, что чтобы получить  сеансовый симметричный ключ размером 64 байта по механизму KDF_TREE_GOSTR3411_2012_256 я должна в C_DeriveKey передать в качестве входного ключа, ключ с типом CKK_KUZNYECHIK/CKK_MAGMA и в качестве выходного получить ключ с типом CKK_KUZNECHIK_TWIN_KEY/CKK_MAGMA_TWIN_KEY? Следовательно, если у меня есть выработанный общий ключ VKO GOST R  34.10-2012 по механизму CKM_GOSTR3410_12_DERIVE с типом CKK_GOST28147, то чтобы получить из него ключ размера 64 байта по механизму KDF_TREE_GOSTR3411_2012_256, мне нужно, например, поступить так:
        1.1. Прочитать значения существующего ключа типа CKK_GOST28147, выработанного по механизму CKM_GOSTR3410_12_DERIVE
        1.2. С помощью C_CreateObject создать новый ключ типа CKK_KUZNYECHIK/CKK_MAGMA и в шаблоне объекта этого ключа в качестве CKA_VALUE передать значение, которое я прочитала в пункте 1.1
        1.3. Созданный ключ в пункте 1.2 передать в качестве входного ключа в C_DeriveKey и в качестве выходного получить ключ с типом CKK_KUZNECHIK_TWIN_KEY/CKK_MAGMA_TWIN_KEY, который будет иметь размер 64 байта
        1.4. Удалить ключ, сформированный в пункте 1.2

    2. В документации упоминается CKM_GOST_KEG (https://dev.rutoken.ru/pages/viewpage.a … M_GOST_KEG), на форуме (https://forum.rutoken.ru/topic/3423/) говорится, что "В следующей версии библиотеки PKCS#11 механизм CKM_VENDOR_GOST_KEG будет заменен на реализацию ТК26 (практически идентичную) - CKM_GOST_KEG." При этом в последнем SDK дефайн CKM_GOST_KEG не определён, а дефайн CKM_VENDOR_GOST_KEG - определён…и получается, что текущая документация немного отличается от того, что предоставляет текущий SDK?