В письме от 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 (А про его значение по умолчанию я подло писать не буду :-) ) Допустил ли я какие-то фактические ошибки в предыдущих двух абзацах? (строка в скобках за абзац не считается. > >> > > > Кажется, необязательный. По идее брать будем > >> > >> 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) -- Do code for fun.
Attachment:
signature.asc
Description: This is a digitally signed message part.