<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Nov 10, 2019 at 11:29 PM Dmitry Eremin-Solenikov <<a href="mailto:dbaryshkov@gmail.com">dbaryshkov@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Привет!<br>
<br>
вс, 10 нояб. 2019 г. в 21:31, Dmitry Belyavsky <<a href="mailto:beldmit@gmail.com" target="_blank">beldmit@gmail.com</a>>:<br>
> On Wed, Nov 6, 2019 at 6:49 PM Alexander Bokovoy <<a href="mailto:ab@altlinux.org" target="_blank">ab@altlinux.org</a>> wrote:<br>
>> В последних версиях crypto-policies (<a href="https://gitlab.com/redhat-crypto/fedora-crypto-policies/" rel="noreferrer" target="_blank">https://gitlab.com/redhat-crypto/fedora-crypto-policies/</a>), которые уже присутствуют в Fedora 31, появилась поддержка "вторичных политик".<br>
>><br>
>> "Вторичные политики" позволяют добавить разрешения на использование специфичных крипто-систем поверх имеющейся системной политики. Даже есть заготовка для ГОСТ, но она не работает, потому что не описывает конкретные шифронаборы, которые можно разрешать.<br>
>><br>
>> Вот дополнительный модуль политики для ГОСТ: <a href="https://gitlab.com/redhat-crypto/fedora-crypto-policies/blob/master/policies/modules/GOST.pmod" rel="noreferrer" target="_blank">https://gitlab.com/redhat-crypto/fedora-crypto-policies/blob/master/policies/modules/GOST.pmod</a>. Этот модуль определяет внутренние имена для генераторов политик конкретных библиотек. Например, openssl генератор: <a href="https://gitlab.com/redhat-crypto/fedora-crypto-policies/blob/master/python/policygenerators/openssl.py" rel="noreferrer" target="_blank">https://gitlab.com/redhat-crypto/fedora-crypto-policies/blob/master/python/policygenerators/openssl.py</a>. Этот генератор (как и другие) не содержит преобразований из внутренних имен ГОСТ, определенных в GOST.pmod в имена, понимаемые библиотеками.<br>
>><br>
>> Фактически, это заготовка, которую нужно доработать.<br>
>><br>
>> Преобразование нужно как-то определить -- оно позволяет нам описать предпочитаемые шифронаборы и управлять их выбором. Если таких наборов будет несколько (старый ГОСТ, современный ГОСТ и так далее), то мы можем описать их в разных дополнительных модулях (GOST-OLD, GOST, etc), но нам нужно договориться о том, во что используемые в них имена будут преобразованы для каждой библиотеки, поддерживающей ГОСТ.<br>
><br>
><br>
> С единством имён у нас плохо. Для openssl в своё время часть имён придумали мы в Криптокоме, и не всегда удачно.<br>
> Есть старые ГОСТы, которые потихоньку вымирают, и есть новые, частично дублированные в RFC.<br>
<br>
Я накидал <a href="https://gitlab.com/redhat-crypto/fedora-crypto-policies/merge_requests/50" rel="noreferrer" target="_blank">https://gitlab.com/redhat-crypto/fedora-crypto-policies/merge_requests/50</a>,<br>
исходя из своего понимания.<br>
Надо доделать генераторы для openssl, gnutls и т.п. (patches are<br>
welcome). Для gnutls постараюсь сделать во вторник.<br>
Плюс я не включил MGM в список, но это просто решается.<br>
<br>
С openssl будет отдельный вопрос, потому что openssl ciphers без<br>
engine не будет нормально работать с ГОСТовыми именами.<br></blockquote><div> </div><div>Спасибо. PR добавляет новую политику верхнего уровня GOST, по ней становится понятно, что писать в подполитику GOST в генераторах. Если не допишите за эту неделю, на следующей я в отпуске и попробую взяться сам.</div><div><br></div><div>Единство имен особую проблему не представляет, кроме усложнения генераторов. С другой стороны, можно сделать специальный модуль для ГОСТ и импортировать его в генераторы, чтобы собрать все преобразования в одной точке.</div><div><br></div></div>-- <br><div dir="ltr" class="gmail_signature">/ Alexander Bokovoy</div></div>