> > > Кажется, необязательный. По идее брать будем
id-tc26-gost-28147-param-Z
> > > с точностью до моих ошибок.
> >
> > Я могу без доп. проверок написать в доке, что это
значение по умолчанию?
> Можешь. И оговорить, что оно не такое для ГОСТа,
используемого в
> шифронаборе GOST2001-GOST89-GOST89, и если умолчание не
такое в каких-то
> ещё случаях, то это скорее всего баг и об этом надо
сообщать мне.
На этой фразе мой мозг пожелал всем всего хорошего и
сломался... O_o
ГОСТовый шифр у нас используется в трёх местах. В CMS, PKCS8/12 и
TLS.
Проще всего в TLS. Там он сейчас используется в двух
шифронаборах, в одном используются парметры A, в другом -
параметры Z.
В PKCS8/12 я не помню, что используется. Сейчас скорее всего
параметры по умолчанию (Z).
В CMS, кажется, как раз используется то, что в CRYPT_PARAMS.
В CMS (равно как и в PKCS#7) шифрование используется в двух
местах: при зашифровании ключа и при зашифровании собственно данных.
Параметры, используемые при шифровании собственно данных, задаются
таки да, через CRYPT_PARAMS, а если он не задан, то используется
умолчательный, который, сколь я помню ТЗ, коее мы на эту тему
сочиняли, таки да, зависит от алгоритма открытого ключа: А для
2001, Z для 2012.
Кажется, так.
Смотрение в тесты показало, что вот нифига: если paramset шифрования не
указан явно, то используется всегда tc26-Z. Да, и для ключей 2001 тоже.
Параметры, используемые при шифровании ключа, могут быть заданы в
сертификате ключа, там структура параметров состоит из <=3 OIDов:
параметры собственно алгоритма ключа, параметры алгоритма
хэширования и параметры алгоритма шифрования. Наличие последнего
OIDа не является обязательным и никто его никогда туда не пишет,
но формально он может присутствовать, и если он присутствует, то
именно эти параметры должны использоваться при шифровании. Сколь я
помню, ты это в свое время даже реализовал, вот насколько оно было
протестировано, уверенно не скажу, хотя имею смутное воспоминание,
что сертификаты с OIDом параметров шифрования мы у Крипто-Про
запрашивали.
Не в open-engine.
Но поскольку на практике такие сертификаты, как я уже писал, не
встречаются, то параметры выбираются умолчательные, по идее
умолчание должно быть тем же, что и для шифрования данных (А для
2001, Z для 2012), но насколько честно ты это реализовал в
open-engine, сказать затрудняюсь.
Тесты проходили, так что должен был реализовать сравнительно честно, и
если где-то не так, то это баг.
А это место в тестах не проверяется никак.
С уважением,
Игорь Устинов
зам.ген.директора
ООО "Криптоком"
То есть интуитивно ясно, что для GOST2001 должны браться
старые paramset'ы. Но
как именно это запряжено в лошадь -- совершенно непонятно...
Давай я попробую разобрать по use-case'ам... Поправь меня
если что...
Мы желаем зашифровать что-то несимметричным кюлчем, для этого
мы откуда-то
берем симметричный ключ, шифруем им текст используя GOST89, и
потом этот ключ
шифруем публичной частью несимметричного ключа получателя...
Так вот, если мы указали CRYPT_PARAMS в конфиге в явном виде,
то при
шифровании GOST89 будет использован тот который мы указали, и
никаких
сусликов...
Если мы ничего не указали в качестве CRYPT_PARAMS, то если мы
несимметричное
шифрование будем делать при помощи GOST2001, то в качестве
ParamSet'а для
GOST89 будет использован id-Gost28147-89-CryptoPro-A-ParamSet.
Если же несимметричное шифрование осуществляется при помощи
GOST2012, любой ее
из размерностей, то в качестве ParamSet для GOST89 ,будет
взят id-tc26-
gost-28147-param-Z
Я правильно все это понимаю?
Еще я понял, что не понимаю смысла вот этого абзаца
> Value of this parameter can be either short name, defined
in OpenSSL
> `obj_dat.h` header file or numeric representation of OID,
defined in
> [RFC 4357][1].
Можешь раскрыть его смысл?
Да, тут проще всего. У параметров есть OID (много цифр,
соединённых точками) и символическое имя (id-tc26-
gost-28147-param-Z)