On 18.06.2018 23:01, Dmitry Belyavsky wrote:
Привет!
2018-06-18 20:04 GMT+03:00 Nikolay Shaplov <dhyan@nataraj.su>:
В письме от 18 июня 2018 12:15:59 пользователь Dmitry Belyavsky написал:
> > > Кажется, необязательный. По идее брать будем 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.
Параметры, используемые при шифровании ключа, могут быть заданы в сертификате ключа, там структура параметров состоит из <=3 OIDов: параметры собственно алгоритма ключа, параметры алгоритма хэширования и параметры алгоритма шифрования. Наличие последнего OIDа не является обязательным и никто его никогда туда не пишет, но формально он может присутствовать, и если он присутствует, то именно эти параметры должны использоваться при шифровании. Сколь я помню, ты это в свое время даже реализовал, вот насколько оно было протестировано, уверенно не скажу, хотя имею смутное воспоминание, что сертификаты с OIDом параметров шифрования мы у Крипто-Про запрашивали.
Но поскольку на практике такие сертификаты, как я уже писал, не встречаются, то параметры выбираются умолчательные, по идее умолчание должно быть тем же, что и для шифрования данных (А для 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)
--
SY, Dmitry Belyavsky