В письме от 19 июня 2018 12:37:43 пользователь Igor Ustinov написал:
Попробую просуммировать всю полученную информацию:
1. Похоже что для того чтобы нормально задокументировать то какой парамсет
когда используется, и как на это влияет CRYPT_PARAMS, нужно строить
многомерную таблицу с осями Case(TLS, CMS etc), широнабор/ассим.алгоритм,
значение CRYPT_PARAMS, направление шифрования. (Какие-то из осей внутрь поля
таблицы можно всосать, но ближе к первой нормальной форме оно вот в такой
размерности похоже).
Это явно задача за пределами INSTALL.md, если в нее соваться, то по отдельному
запросу...
2. А для INSTALL.md я попробую сформулировать так:
Есть случаи, когда gost-engine может сам определить какой ParamSet для gost98
использовать. Так например при установке TLS соединения ParamSet однозначно
задается выбранным шифр-сьютом, или Id paramseta может быть явно указан в
параметрах [крипто объекта???] (Например внутри объекта CMS, предусмотрено
поле для параметров симетричного шифра, и ParamSet для gost89 может быть
указан там)
Однако часты случаи когда выбор ParamSet'а не может быть сделан автоматически
(например в случае если в CMS не заполнено поле опций симметричного
шифрования), или OpenSSL не предоставляет интерфейса для выбора ParamSet
(шифрование gost89 используя командно строчную утилиту). В этих случаях в
качестве значения ParamSet будет использовано значение указанное в параметре
CRYPT_PARAMS
(А про его значение по умолчанию я подло писать не буду :-) )
Допустил ли я какие-то фактические ошибки в предыдущих двух абзацах? (строка в
скобках за абзац не считается.
Do code for fun.
> >> > > > Кажется, необязательный. По идее брать будем
> >>
> >> 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)
--